vCenter Security Bug Workaround with vCenter Firewall Configuration

Recently we had one of the most significant security advisories that I can remember with vCenter Server. Compromising VMware vCenter Server is the holy grail of a vSphere environment for an attacker as it allows total control of the VMs and now, containerized environments housed therein. VMware vCenter Server security best practices recommend you have vCenter Server on a segmented network with limited access from any client subnet that may exist in the environment. In this way, you drastically reduce the attack surface of your vSphere environment. However, what if your vCenter Server management address is on a flat network? What if network segmentation is out of the question? There is still a way to introduce a vCenter Security bug workaround with vCenter firewall configuration. Let’s see how.

vCenter Compromise usually involves network access

When you look at most if not all the security bugs that have recently affected either vCenter or ESXi, most often it involves some type of network access by an attacker. This latest vCenter security bug is an extremely bad vulnerability since it only requires an attacker have access to port 443. This vCenter port is generally left unrestricted in most environments as it is the main communication port for management and accessing the vCenter APIs which are required by most solutions integrating with vSphere.

In many environments, vCenter Server is positioned on the same network as everything else, including other general-purpose servers, clients, printers, IoT devices, and other endpoints. Positioning your vCenter on the same flat network as everything else is a bad idea. It gives free reign to attackers who may come in on a compromised client and pivot across the network, including vCenter Server.

Flat network layouts that house vCenter Server may look something like below. Note, how an attacker, who as infected a laptop on the network is able to easily access vCenter Server.

Network segmentation

Segmenting your network has long been a security best practice. It allows separating critical server resources from dangerous client networks. Often, attackers invade networks due to a user visiting an infected website or opening a malicious email attachment that made it through email filters.

Separating management addresses, including vCenter management from the flat production network, including client operating systems pays dividends when it comes to security. Attackers will have a more difficult time trying to get at your business-critical management services. Network segmentation, at a high level, may look something like below. Even though the attacker has invaded the LAN segment, there is another firewall and filtering in place between the LAN and Management network. So, even if vCenter Server is vulnerable to a security bug, such as CVE-2020-22005, an attacker cannot easily capitalize on this vulnerability.

IT admins have rules set up to allow accessing vCenter Server using a jumphost located in the management network.

vCenter Security Bug Workaround with vCenter Firewall Configuration

What if network segmentation is not possible? Network segmentation is generally not something you can jump in and do one evening. There has to be thought put into the process and great care used in executing on a network segmentation plan. Failure to do so can lead to traffic disruption.

In flat networks, how can you introduce many of the same protections to vCenter without network segmentation? The vCenter Server firewall is a very underutilized feature in vCenter Server. It provides a very basic firewall that allows filtering traffic based on network IP. It provides protection to your vCenter Server on multi-client networks that are flat, lacking any segmentation.

vCenter Firewall Configuration

Let’s take a quick look at how to configure this in the vCenter Server firewall. The vCenter Server firewall is configured from the VAMI interface on port 5480. Browse there and click Firewall > Add.

The vCenter Server firewall rules are very basic and only provide the ability to add network IP address objects. However, this is sufficient for what we are trying to accomplish.

The vCenter Server firewall processes and matches rules from the top down. So if you want to allow traffic over other general blocked traffic, it must be moved higher in the list. As you can see below, I have a specific rule that is set to Accept and the general IP address subnet that is set to Reject. The Reject in this case will be matched first. We need to Reorder the firewall rules. Click the Reorder button.

Click the rule you want to reorder. You can choose a rule and either move it up or down. Here, I am moving the specific host rule above the general IP subnet Reject rule.

Once moved, Save the rules.

Now, the rules are set appropriately to allow access from a specific IP address and block all other traffic from the subnet.

vCenter Server Firewall Rules How to Video

Take a look at my video below, detailing the process we have described in the blog post and effectively allowing and disallowing traffic to provide additional vCenter Server security.

Wrapping Up

Securing vCenter Server is absolutely critical. While network segmentation is the absolutely recommended approach to securing network resources among others, using the vCenter Server firewall provides a quick and easy way to secure vCenter Server network access on flat Layer 2 networks found in many SMB environments. The tool is often underutilized in my opinion and is a great tool for security.