Skip to main content

*UPDATED and REVISIONED APRIL 2024 - ver 12.1*

Every day we wonder which are the best way to hardening a new installation of Veeam Backup & Replication 12.1.

I wrote a *maybe* definitive community’s checklist:

 

Domain or workgroup?

There are two religions: mine is to keep the Veeam servers absolutely out of domain, in a workgroup environment. In an Enterprise level, a possible alternative is to create a separated domain dedicated exclusively to management. Decision is yours, according to your needs.

Hacker’s perspective: domain solutions are vulnerabile to Responder attack.

 

Remove Builtin\Administrators as Veeam Administrator

I think it’s better to assign specific roles to specific users rather than leaving access to all members of the Builtin\Administrators group, so it’s a good idea to create a new admin user and add it into security tab of console. Also, leaving the group doesn’t allow you to enable 2FA.

Hacker’s perspective: managing single users is easiest to keep unwanted and vulnerable users out of Veeam's Console management.

 

Principle of least privilege

It’s almost always not necessary to assign a high role to a user if he doesn't need it. VB&R allow us to divide into: Restore Operator, Backup Operator, Backup Administrator, Tape Operator and Backup Viewer roles. Let's use them wisely.

Hacker’s perspective: if a “common user” can lead to crucial operations on Veeam’s product, it could be really dangerous for your backup environment. Like, you know, delete all backups at once or change encryption passwords.

 

Enable the 2fa

Veeam’s 2FA option is compatible with all the most third-party apps, and this is a MUST. To activate it you need to remove the Builtin\Administrator group as written above.

Hacker’s perspective: 2FA saves you from unwanted access by leaked credentials.

 

Enable auto log-off

A best practice is to keep as few users as possible logged in Veeam’s console. Since version 12 it’s possible to set a logout timer.

Hacker’s perspective: if an RDP is compromised, without using credentials, the Veeam session should be closed to limit damage.

 

Enable Configuration Backup encryption

Having an encrypted configuration file of the whole backup infrastructure, with all passwords and IPs and users and everything else saved inside can be life-saver, especially in case of disaster. Need to recover your Veeam server from scratch? No problem, import that config file and you’re ready to go.

And don’t forget to save in a safe place the encryption password, because if you lose it the previous saved config file will becomes just a useless bunch of bytes.

 

Enable Backup Jobs encryption

Backup repositories are secure, aren’t they? But we live in a world where zero day vulnerabilities exist and best practices suggest to use a Zero Trust approach. If a malicious actor can access into the storage where .vbks are kept, well, it’s not a good thing. Enable encryption and, again, please save the encryption password.

Hacker’s perspective: getting access to a backup file let me access to all the files in the structure, bypassing folders' permissions.

 

Enable encryption in the LAN Traffic Rule

By default, only WAN traffic is encrypted by Veeam. To enable LAN traffic you need to create a specific new Traffic Rule with encryption enabled in the Global Network Traffic Rules tab.

Hacker’s perspective: not enabling LAN encryption makes you vulnerable to an APT sniffing attack.

 

Limit external access or move Veeam console

If applicable, it would be appropriate to limit all external accesses like RDP and third-party solutions. It’s not always possible, but where it is do it. An alternative is to use a “bastion host” with only the Veeam Console installed on that, and use that to connect to the Veeam Backup server, with different credentials. Of course.

Hacker’s perspective: getting access to the console host doesn’t allow me access to the Veeam backup server.

 

Disable remote powershell 

Another best practice is to limit remote powershell to the Veeam Backup Server.

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/disable-psremoting?view=powershell-7.3

Hacker’s perspective: there are over 1030 results fot CVEs related to powershell to date, and over 3k exploit public accessible on github.

 

One role to bind them, one… just one!

Do not install any other roles or any kind of unnecessary software on servers dedicated to Veeam. Each of them can be used as attack vector or can lead to incompatibilities or freezes of the vm/server or of VB&R itself.

Hacker’s perspective: over 25000 CVEs discovered in 2022 and already 22668 CVEs in 2023. Why risk?

 

Windows or third parties firewall, yes please!

You must not disable Windows firewall, configure it with only the necessary ports. I know put firewall down is quicker, but that’s not the correct way. Here the list of ports:

https://helpcenter.veeam.com/docs/backup/vsphere/used_ports.html?ver=120

https://helpcenter.veeam.com/docs/backup/hyperv/used_ports.html?ver=120

