Securing Vembu Backup Server -Part05

Segmentation of Vembu Backup Server

This the concluding post of Five Part series. Previous posts are Part01, Part02, Part03 and Part04. If you are with me for all these 5 parts I assure you that you would have learned at least something.

The planning for Segmentation for the workload is considered much before we choose to deploy to Vembu Backup Server (VBS). This topic has network security element involved. In Virtualization world, VLAN is our starting point especially trunk VLANs for segmentation. We also recognize we have to limit access to this server from the network aspect. At the network level, you need to deploy a VBS in dedicated Backup VLAN. But this just one viewpoint. Here is the break down who all needs to communicate with VBS

VBS needs to communicate with

  1. ESXi host (for Data transfer)
  2. vCenter (to initiate backup)
  3. Agent (In case of physical server backup)
  4. Jump Server (for management)

Jump server might catch your attention. We need a central server dedicated for Administration of your virtual infrastructure not only backup server. Jump Server design is a much bigger topic, which I’m planning to cover in future. As the saying goes you are as strong as your weakest link. Therefore, if Jump server is compromised so is your entire network. I’m describing below an approach I feel positive but I’m undoubtedly convinced there are other methods of achieving network security for VBS.

We need at least 3 VLAN to segment VBS.

  1. VLAN for ESXi management traffic
  2. VLAN for VBS
  3. VLAN for Jump Server

VLAN for Jump Server will be Out of Band (OOB) VLAN to manage entire infrastructure. OOB VLAN would need access to all servers in your infrastructure. For the scope of this blog, VBS VLAN should have access to or should be accessible from

  1. Jump Server (will be used to log into VBS)
  2. ESXi Host
  3. vCenter
  4. All Virtual & Physical Machines

To achieve 4th point, all Virtual & Physical Machines must have additional network card mapped to same VLAN/Network where VBS is residing. Below is the illustration of how it would look logically

Figure 1 Segmentation of VBS and its dependent servers

Now that we have segmented networks we still have to do some work. All these VLANs must communicate with each other but do they have to access everything? Of course, the answer is NO. As the first step, we need to have all traffic marked towards the firewall. That is achievable when you all these VLANs have Firewall as the default gateway. In our case router will act as a default gateway. This router will also do the added function of firewalling.

To explain next section, I have allocated subnet to all the VLANs in the scope. This will aid me in demonstrating the concept in the much better way.

VLANs IP Segments
OOBand VLAN 192.168.10.x
Backup VLAN 192.168.20.x
ESXi MGMT VLAN 192.168.30.x
Virtual & Physical Server VLANs 192.168.x.x

Referring Vembu Installation guide, VBS needs to communicate with vCenter on TCP Port:443. Post that communication, VBS needs to transfer data from ESXi host on port TCP: 902. These are the essential requirement for backup to kick in. Then there are additional ports which are required for communication between Vembu Web Server and Vembu Backup Server. As both the components are on same server TCP:32005 is not required to be opened. TCP:32004 is the port required to be opened on all Virtual & Physical servers if VembuBDR client is installed. Finally, TCP:6061 is Apache Web Server SSL port which has to be opened to allow managing backup policies from the Jump Servers. I have put across 4 firewall tables below with source and destination servers.

Vembu Backup Server vCenter
Source IP Source Port Destination IP Destination Port Any TCP 443

Table 1 Firewall Ports are required to be opened between VBS and vCenter

Vembu Backup Server ESXi
Source IP Source Port Destination IP Destination Port Any TCP 902

Table 2 Firewall Ports are required to be opened between VBS and ESXi hosts

Vembu Backup Server Physical Servers
Source IP Source Port Destination IP Destination Port Any 192.168.x.x TCP 32004

Table 3 Firewall Ports are required to be opened between VBS and Physical Servers

Jump Server Vembu Backup Server
Source IP Source Port Destination IP Destination Port Any TCP 3389,6061

Table 4 Firewall Ports are required to be opened between Jump Server and VBS

Below at logical level, I have illustrated the firewall ports and sections it needs to be opened for the successful running of the backup server.

Figure 2 Firewall ports and logical flow of traffic

I have used windows firewall to enable above firewall rules. In below screen grab, I have allowed incoming 6061 TCP port on VBS. Jump server  IP Address is

Figure 3 SSL Port for Apache Web Server

In the below screen, I have chosen the only server which has Domain profile will be allowed to access the Vembu Back Server. This profile is pushed when the server is part of the domain.

Figure 4 Domain profiles ensure only VM joined to a domain is allowed

Finally, I’m narrowing down to scope to the IP Address of Jump Server. Since my lab does not have a firewall, I have not used the same IP Subnet scope as was described in the numerous firewall table described above.

Figure 5 Restrict access to Jump Server


In this post, I have described how VBS can be segmented and secured using firewall rules. I must emphasize this is just one of the many approaches to secure the access to VBS. This post also concludes the 5 series post I have written on how to secure Vembu Backup Services. In spite of covering 5 posts, I still see there is scope for further hardening and restricting access to VBS. To list few are

  1. Restrict console access to VBS using vCenter
  2. Use RBAC model and assign the specific role to the backupsvc account. I can use the backupsvc account to register vCenter
  3. Use Local Administrator Password Solution (LAPS) to control local administrator password of VBS

Hope you enjoyed it. In case you wish to review/go through other parts here are those Part01, Part02, Part03 and Part04