Good Fences, Good Neighbors: Isolating Infrastructure Management

(Day 20 of 22 in our Cybersecurity Awareness Month series. Today: isolating the management network)

Robert Frost’s poem “Mending Wall” gave us the line “good fences make good neighbors,” though the poem itself is actually skeptical of the idea. Infrastructure security needs no such skepticism. The management network, where vCenter, ESX, NSX, and the rest of the VMware Cloud Foundation (VCF) management components live, holds the keys to everything running on the platform, and it deserves a good fence.

Why Attackers Go After the Management Network

An attacker who reaches the management network can do in minutes what would otherwise take weeks: encrypt every VM at once, copy domain controllers, delete backups, and stay out of sight of the security tools running inside the guests. Threat intelligence reports say it outright: ransomware operators actively target backup infrastructure, identity services, and virtualization management planes, and virtualization and management platforms need to be treated as Tier 0 assets (Google’s M-Trends 2026 report).

The paths in tend to look alike:

• Management interfaces exposed where they shouldn’t be. One ransomware campaign compromised more than 3,800 internet-exposed, unpatched hypervisor hosts around the world (CISA and FBI). Without further defense-in-depth, a vulnerability is easily exploited, and stolen credentials are easily used.
• Flat networks. Threat researchers describe attackers moving from a help desk call to Active Directory, to vCenter, to ESX, to ransomware “in mere hours” (Google Threat Intelligence Group report). Each step was easier because the next system was reachable from the last one.
• Unrestricted outbound access. Attackers have planted backdoors on management appliances that call out to the internet for instructions, and investigators recommend that appliances not have unrestricted access to the internet (Google Cloud blog).

Good isolation won’t stop every attack, but it takes away the shortcuts and makes attackers much more likely to get caught.

What Belongs on the Management Network

In VCF, the management network holds vCenter, NSX Manager, SDDC Manager, VCF Operations and its related components, fleet management, VCF Identity Broker, and VCF Automation (management appliances), along with the ESX management interfaces and the VCF management services. Add the things those components depend on, like DNS, NTP, key servers, backup targets, and log collectors. Server hardware management controllers belong on the list, too, which we talk about below.

VCF’s design guidance separates these further. ESX management traffic gets its own VLAN, apart from the other management components, and each workload domain gets its own ESX management VLAN (ESX design). Each host’s management VMkernel interface belongs on that dedicated segment, with other VMkernel interfaces carrying only their own traffic. That way, “an intruder on a non-management segment cannot directly initiate a management session against the host” (VCF Security Configuration Guide).

Build the Fence

Separate networks are a start, but VLANs by themselves don’t provide isolation. Broadcom’s ransomware design guidance puts it well: several VLANs may still allow one administrator, jump host, or broad firewall rule to reach everything, and “that changes the diagram more than the risk” (ransomware design). The fence is the firewall policy between those networks.

The VCF Security Configuration Guide says management interfaces should be reachable “only from the networks administrators use, not from general user or workload networks and not from the internet.” Administrators should connect from an authorized network or through a jump host. Build that with a perimeter firewall around the management network, and then tighten the gates on each component:

• Restrict the ESX firewall. By default, the firewall rule for each ESX service allows access from any IP address. Change each service to allow only your management networks (docs).
• Use lockdown mode. Normal lockdown mode routes host management through vCenter. It doesn’t turn off SSH or the ESX Shell, so keep those services stopped, and reserve the Exception Users list for service accounts (lockdown behavior). Be careful with strict lockdown mode: if vCenter is lost and no other path was prepared, recovering a host may mean reinstalling it (KB 336894).
• Use the appliance firewalls carefully. The vCenter appliance firewall filters inbound traffic by source address, for all ports at once (tech docs), so add a rule for your administrative networks first, or you can lock yourself out. It doesn’t filter outbound traffic, which is a job for the perimeter firewall.
• Turn on VCF Operations firewall hardening, which limits traffic between cluster nodes and is off by default.
• Remove what you don’t need. Power off or remove the VCF Installer after bring-up, unless it became SDDC Manager, because it holds bring-up credentials and would otherwise just be another thing to patch and maintain.

Don’t Forget the Basement Door

Every server has a hardware management controller, often called a BMC, that provides remote console, power control, and firmware updates, and it keeps working even when the server is powered off. NSA and CISA call the firmware in these controllers “highly privileged,” warn that attackers could use them to disable security features like the TPM, and recommend isolating BMC network connections (NSA and CISA). Attackers are paying attention, too; CISA has added an authentication bypass in a widely used BMC firmware to its catalog of known exploited vulnerabilities (CISA).

Our post on hardware security covers these controllers in more depth. For the management network, the VCF Security Configuration Guide recommends treating them as Tier 0:

• Put them on a dedicated management interface, or at least an isolated VLAN, reachable only from authorized administrative addresses.
• Turn off services you don’t use, like IPMI over LAN, and require TLS 1.2 or later, and TLS 1.3 where the controller supports it.
• Don’t authenticate BMC users against an Active Directory that runs on the same hosts the BMCs can power off. It’s a dependency loop, at best, and connections to identity providers are also attack paths.
• Lock the configuration after provisioning, forward the logs, and sync the time.

Control the Way In and the Way Out

The way in. Administrators should reach the management network from a small number of controlled places. Microsoft’s guidance on privileged access workstations, dedicated devices for administration that don’t do email or web browsing, applies to infrastructure administrators as much as anyone (Microsoft). If you use jump hosts, remember that a jump host many sensitive sessions pass through is a target in its own right. Microsoft’s tier model treats a jump server used to reach domain controllers as a Tier 0 asset (tier model). NSA’s guidance on out-of-band management goes further, calling physically separate management infrastructure the most secure design (NSA).

The way out. Management components need very little from the internet, so give them very little. VCF needs to reach a short list of Broadcom URLs on port 443 (public URLs). Send that traffic through a proxy, and block the rest. A few options make it easier:

• Use a proxy. VCF Operations, SDDC Manager, and vCenter all support proxies, and TLS-inspecting proxies work with some extra configuration, like importing the proxy’s CA certificate.
• Use an offline depot. The VCF Download Tool fills an offline depot from a system with internet access, and one depot can serve multiple VCF instances (tech docs).
• Turn off defaults that call out. For example, vCenter downloads the vSAN hardware compatibility list directly from the internet unless you turn that off or send it through a proxy.

Broadcom’s guidance on the BRICKSTORM backdoor recommends restricting outbound internet access from vCenter and ESX (KB 427833). An appliance that can’t call out is much less useful to an attacker who has compromised it.

Good Fences Make Good Management Networks

Isolation isn’t glamorous, and it rarely shows up in a product demo. It’s also one of the most effective things you can do for infrastructure management. Know what lives on the management network, put a real firewall around it, tighten the gates on each component, give the hardware controllers their own fence, and control the ways in and out.