Avoid high-risk data commingling with VMware virtual networks to prevent security vulnerabilities

Running VMware in an environment that involves converged networks causes data commingling, which, although intrinsically harmless, can be harmful if the wrong data is commingled. Network convergence happens because not many people use 100% of a 10 Gigabit Ethernet network bandwidth; many people do not even use the full bandwidth of a 1 Gigabit Ethernet link. The goal is to use the unused bandwidth for other aspects of networking as laying new cable is often not possible due to a lack of network interface cards (NICs), and it's expensive and time consuming.

The simple solution is to often run more over the wire than just one item, also known as data commingling. Data commingling is not a security issue per say, as long as the data on the wire shares the same classification level and security zone. Data commingling can become a problem, however, when data on the same wire isn't of the same classification level and security zone.

Classification levels define who can see any data that lives on the wire, while security zones cover to where the wire is connected and possibly how it is used. For example, a DMZ tends to be a hostile environment compared to the security zone named production. Commingling the data in these two zones will raise the level of risk that normally exists without data commingling on a converged network.

With virtualization there are at least four possible networks for each VMware ESX host: the service console or management appliance, the storage network, the VMware VMotion or Storage VMotion network and the virtual machine network. There are also at least four other distinct security zones: hypervisor, virtual machines, storage and management.

How to properly commingle networks and security zones
Which networks and security zones can be combined depends on many aspects, but to simplify matters we will ignore hardware restrictions and go with the current thoughts on why various security zones and networks should remain separate. It is not that I do not like VLANs, but VLANs do not grant security. VLANs are a tool used within a network (physical or virtual) to ensure a packet is delivered to the proper port -- not a method to secure a network.

In recent VMware Communities discussions the term "secured with VLANs" is very popular. There is no mention of security within the 802.1q Request for Comment (RFC). VLANs do not grant security, but they can be used securely. In order to use converged networks securely, however, a few items need to be discussed.

• Any access to the hypervisor through a network connection either directly (vmkernel vNICs) or indirectly (management appliance and applications) should be strictly controlled. Access to the hypervisor is at risk for granting access to everything within the VMware ESX/ESXi host.

• Any access to the VMotion network raises the risk that credential and identity data from within a VM can be discovered as the VM's in-use memory is transferred over the wire in clear text.

• Any access to the storage network either from a VM, backup server, or indirectly through the hypervisor and management tools should also be strictly controlled. Access to the storage network raises the risk that the contents of virtual disks of the VMs could be discovered as the storage network is accessed in clear text.

Best practices
Given all this information, what is the best suggestion for virtual networking with converged networks? Ideally you would not converge any of the networks within the VMware ESX/ESXi host, but that is not necessarily practical. You may be able to not converge the networks from the VMware ESX/ESXi host to the physical switches, but from there they would be trunked to travel through other physical switches of the entire company switching fabric.

The weak point in the switching fabric may actually be the physical network as the virtual switch does protect against the current Layer 2 VLAN attacks, although not from Layer 3 attacks. Not all physical switches protect from Layer 2 VLAN attacks, however.

Often people commingle data from the VMware ESX/ESXi host management appliance and VMotion on the same cable, considering both to be at the same level of risk as any other network. VMotion is the network with the highest risk. If a person can break into the management appliance of the VMware ESX/ESXi host, however, they could gain access to all the disk data, but not necessarily the VMotion data. If these two are on the same wire, however, there is a higher risk level.

The other data that is often commingled is storage data and virtual machine (VM) data. In other words, the VM can see the same storage that the ESX hosts can see. If the VM is not a storage management node or another form of management node, this also could cause a higher risk to the virtualization environment in the event of a security breach.

At the moment there is no good way to mitigate these issues. VMware ESX and ESXi do not currently support Internet Protocol Security (IPsec). IPsec with pre-shared keys and a good public key infrastructure could allow strong encryption of all data on the converged network using different keys based on source. This would lower the overall risk.

Choosing which networks to converge requires intimate knowledge of the data to be transferred, to where the data will go, how it will travel, encryption possibilities, and the risks associated with this data getting into the wrong hands. Keep the information that I've presented in mind, however, and you should be in good form.

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.