Skip to main content

More en more companies are being a victim of malware, ransomware or even hackers.

It is always important to implement the golden 3-2-1-1-0 rule (in detail explained in a former post of me - 3-2-1-1-0 Golden Backup Rule | Veeam Community Resource Hub).

Next to this rule, one of the first things to keep in mind is to protect as much as possible your backups because those can save you when you are being attachked and you need them.

The first thing that comes in mind, is to harden your Veeam Backup & Replication server as much as possible.

I will give you here 10 tips you can implement. There are of course more things possible, but it's a start.

1 - Do not domain-join the backup server in the production domain

A best-practice is to put the VBR server in a workgroup and not AD domain-joined for smaller environments.

Why? If ransomware is nested in a roaming profile of a domain-user connecting to the domain-joined VBR server, this malware can be activated on the VBR server and impact the backups. Also if this domain-user is being logged on to his client and has admin-access to the VBR server, ransomware can also being activated on drives of the VBR server.

If the VBR server is member of a workgroup this can be eliminated.

For larger environments, it is recommended to implement a separate management domain. The VBR-server is then a member of this management domain and not the production domain.

Do the same for other Veeam components (proxy-servers, repositories, ...)

2 - Do not use RDP for the backup server

Avoid using RDP on the VBR server. Use instead the Veeam console installed on a management server. From there you can connect to the VBR server using this console. Try to use a regular (no local admin permissions) local user on the VBR server connecting to it.

Only log on to the VBR server using RDP for upgrading Veeam or installing manually updates or firmware (in case of a physical backup server).

You can go even further : disable the RDP service. You can use then the management-interface (ILO, iDRAC, ...) of the server (in case of a physical server) or the console (HyperV, vSphere, ...) in case of a virtual machine.

3 - Do not use other roles on the backup server

The server where VBR is implemented should have only 1 role, the role of Veeam backup server!

No other roles (like WSUS, anti-virus management, file-server !!!, domain-controller !!!, ...) are being performed by this server.

The backup server must be a dedicated one with only 1 role!

So only install software needed for Veeam and nothing else.

You could think, that's obvious, but I can assure you, in smaller environments you can see everything ;-)

4 - Schedule maintenance for Windows Updates on all Veeam components

Often Windows updates are being installed automatically using GPO's or other mechanisms on Windows servers. Also often they are being rebooted automatically. This is mostly being performed in a maintenance window that is discussed with the management of the company. This maintenance windows is often at night or during the weekend, especially for critical production servers.

This maintenance window is mostly not available for the backup server and components. This because backups are mostly running during the night and full backups during the weekend.

Therefore a second maintenance window for updating the VBR server and components is necessary. This can be automatically if you are sure no backup-jobs or replication-jobs are running anymore.

Personally I prefer to install Windows updates and reboot the server manually. Then you can do this in a controlled manner. First check the status of the jobs, if everything is OK, disable them, reboot the server, install all available updates, reboot again, check again, enable the jobs, follow-up the backups the day after.

5 - Schedule maintenance for Firmware Updates on all Veeam components

If you are using a physical VBR server, then schedule on a regular basis a maintenance window where you will install the most recent firmware and drivers for this server. Do not think only on physical windows servers, but don't forget the NAS-devices being used as a backup repository. Lately those devices are frequently being impacted.

Don't forget to schedule this frequently, not once a year!

6 - Use Windows Firewall with only necessary ports

The Windows firewall is not the strongest solution as a firewall, but's build-in, it's available, therefore use it as it should.

Keep the firewall on for all domains (public, private and if applicable domain). Just open the necessary ports needed for Veeam to communicate with the necessary components.

7 - Roles, users and passwords

Use the principle of least privilege, especially in larger environments. Give the minimal privilege needed for someone to operate the necessary tasks. If you have multiple backup administrators, make sure they have a personal, dedicated account. Make this user a member of a group with the necessary permissions for this role.

Only give acces to what is needed for their job.

Of course, use always and only strong passwords. I take as a minimum 20 characters with at least a a-z A-Z 0-9 and a special character.

8 - Use anti-virus software with the necessary exclusions

Make sure that on the VBR server and all their components an anti-virus application is installed like you should install on all servers and clients.

Also make sure that the exclusions (ex. folders used as repository, Veeam-applications, ...) are correctly being set. Otherwise this could have a negative result on the performance.

Obvious you think, but unfortunately often forgotten or not correctly being implemented.

9 - Enable authentication on iSCSI LUNs as repositories

Often iSCSI LUNs are being used as a backup repository. That's perfect, a lot better than using SMB-shares in my opinion (a lot more stable and more efficient).

Frequently authentication is than not being used, only the iQN is needed, that 's it.

Try to limit the access to the LUNs being used as a repository.

You can use the CHAP protocol. It's not known as the best and most secure protocol, but it's better than using nothing as authentication.

10 - Secure physical backup repositories - use Veeam encryption

And last but not least, make sure that the physical devices being used as backup repository are physically secured.

Mostly those devices are located in a serverroom, but make sure that only people have access to this room that needs to.

Don't forget the second repositories (often located on another location or other site of the company and often not physically protected).

Don't forget to use Veeam encryption (using a very strong password) on those backup repositories that are not being physically protected! I think especially on mobile backup repositories like rotated USB disks, tapes, small NAS-devices.

If such a device comes in the wrong hands without encryption implemented...

One of my wishes would be that Veeam would eventually move completely to a web based gui (something like the Veeam Appliance for Azure) and in that manner perhaps allow the vbr server to be installed on Windows core or even like the Veeam Appliance for Azure on Linux.


This is a good and very timely review of basic yet overlooked security best practices. I posted in LinkedIn. Thanks for this, especially after the latest high-profile hack at Colonial Pipeline.


windows is update frequently. 

in my case I use VM for VBR server. it give me minimal downtime for update. 

 

Thanks for your post. 


Really like this. Would be nice if we could get to Windows Core or even possibly Linux for the VBR server in the future as mentioned by @Geoff Burke 

 


Nice summary. I wrote about the question often at hand to join a domain or a workgroup for the Veeam components. Add Veeam to a workgroup, domain or forest? on vmguru.com. 


@Viperian , thx for your reply and your post. I agree on your post that a management domain is the best way, then you can also use VDRO. But at small companies (not using Microsoft datacenter licenses), a separate management domain is overhead ;-)


@Nico Losschaert depends how small the company is to be honest! It is always balancing risk/reward and tie-ing investments towards the eventually required outcome.  For small companies I would recommend to add them to the Prod domain but deploy 2-Factor authentication for the administrative privileged accounts and make sure you have an ultra-resilient copy of your backups. Can be in a local Hardened Repository, a copy to a VCSP with insider protection enablement. Offload to a S3 environment (hyperscaler, local or VCSP) with Object Local or just Tape or rotational media, but please make sure those media are removed from the unit and out of the building whenever possible. 


Comment