https://helpcenter.veeam.com/docs/backup/agents/used_ports.html?ver=120

Hacker’s perspective: you know that disabling the firewall allows an attacker to scan and enumerate all the ports on the server and look for vulnerabilities?

 

Use strong Passphrases, not passwords.

I shouldn't even write it, but... You must use strong and uncommon passphrases. Passwords are officially obsolete.

Hacker’s perspective: the following table show how much it takes to crack a password in 2023, and they’re not considering social engineering, personalized wordlists, rainbowtables, ecc...

 

Keep OS updated.

Updating operating systems in production is vital for security and performance, but testing is essential to reduce risk of problems. Planning and testing (in a testing environment) are key to ensuring business continuity.

Hacker’s perspective: Zero day attacks are a different thing, generally the priority of the update depends on the value of the CVE.

 

Antivirus, yes or no?

It varies. Installing a third-party antivirus may not always be essential, as the built-in Windows antivirus is quite effective. The crucial step is to ensure that Veeam processes are exempt from it to prevent unexpected issues.

Hacker’s perspective: antiviruses with behavior analysis can literally save your day.

 

Disable remote registry

In a high security environment, exposing the registry to remote access and its modification is an increased security risk. Via registry you can enable RDP, so… You know. You should disable via Services.

Hacker’s perspective: it’s possible to get a RDP access even if previously disabled if the service is active and running, by getting valid credentials with multiple attack vectors.

 

Disable ILO or IDRAC

Remember to disable HPE ILO or DELL IDRAC access to the hardware server console, where possible, as it can provide unauthorized access.

Hacker’s perspective: another way to gain access is via hardware console, resulting in the same as being physically connected to the device.

 

Hardware repositories

As the title suggests, it's essential to use physical repositories instead of virtual machines. A compromised hypervisor can lead to VM deletion. While physical servers can also be compromised, this approach eliminates one potential attack vector.

 

Best Practices Analyzer

In version 12, a new feature is the "Best Practices Analyzer" button can be found in the Home tab. It analyzes commonly used options for correct configurations, serving as a valuable tool to ensure nothing has been overlooked.

 

Physical Access Control System

No unauthorized person should have access to the server room. The perimeter must be protected by a video surveillance system and/or access via badge.

Hacker’s perspective: avoid piggybacking or tailgating too.


Remove unnecessary Veeam software

Remove Veeam Explorers and Veeam Console from the VB&R server if not useful.
(To remove the Console you need to remove all Veeam Explorers first!)
From CMD as Administrator

wmic product list brief > C:\temp\installed.txt
msiexec /x {RelatedProductCode}


Isolate the backup network...

Following best practices, it's imperative to segmente the production network from the management/backup network. This can be achieved using VLANs or VMkernel within the VMware hypervisor. The V12 server typically shouldn't be reachable from the production or WAN networks, except for occasional cases where it may need connectivity to an SMTP server for sending email notifications.

Hacker’s perspective: VLAN hopping is not simple, protect your backup network!

 

...but don’t forget Veeam updates!

Ensure that the backup server has the necessary permissions to communicate with specific internet servers, restricting communication to secure HTTPS connections, including the following specific addresses:

dev.veeam.com - the Veeam Update Notification Server

vbr.butler.veeam.com - Veeam License Update Servers

autolk.veeam.com - Veeam License Update Servers

 

Disable obsolete network protocols

SSL 2.0 and 3.0, TLS 1.0 and 1.1, SMB 1.0 and NetBIOS should be disabled.

https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server

Hacker’s perspective: old SMBs protocols has a 10.0 value score, the highest possible.


Manage SNMP traps with Veeam One

Veeam One can be configured to report about triggered alarms via SNMP traps. When SNMP trap notifications are enabled, Veeam ONE acts as an agent and generate and send SNMP to monitor servers.


Veeam ONE to detect Ransomware activity

Analyzing CPU usage, write rates on datastores and abnormal network traffic usage from the server Veeam One can send alarms and notification to identify a possible ransomware or malicious activity.

 

Subscribe to Veeam security advisories

You can opt to receive either a weekly summary of the latest KB updates or immediate notifications about Veeam security advisories.

https://www.veeam.com/services/open/kb/security-feed

https://www.veeam.com/services/open/kb/rss-feed

 

Script to Automate Implementation of Security & Compliance Analyzer Recommendations

