Skip to main content

Hardening Veeam 12 Server: the definitive checklist


Show first post

46 comments

marcofabbri
Forum|alt.badge.img+13
  • Author
  • On the path to Greatness
  • 990 comments
  • April 20, 2023

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

dips
Forum|alt.badge.img+7
  • Veeam Legend
  • 808 comments
  • April 22, 2023

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

coolsport00
Forum|alt.badge.img+20
  • Veeam Legend
  • 4139 comments
  • May 4, 2023

Very thorough list @marcofabbri Great post! 


  • New Here
  • 1 comment
  • July 11, 2023

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.
 


marcofabbri
Forum|alt.badge.img+13
  • Author
  • On the path to Greatness
  • 990 comments
  • July 11, 2023
Tinux wrote:

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.


vAdmin
Forum|alt.badge.img+2
  • Influencer
  • 168 comments
  • July 26, 2023

Many thanks for sharing this guide @marcofabbri 


Iams3le
Forum|alt.badge.img+11
  • Veeam Legend
  • 1393 comments
  • October 3, 2023
dloseke wrote:

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!


marcofabbri
Forum|alt.badge.img+13
  • Author
  • On the path to Greatness
  • 990 comments
  • October 18, 2023

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!


DavideAbrigo
Forum|alt.badge.img+1
  • Experienced User
  • 118 comments
  • February 2, 2024

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?


damien commenge
Forum|alt.badge.img+5

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.


marcofabbri
Forum|alt.badge.img+13
  • Author
  • On the path to Greatness
  • 990 comments
  • February 2, 2024
damien commenge wrote:

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.


damien commenge
Forum|alt.badge.img+5
marcofabbri wrote:
damien commenge wrote:

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.


marcofabbri
Forum|alt.badge.img+13
  • Author
  • On the path to Greatness
  • 990 comments
  • February 2, 2024
damien commenge wrote:
marcofabbri wrote:
damien commenge wrote:

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!


DavideAbrigo
Forum|alt.badge.img+1
  • Experienced User
  • 118 comments
  • February 2, 2024
marcofabbri wrote:
damien commenge wrote:
marcofabbri wrote:
damien commenge wrote:

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 😉


damien commenge
Forum|alt.badge.img+5
DavideAbrigo wrote:
marcofabbri wrote:
damien commenge wrote:
marcofabbri wrote:
damien commenge wrote:

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


marcofabbri
Forum|alt.badge.img+13
  • Author
  • On the path to Greatness
  • 990 comments
  • April 15, 2024

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

 


Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • 8492 comments
  • April 15, 2024

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.


  • New Here
  • 1 comment
  • June 5, 2024

Great post! Thanks a lot!


Dynamic
Forum|alt.badge.img+10
  • Veeam Vanguard
  • 383 comments
  • July 9, 2024

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


Dynamic
Forum|alt.badge.img+10
  • Veeam Vanguard
  • 383 comments
  • July 11, 2024

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 


Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • 8492 comments
  • July 11, 2024
Dynamic wrote:

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