There is an education gap between security administrators and virtualization administrators that must be filled. Security administrators do not always fully understand \n\nthe 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 \n\nwhen virtual machines are placed within the network DMZ.\n\nOften there are hard and fast rules that tell IT what can be done within a DMZ \u2014the exposed portion of a corporate \n\nnetwork, which might contain Web, FTP, SMTP and other servers that need open access to the Internet. \n\nTypical of these is a rule banning systems with more than one network connection. Such multihomed systems are favorites of \n\nhackers for the easy access they provide to other potentially vulnerable machines. Typically only switches, firewalls or \n\nother networking devices are permitted multiple network connections. \n\nHowever, when this rule is applied to machines supporting virtual servers, you run into some serious concerns, and you could \n\nopen your network up to further attack. \n\nI would keep all virtual servers as far away from the DMZ as I could physically put them, whether they're running XenServer, \n\nVMware Server, Microsoft Hyper-V, or any other form of virtualization. \n\nAll qualify as targets for a security administrators fears. But if you're using VMware ESX or VMware ESXi, the reason for \n\nthat fear is less substantial. \n\nThe reason is the virtual switch, which only VMware ESX and VMware ESXi, of all the major virtualization products, currently \n\nsupports. \n\nThe virtual switch works just like any other Layer 2 switch\u2014moving network traffic to and from specific virtual \n\nmachines in exactly the way a physical switch does. \n\nVirtual switches have a few other important capabilities; they limit IP and MAC address spoofing, disable promiscuous mode, \n\nwhich disables wire tapping, and they support VLANs (called portgroups within VMware ESX). Virtual Switch support for VLANs \n\ncurrently prevents all currently documented VLAN attacks. \n \nThe virtual switch's greatest impact is that it provides a defined path from each virtual machine in the DMZ to the physical \n\nswitch in the DMZ via an uplink. This allows the VMs to communicate with the outside world. The VMs on the DMZ virtual switch \n\nhave no access to any of the other virtual switch defined within the host, unless the administrator purposefully bridges the \n\nvirtual switches. The average VMware ESX host has 3 defined virtual switches.\n\nThese defined virtual switches, which cover other critical components (namely the Service Console management appliance, \n\nStorage, and vMotion) have their own virtual switches that are 100 percent separate and segregated from the DMZ virtual \n\nswitch. These networks should be connected to the internal network and not the DMZ.\n\nThis level of protection makes it impossible for a network attack against the DMZ to pivot directly to any other network on \n\nthe ESX server unless an administrator purposefully creates a misconfiguration.\n\nSecurity administrators need to understand the impact of virtualization and be ready to combat any attack on a virtual \n\nmachine, just as they do for physical machines. \n\nYet, they cannot ignore the fact the VMware ESX and VMware ESXi provide networking functionality designed to match old-school \n\nexpectations of physical equipment, but in the virtual space. Security and network administrators need to stop thinking of a \n\nVMware ESX host as just a box, and start treating it as a data center whose networks should be managed, monitored and \n\nassessed.\n\nIf you do not, and you allow a virtualization server within your DMZ, it is most likely has been configured without \n\nsafeguards that will keep virtual machines from connecting to the vital networks that should have no direct connections to \n\nanything within the DMZ. \n\nIf this sounds like your approach, stop, disconnect all cables and start over; you are definitely insecure and courting \n\ndisaster.\nVirtualization 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.