Virtual Servers in the DMZ Pose Security Risks

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 supports.

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 assessed.

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 disaster.

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.