The script released on KB4525 is provided to expedite the implementation of Security & Compliance Analyzer recommendations by VB&R Best Practices Analyzer. It was created by Veeam's development team and will be updated as further Security & Compliance recommendations are added to Veeam Backup & Replication.

https://www.veeam.com/kb4525

 

And the last but not least importat:

Do regular security audit 

Conducts regular security audits to ensure compliance of the backup infrastructure and mitigate risks before a breach. Plan vulnerability assessment by ethical hackers to maximize security. These proactive measures are crucial for maintaining robust posture security. 

 

These two official documents were also released with version 12:

Official Veeam Security Checklist:

https://go.veeam.com/rs/870-LBG-312/images/veeam-security-checklist.pdf

 

Official Veeam Security Best Practices

https://go.veeam.com/rs/870-LBG-312/images/veeam-security-best-practices-2022.pdf

 

Have I missed something? 🤠

Added:

  • Physical Access Control System
  • Remove unnecessary Veeam software
  • Isolate the backup network
  • Manage SNMP traps with Veeam One
  • Veeam ONE to detect Ransomware activity

I’ll add:

  • Regularly scan the server with Vulnerability Scanning software
  • Audit Logon events to check no-one apart from authorised users are logging on

Very thorough list @marcofabbri Great post! 


And why not abandon Windows at all ?
Even when you apply all hardening rules on the repositpry, the local Administrator can still delete all volumes via Disk Management.

And why does Veeam still use integrated Windows accounts and not its own local account databases like other competitors ?
Mind you that the local Administrator user on the Backup & Replication server still has Backup Administrator rights, even when Administrators group is removed from the list.
 


And why not abandon Windows at all ?
Even when you apply all hardening rules on the repositpry, the local Administrator can still delete all volumes via Disk Management.

And why does Veeam still use integrated Windows accounts and not its own local account databases like other competitors ?
Mind you that the local Administrator user on the Backup & Replication server still has Backup Administrator rights, even when Administrators group is removed from the list.
 

‘cause a well secured Windows machine is as safe as Linux machine, and vice versa.


Many thanks for sharing this guide @marcofabbri 


Just came across this post...not sure how I missed it.  While I like the idea of disabling iLO/IDRAC/CIMC/IMM/RSA, sometimes not an option.  One, slighly less secure alternative may be to place your OOB management on a separate network.  Not a sure solution, but best to not have it on the same network as your normal network traffic.

I agree with your comment!


Updated for the Cybersecurity Awareness month with new:

  1. Disable remote powershell 
  2. Subscribe to Veeam security advisories
  3. Vulnerability Assessment audit
  4. Limit external access or move Veeam console
  5. Whitelist Veeam server updates
  6. Disable obsolete network protocols

Added new links, hackers perspective in each point and rewrited most of them!


Regarding iLO/iDRAC/IMM/YourVendorAcronym access: i discussed this at the latest VUG with @marcofabbri , i was thinking about disabling the port at the switch level, while also adding a check on your monitoring system for the specific port when it’s enabled to trigger an alert.

Could it be reasonable enough?


Hello @DavideAbrigo ,

It’s one option but will never be the best… 

Physically disconnect it is the only way to be sure no one can remotely connect to the server. He needs to physically connect the IMM first.

If “hacker” get switch management password with your option because the password is stored in a keepass and someone get the password of the keepass => game over. 

It’s your choice to “accept” this risk or not.


Hello @DavideAbrigo ,

If “hacker” get switch management password with your option because the password is stored in a keepass and someone get the password of the keepass => game over. 

In a proper configuration, all management devices should be accessible only on a separate VLAN. So a game over is caused by wrong network segmentation, not by credential harvesting :)

@DavideAbrigo if disabling switch level, you mean implementing VLAN separated and protected, answer is yes. BUT, as we discussed, is to solve a need to remote access to ILO.


Hello @DavideAbrigo ,

If “hacker” get switch management password with your option because the password is stored in a keepass and someone get the password of the keepass => game over. 

In a proper configuration, all management devices should be accessible only on a separate VLAN. So a game over is caused by wrong network segmentation, not by credential harvesting :)

I totally agree with you, IMM is a dedicated VLAN. However, you just need to have access to a workstation allowed to connect to this remote management and…. 
In big company, different people will manage network and backup but in smallest, it will often be the same people.

 

I agree 100% about network segmentation but it’s just not enough to think it’s secured because you have VLAN and you can plug in the cable.


