Event Recap: Veeam Hardening Best Practices (March 19, 2025)

Thanks for posting this one Lukas as I missed it.  I will watch it now.  👍

Thanks for presenting and posting the recap. It was a great presentation! 

Nice one, was a very good session 👏💚

Hi Lukas, thank you for your presentation!

I’ve just a question: why did you choose to extend the backup VLAN to the repositories? Also steching it to diffirent sites, it is not a “security issue”? Assuming that the Veeam BP network design should be separate as much vlan as possible, it is better to not segment too much components in you opinion?

Thank you Marco!

The design always has to be matching the customer’s requirements so you always have to match blueprint to the actual situation.

My blueprint is designed for small to midrange customers since they often don’t have any segmentation at all.

The goal of putting repos and VBR / proxies into a single VLAN is simple: To avoid running backup data traffic (which can be lots of TB) through firewalls which are used for segmentation.

I often see the scenario that customers don’t even have a 10Gbit firewall which would slow down the backup process extremly.

As always: Please use the design which fits the requirements mostly and refer to the official BP guide in case of more complex scenarios.

Thanks for sharing, Lukas! I missed the session, but I’ll definitely watch the recap.

In the case of protecting a Hyper-V environment where the Hyper-V hosts are the proxies, would it be accurate to say the Veeam repositories must be on the same VLAN as the Hyper-V hosts? There seems to be no way to enable an off-host proxy to backup directly from the SAN for Hyper-V.

I have a customer that is being very strict about breaking everything into separate VLANs and minimizing routed traffic to avoid as much traffic going through the firewall as possible.

Good point! Since Hyper-V works a bit different, I see a few options here, all are maintaining the VLAN segmentation / separation:

1. (this only works for 3-tier architectures, so a dedicated storage / SAN) off-host proxy with SAN integration:

Here you can simply apply my blueprint or any other best practice blueprint with separation and simply attach the proxy (which can be a physical server with the repo role as well) to the SAN (FC / iSCSI), this has to be done by dedicated, seperated NICs / HBAs. I don’t see a huge security risk here since this is a different protocol.

With that you can use off-host proxy method but you have to refer to the storage vendor guides to implement this.

2. on-host proxy with dedicated NICs on the Hyper-V

You could add dedicated NICs to your Hyper-V nodes that run the VMs and use network policies and an optional hardware firewall between HV and repo to get the traffic to the repo. The disadvantage is that there will always be a security risk since there is a direct, dedicated connection (in case you don’t have a hardware fw in between).

3. on-host proxy through hardware firewall

You also could use the “default” and don’t add dedicated NICs for backup data traffic and route this through your firewalls. The disadvantage is that there will be a huge workload added to the fw so you could have a bottleneck there. The advantage is (compared to aspect 2 mentioned above) that you will have a specific security level maintained since there is no direct communication possible.

Especially when you use HCI scenarios (Microsoft S2D) you have to work with methods 2 or 3 since there is no dedicated storage appliance and - as far as I know - no integration possible.

Hope that helps!

Lukas

Great Security/Hardening overview Lukas! I was on vacay, so missed this. Glad it was recorded so I could watch it.

Thanks for sharing!

Thank you Shane, great to hear that this can be taken as valuable content! 😊

Thanks Lukas! I was wondering if you could elaborate on two particular recommendations in the Veeam Best Practices guide in 2.9 Hardening. First, do you recommend that we remove the Console from our VBR servers and install the Console on its own on a separate system, possibly in its own domain/workgroup? Second, did you say you preferred that the management server(s) be installed on a physical server in its own Workgroup over a Management AD domain, possibly virtualized? I’m being tasked with redesigning our infrastructure and I’m having a hard time finalizing on a design, particularly when it comes to any dedicated hardware that needs to be ordered. Excluding the repositories, what do you feel the is the current best practice when it comes to separating critical Veeam management components from the production domain?

Absolutely!

First:

Correct. Imo you shouldn’t access your main VBR servers (or other components) directly via console or RDP since this can lead to security issues: The RDP port is well-known and as long it is open the server listens on that port, also sessions could be disconnected but not logged out completely which is a major security concern.

Second:

Management servers (PAWs) should be redundant, that is the point. If you do it right those PAWs are your only access to the DR (Veeam) systems and e.g. you run a single PAW in a cluster and the cluster fails so you have to restore it - you won’t be able to since the PAW has died together with the cluster.

The main recommendation is to separate you Veeam components (VBR servers, repos, proxies etc.) from you production Active Directory. Some - lager - customers put them in a decicated management domain but I don’t since you have to harden that management domain as well. You simply don’t want an attacker to gain access to Veeam by compromising the production AD. Same is for the network: You don’t want lateral movement through your network to access Veeam.

I often go with the following, simply as that:

VBR virtualized, Enterprise Manager virtualized (separate VM), ONE virtualized (separate VM) and phyiscal repo (e.g. with proxy and / or tape proxy role if required and applicable), e.g. physical tape library etc.

