The key to placing a VMware ESX or ESXi host into the DMZ is to realize that it is a hybrid network and compute resource instead of a single operating system or appliance, and gauge whether or not a virtual machine should exist within the DMZ accordingly.
Most security administrators will not allow multi-homed systems into a DMZ. Multi-homed implies a system that connects to multiple networks at the same time. The fear is that these systems would then act unknowingly as a bridge between security zones outside the predefined firewalls, routers and gateways the security teams have already setup.
With VMware ESX or ESXi this is not the case. Inside the hypervisor is a Layer 2 virtual switch that behaves very similarly to a Layer 2 physical switch. Given that virtual switches exist and that virtual switches can not talk to each other unless, as with separate physical switches, there is some system bridging the gap. VMware ESX and ESXi do not act as such a bridge but maintain the virtual switch as its own entity.
There are at least four possible networks for each VMware ESX host: the service console or management appliance, storage network, VMware VMotion or Storage VMotion network, and the virtual machine network.
The first three networks are critical networks and they should never reside within a DMZ. The last network is the one that can reside within a DMZ.
Many people agree that it's a best practice not to place the first three networks within the DMZ, but do not give reasons for this. Here are some that I use; these are all predicated upon the fact that the DMZ is a hostile environment under constant threat and possible attack that once breached could be used to pivot attacks further into protected networks.
The service console or management appliance is the door to the kingdom and lives within its own portgroup on its own vSwitch. On this network all the administrative tasks occur which often includes credential information for logging into each system. Access to this network, while often protected by SSL, could grant the attacker the chance to infiltrate the virtual environment at the most basic level, and the chance to steal data unnoticed goes up considerable. (By data, I mean virtual disk files and contents.) Furthermore, it provides an avenue to directly attack the user accounts on the VMware ESX or ESXi host, which could give the attacker access to everything.
The storage network is another important network that often lives on its own vSwitch. All current protocols for storage send data across the wire in an unencrypted fashion. Access to this network could gain the attacker access to virtual disk data. Furthermore, if iSCSI is in use, this could present another attack point to the service console or management appliance as they must participate with the iSCSI network.
VMotion and Storage VMotion networks
VMware VMotion and Storage VMotion networks are also often on their own vSwitches and pass, in clear text, memory and disk contents of a VM across the wire. This network is one of the most dangerous to place in an unsecured location as the attacker could gain access to the memory of a virtual machine as well as the disk contents. Given this information, the attacker could then gain access to credential information and further pivot attacks into your network using the credentials gathered.
Virtual machine networks
Access to the virtual machine network does not have the same threats as access to the other networks.
Further reading includes the following documents from VMware. I find these documents to be incredibly important as a starting point before placing VMware ESX and ESXi hosts into a DMZ.
- VMware whitepaper on virtual networking concepts
- VMware whitepaper on VMware ESX 802.1q VLAN solutions
- VMware whitepaper on iSCSI design and deployment
- VMware whitepaper on placing a VMware ESX host within a DMZ
ABOUT THE AUTHOR: Edward L. Haletky is the author of VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers. He recently left Hewlett-Packard Co., where he worked on the virtualization, Linux and high-performance computing teams. Haletky owns AstroArch Consulting Inc. and is a champion and moderator for the VMware Communities Forums.
This was first published in December 2008