There is an education gap between security administrators and virtualization administrators that must be filled. Security administrators do not always fully understand
the virtual infrastructure. Virtualization administrators do not always fully understand security. This often leads to insecure virtualization server deployments: It’s even more of an issue
when virtual machines are placed within the network DMZ.
Often there are hard and fast rules that tell IT what can be done within a DMZ —the exposed portion of a corporate
network, which might contain Web, FTP, SMTP and other servers that need open access to the Internet.
Typical of these is a rule banning systems with more than one network connection. Such multihomed systems are favorites of
hackers for the easy access they provide to other potentially vulnerable machines. Typically only switches, firewalls or
other networking devices are permitted multiple network connections.
However, when this rule is applied to machines supporting virtual servers, you run into some serious concerns, and you could
open your network up to further attack.
I would keep all virtual servers as far away from the DMZ as I could physically put them, whether they’re running XenServer,
VMware Server, Microsoft Hyper-V, or any other form of virtualization.
All qualify as targets for a security administrators fears. But if you’re using VMware ESX or VMware ESXi, the reason for
that fear is less substantial.
The reason is the virtual switch, which only VMware ESX and VMware ESXi, of all the major virtualization products, currently
The virtual switch works just like any other Layer 2 switch—moving network traffic to and from specific virtual
machines in exactly the way a physical switch does.
Virtual switches have a few other important capabilities; they limit IP and MAC address spoofing, disable promiscuous mode,
which disables wire tapping, and they support VLANs (called portgroups within VMware ESX). Virtual Switch support for VLANs
currently prevents all currently documented VLAN attacks.
The virtual switch’s greatest impact is that it provides a defined path from each virtual machine in the DMZ to the physical
switch in the DMZ via an uplink. This allows the VMs to communicate with the outside world. The VMs on the DMZ virtual switch
have no access to any of the other virtual switch defined within the host, unless the administrator purposefully bridges the
virtual switches. The average VMware ESX host has 3 defined virtual switches.
These defined virtual switches, which cover other critical components (namely the Service Console management appliance,
Storage, and vMotion) have their own virtual switches that are 100 percent separate and segregated from the DMZ virtual
switch. These networks should be connected to the internal network and not the DMZ.
This level of protection makes it impossible for a network attack against the DMZ to pivot directly to any other network on
the ESX server unless an administrator purposefully creates a misconfiguration.
Security administrators need to understand the impact of virtualization and be ready to combat any attack on a virtual
machine, just as they do for physical machines.
Yet, they cannot ignore the fact the VMware ESX and VMware ESXi provide networking functionality designed to match old-school
expectations of physical equipment, but in the virtual space. Security and network administrators need to stop thinking of a
VMware ESX host as just a box, and start treating it as a data center whose networks should be managed, monitored and
If you do not, and you allow a virtualization server within your DMZ, it is most likely has been configured without
safeguards that will keep virtual machines from connecting to the vital networks that should have no direct connections to
anything within the DMZ.
If this sounds like your approach, stop, disconnect all cables and start over; you are definitely insecure and courting
Virtualization expert Edward L. Haletky is the author of “VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers,” Pearson Education (2008.) He recently left Hewlett-Packard, where he worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Haletky owns AstroArch Consulting, providing virtualization, security, and network consulting and development. Haletky is also a champion and moderator for the VMware discussion forums, providing answers to security and configuration questions.