Hello @DavideAbrigo ,

If “hacker” get switch management password with your option because the password is stored in a keepass and someone get the password of the keepass => game over. 

In a proper configuration, all management devices should be accessible only on a separate VLAN. So a game over is caused by wrong network segmentation, not by credential harvesting :)

I totally agree with you, IMM is a dedicated VLAN. However, you just need to have access to a workstation allowed to connect to this remote management and…. 
In big company, different people will manage network and backup but in smallest, it will often be the same people.

I agree 100% about network segmentation but it’s just not enough to think it’s secured because you have VLAN and you can plug in the cable.

Yeah, if we’re talking about internal threat, I absolutely agree!


Hello @DavideAbrigo ,

If “hacker” get switch management password with your option because the password is stored in a keepass and someone get the password of the keepass => game over. 

In a proper configuration, all management devices should be accessible only on a separate VLAN. So a game over is caused by wrong network segmentation, not by credential harvesting :)

I totally agree with you, IMM is a dedicated VLAN. However, you just need to have access to a workstation allowed to connect to this remote management and…. 
In big company, different people will manage network and backup but in smallest, it will often be the same people.

I agree 100% about network segmentation but it’s just not enough to think it’s secured because you have VLAN and you can plug in the cable.

Yeah, if we’re talking about internal threat, I absolutely agree!

My idea was about a trade-off between security and manageability, with a configuration like:

  • at switch level, the BMC port should always be in shutdown
  • monitor the port with PRTG/Nagios/etc., checking if the status is disabled and raise an alert to the security team if enabled

As a member of a small team, i think this would be reasonable. Obviously proper switch configuration is needed (ACL, auditing, ...), but if the same people can manage network devices and servers, very little can be done for internal threat mitigation 😉


Hello @DavideAbrigo ,

If “hacker” get switch management password with your option because the password is stored in a keepass and someone get the password of the keepass => game over. 

In a proper configuration, all management devices should be accessible only on a separate VLAN. So a game over is caused by wrong network segmentation, not by credential harvesting :)

I totally agree with you, IMM is a dedicated VLAN. However, you just need to have access to a workstation allowed to connect to this remote management and…. 
In big company, different people will manage network and backup but in smallest, it will often be the same people.

I agree 100% about network segmentation but it’s just not enough to think it’s secured because you have VLAN and you can plug in the cable.

Yeah, if we’re talking about internal threat, I absolutely agree!

My idea was about a trade-off between security and manageability, with a configuration like:

  • at switch level, the BMC port should always be in shutdown
  • monitor the port with PRTG/Nagios/etc., checking if the status is disabled and raise an alert to the security team if enabled

As a member of a small team, i think this would be reasonable. Obviously proper switch configuration is needed (ACL, auditing, ...), but if the same people can manage network devices and servers, very little can be done for internal threat mitigation 😉

To be honest, smalles customer doesn’t do anything (but that’s a bad practice).
My last customer has arround 500VM for arround 2K users with dedicated teams. All IMM of repository are unplugged. The servers are in the same site so it’s not “hard” to plug them….

However, if you need to take a car and go to 450km… That could be a big pain xD.

As I said, it’s not the “best” practice, and you accept some risk. It’s all on you :)


UPDATE APR’24:
 

Script to Automate Implementation of Security & Compliance Analyzer Recommendations

The script released on KB4525 is provided to expedite the implementation of Security & Compliance Analyzer recommendations by VB&R Best Practices Analyzer. It was created by Veeam's development team and will be updated as further Security & Compliance recommendations are added to Veeam Backup & Replication.

https://www.veeam.com/kb4525

 


Really enjoyed testing this script out with the security analyzer.  Nice to see Veeam put this out there to make it easier for those that require assistance with this part of the product.


Great post! Thanks a lot!


very nice overview, will inform my colleagues of this as well. Thanks!


update from my side, as didn’t find it in the overview:

...i would also add the Four-eyes authorization feature to this list. Brings also more security: another admin has to acknowledge changes to users/roles and for deleting backups/repositories.

best regards Markus 


update from my side, as didn’t find it in the overview:

...i would also add the Four-eyes authorization feature to this list. Brings also more security: another admin has to acknowledge changes to users/roles and for deleting backups/repositories.

best regards Markus 

This is definitely one to add as we have implemented it on all our servers for better security and auditing.


Comment