Five VMware security breaches that should never happen

VMware security breaches should not be taken lightly, especially now that there's a spotlight on regulatory compliance and the shift toward cloud computing.

Virtual hosts house many workloads, and if an unscrupulous individual gains unauthorized access to a host, that person can potentially compromise all of its virtual machines (VMs). That means virtualization administrators should pay special attention to preventable VMware security breaches. There are several potential weak points where VMware security breaches can occur .

Making VMware security less like Swiss cheese
Out-of-the-box, VMware vSphere is fairly secure, but you can make it more susceptible to security breaches if you're not careful with its configuration and remote-access settings.

By default, VMware disables many features that would make administration easier, and enabling these features weakens security. In ESX, for example, administrators typically enable Web user interface. And in ESXi, many IT pros allow access to the remote console through Secure Shell (SSH) connections. These actions may make your job easier, but they open up attack vectors for unauthorized individuals.

An even bigger vulnerability is the host's management console. It's the door to your entire virtual infrastructure, so don't pass out many keys. Lock up the management console tightly and use it only when absolutely needed -- which typically isn't often. Other areas of concern are VM data stores, management and storage network traffic, virtual networking, application programming interfaces, VM-host interconnects, vCenter Server roles and permissions and third-party add-ons.

The bottom line: Know your weak points and make them secure.

VM portability leads to VMware security breaches
The portability of VMs increases the chance of theft, but these security breaches are easily avoidable if you have a strong backup strategy.

Virtualization encapsulates an entire server -- the operating system, application and settings -- into a single virtual disk file. Encapsulation is a strength of virtualization, but it can easily be a weakness.

To steal a physical server, an attacker needs to physically enter a data center and carry out the machine. But a whole VM can be copied out of the data center over the network and transported away on a portable storage device. Once someone has a copy of a virtual disk file, he can easily mount it to access the file system, or start it up on any workstation, using a tool such as VMware Player.

To prevent these types of VMware security breaches, you must protect the data stores where your VMs reside at both the physical-storage and host levels. Make sure the storage network is properly secured and that only the vSphere hosts have access to the VM data store logical unit numbers.

Common tools, such as the management console or the vSphere Client, can copy VMs off a host. Remove permission to read files using the Datastore Browser in the vSphere Client and limit who can access the management consoles. Also, if you use a disk-to-disk VM backup application, properly secure your backup repositories, because entire VM images are kept there.

Preventing VMware security breaches over VLANs 
VM networking configurations are easy to change, which can lead to security breaches if the proper precautions are not taken.

If you move a physical server between virtual local area networks (VLANs), you typically work with your networking group to change the VLAN in the switch-port configuration. Virtual hosts generally use VLAN tagging, which means a single physical-switch port supports multiple VLANs. The VM's virtual network interface card (vNIC) is then configured to use the multiple port groups on a host. The host's virtual networking makes it easy to move a VM between VLANs by editing the VMs settings and choosing a new VLAN for the vNIC.

This design means anyone who can manage that VM can easily move it from one network to another, or make it part of multiple networks by adding multiple vNICs. As such, someone could move a VM from a secure network to less secure one (e.g., from an internal network to a DMZ, where it would be exposed).

It is also possible for a VM to bridge two virtual networks, creating a path for an attacker from an outside network to your internal network. To prevent these security breaches, lock down the permissions required to change VMs' virtual networking settings. Preferably, network administrators should only have these privileges, not the server or application administrators who own the VM.

Avoiding VMware security breaches through isolation 
When virtual infrastructure traffic travels along the same physical network as storage and management data, it opens your VMs up to potential security breaches. Not all traffic between these endpoints is encrypted, so anyone with access can sniff the data on the wire, including sensitive information transmitted to storage devices and data that's in a host's memory when vMotions occur.

Without traffic isolation -- which adds a layer of protection for core traffic among hosts, storage devices, vCenter servers and administrators -- you risk your private data being stolen out of mid-air. You should isolate a lot of the virtual infrastructure traffic that travels over the physical network. Keep management and storage traffic, for instance, on a physically isolated network that's away from the regular VM network traffic.

This practice includes the networking for the ESX service console, ESXi management console, VMkernel and vCenter Server. These components communicate heavily with each other and have limited outside network connectivity needs.

Use a firewall to guard the private network so it allows only authorized traffic for administration, domain name services, updates and other actions. Most of the traffic is encrypted, but isolation adds an extra layer of defense against security breaches. VMotion traffic is not encrypted, for example, and the host's memory content is sent in plain text whenever a VM moves from one host to another.

Also, physically isolate any network-based storage traffic (e.g., iSCSI and Network File System) from the host to the storage devices. For iSCSI, secure it with the bi-directional challenge-handshake authentication protocol to prevent unauthorized connections. Isolation not only protects storage traffic, but it can also improve performance and reduce contention with other devices on the network.

Improving VMware security with user accounts
Safeguard the root account for the ESX service console and ESXi management console. If it's compromised, everything on the host -- including the virtual machines -- are compromised as well.

The ESX service console and ESXi management console run variants of a Linux operating system. As such, they have a root account, which is the super-user account with full permissions. Use the root account as little as possible, and create a less-privileged account for each user, which will also provide an audit trail that shows the usage of each account.

In ESX, you can setup sudo to grant specific privileges to user accounts, without granting full access. In both ESX and ESXi, you can use the su command to temporarily grant super-user privileges to an account.

By default, the root account cannot remotely log in to the console from a SSH connection. Even though you can easily enable root access through SSH, you shouldn't do it. VMware disabled it for a reason. You can also setup Active Directory authentication for console access, rather than individually managing local user accounts on each host.

In the end, protect your root account. Change the password regularly, and limit its use as much as possible.