Put everything in a separate VLAN and create another, second backup VLAN only for management (iLO, iDRAG of physical systems).

In case you have a DR cluster run the Veeam systems (virtualized) there, otherwise only present the primary backup VLAN to you primary cluster and run them there.

For the PAW: Run the first one on the primary cluster as well but put it in your server VLAN and open only the required ports to Veeam, install the VBR console there and use the firewall rules to get access to Veeam - the GUI and the console stays the same.

In case your cluster fails and you need to restore, you should have a second PAW in place - maybe a dedicated notebook or something like that which has prepared or active firewall rules (same as for the first PAW).

Hope that gives an overview. Please feel free to refer to one of my presentations on hardening and VLAN design - that might cover a lot of your questions:

Event Recap: Veeam Hardening Best Practices (March 19, 2025) | Veeam Community Resource Hub

Take care!

Lukas

Thanks Lukas! Just to be clear from a physical server perspective, how many would we need to set up the Backup Domain / Workgroup? You mentioned clustering so I imagine at least two physical servers outside of the production domain would be needed (not including the repositories) with all the Veeam servers and PAWs being virtualized?

I’d recommend simply using physical repository servers (Windows ReFS or Veeam Hardened Repo with Linux), virtual Veeam components and both a virtual and a physical PAW and you basically should be good to go.

Please keep in mind that you could extend the usage of physical servers in case your RTO requirements declare this.

thank you ​@lukas.k for sharing this.

Thank you ​@lukas.k for this video.  It is very informative.  Much like ​@StoopidMonkey, I’m in the process of redesigning my Veeam network for hardening and organizational purposes.  After watching your video, I have a few questions:

-Regarding internet limiting, you mentioned allowing access to Veeam domains, for updates and license check. (on Veeam components)  I’m assuming you also allow access to Windows Updates, correct?  Or is there a better practice for this?  (such as a Veeam-dedicated WSUS server)

-During my designing, I had planned to put the data ports of my hardened repo into a separate VLAN, yet I saw yours connected to the backup VLAN with the IPMI port(s) connected to a separate VLAN.  I understand that my design would send a lot of data through my firewall (where the segmentation occurs), but wouldn’t it be safer to have this layer of separation?

-Previously, I used a workgroup for my Veeam components and disabled the local admins, creating a separate admin for each server.  I ran into issues connecting to each component unless I applied the LocalAccountTokenFilterPolicy registry edit.  I then found that this issue could be rectified by using a domain for my Veeam components, which I had planned on doing.  After your comments and video, I’m second guessing going the domain route.  In your opinion, which option is safer?  Domain or applying the registry edit to each server/component?

-Last question.  Do you allow your PAWs to have full access to every Veeam component?

Thank you for taking the time to answer my questions.  I wish I had watched the video live, but your presentation would have gone well over the hour with all of my questions!!!

David

Hi ​@stryker54141,

To answer your questions:

1. You can use both a dedicated WSUS (but with SSL please) or open the internet ports but both scenarios open ports to you hardened design. I often work with WSUS offline which provides an ISO file that you can mount to the approptiate servers. Both works, the decision depends on your target level of security.
2. You can move the traffic to your VHR through firewalls but let me put it this way: The data ports have to be open either way and Veeam doen’t recommecnt IPS / IDS to be turned on - what would be your advantage of a dedicated firewall? I see a management overhead that isn’t neccessary and the file system is hardened either way but technically - if your firewall can handle the traffic - there is nothing agains you design.
3. By the time I don’t go with a domain since you have to harden you Veeam / management domain as well which can be a huge workload. You would have 2 domains that you have to apply to your security level since anyone compromising you Veeam DC might have full access to Veeam - same thing than a production domain but with a different domain name - but this is only my oppinion.
4. What do you mean with full access? I wouldn’t recommend to put it into your Backup VLANs so just put it into you production server VLAN and only open the required ports (RDP if applicable, HTTPS, Veeam console ports, etc.). Since this is the single point of access I do often open all ports that might be needed for administration (RDP) as well and put in the layer of security with user accounting, MFA and stuff.

Hope that helps! Just a hint: The presentation was a user request so to add another hour for answering questions was the goal - don’t worry next time!

Best

Lukas

Thanks again ​@lukas.k!

I have one final question.  You mentioned in the above comment having backup proxies in a single VLAN with the VBR, so I’m assuming you mean the backup VLAN from your presentation.  Is this correct?  I was under the impression that you should place your backup proxies on the same VLAN as your hypervisor(s).

You can do both. If you put your Proxy in the Production net you have to route traffic through a fw.

In case you can add the proxy to a SAN you could put it in the backup net to avoid fw handling.

Speaking of firewalls, do you see any issues with using software firewalls like those that come included with many anti-malware security agents? This would avoid issues where the hardware firewall can’t handle high speed 10Gbps+ connections.