Enabling promiscuous mode port groups compromises security within VMware virtual infrastructures. Many network security tools such as Blue Lane, Catbird and Reflex Systems, however, require them to be enabled. In addition, some new tools that inspect network packets, such as VMware vCenter AppSpeed, require promiscuous mode settings to be enabled.
These programs also require you to set the VLAN ID to 4095 for the port group. This special VLAN ID is used to pass data direct to a virtual machine (VM) without interpretation by the VLAN processing within the vSwitch, which is often used to perform virtual guest tagging (VGT). This port group setting, however, will also allow promiscuous mode VMs to see all packets as they traverse the vSwitch regardless of VLAN. If the VLAN ID for the port group is not set to 4095, a promiscuous mode Ethernet adapter can only see the data for the specific port group, not the entire vSwitch.
But how do you do this securely? How do you enable a promiscuous mode port group and keep everything else off of it? This is a tricky problem as the granularity of protections for moving VMs from one port group to another does not exist within the current release of VMware ESX or ESXi. There are several ways to move a VM from one port group to another.
- Edit the VMX file by hand for the VM while the VM is powered off, either directly on the virtual machine file system or by using the remote command-line interface VIFs tool to get the original file and put the modified file back on the system.
- Use VMware Converter or another tool to perform a virtual-to-virtual conversion.
- Connect to VirtualCenter (now known as vCenter Server) with the VMware Infrastructure Client (VI Client) to make the modification.
- Connect to the host VM with the VI Client to make the modification.
With so many ways to move a VM to a promiscuous mode port group, security comes down to trust as well as some roles and permissions settings.
Security, specifically with a security setting without a control that prevents a fellow administrator from doing something destructive inadvertently (or on purpose), requires trust in the other administrators. In addition to trusting other sys administrators, you need to audit your infrastructure more frequently to catch these possibilities. Unfortunately, there are no alarms within the virtual infrastructure that can be set to monitor for these issues, so you need to either rely on manual monitoring or third-party tools.
Since each of these actions requires administrative access, the virtualization administration network where vCenter, the management workstation and the VMware ESX Management appliances (service console and VMware ESXi management appliance) reside should be behind its own firewall. That way, you can control which workstations can access the infrastructure management tools and which can not, as well as how they can be accessed. Ideally you would want administrators to use a VPN to access their internal-to-the-virtualization-administration-network VMs. This way, normal, every day workstations do not need to be within this network and there would be limited vision to this network from any other network. In other words, protect the virtualization administration network like you would protect your data center: with as many controls as necessary. This type of setup may also help with remote access to the virtualization hosts as well.
What about remote consoles?
Since some of the changes can happen via the console as well, it is important to also protect remote consoles (Integrated Lights-Out, Dell Remote Assistance Cards, etc.,) from access. Remote consoles should be on another firewalled segment of the network.
VMware Converter is one of those tools that could bypass your security with ease, so the only mitigation is to increase your auditing.
Roles and permissions
The last control to put into effect is to limit who can modify the network on which VMs can reside. Set permissions for the non-administrative roles to control these possibilities:
- Host, then Configuration, then Network Configuration
- Host, then Configuration, then Change Settings
- Virtual Machine, then Interaction, then Device Connection
- Virtual Machine, then Configuration, then Add or Remove Device
- Virtual Machine, then Configuration, then Modify Device Settings
- Virtual Machine, then Configuration, then Advanced
Unfortunately, these changes will not ultimately prevent the movement of a possibly hostile VM to the promiscuous mode port group, but it will decrease the possibility. However, nothing can replace auditing changes to your infrastructure on a regular basis. Several companies have products that do this: Tripwire and Configuresoft. Other companies have tools to prevent traffic to and from the VM in question by placing a virtual jail around the VM: Catbird and Reflex Security.
No matter which tool you choose, the use of promiscuous mode enabled port groups implies the need to increase auditing and your own diligent observations.
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.