Hardening Veeam 12 Server: the definitive checklist



Show first post

42 comments

Userlevel 7
Badge +13

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
Userlevel 7
Badge +7

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
Userlevel 7
Badge +17

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.
 

Userlevel 7
Badge +13

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.

Userlevel 7
Badge +2

Many thanks for sharing this guide @marcofabbri 

Userlevel 7
Badge +9

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!

Userlevel 7
Badge +13

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!

Userlevel 4
Badge

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?

Userlevel 6
Badge +4

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.

Userlevel 7
Badge +13

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.

Userlevel 6
Badge +4

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.

Userlevel 7
Badge +13

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!

Userlevel 4
Badge

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 😉

Userlevel 6
Badge +4

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 :)

Userlevel 7
Badge +13

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

 

Userlevel 7
Badge +20

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.

Comment