Virtualization Strategies for the CIO
As I've mentioned in other tips that I have written, I consider all virtual machines (VMs) to be hostile to the virtual environment. Virtual machines pose a threat to storage networks, management appliances
Requires Free Membership to View
and hypervisors.The problem arises when virtual machines access
a storage device that is also being accessed by virtualization hosts using storage capabilities
such as a network file system over a transmission control protocol, iSCSI, Fibre Channel over
Ethernet or a Fibre Channel host bus adapter supporting N_Port ID Virtualization.
Storage networks can also become attack vectors when the storage for the hypervisor is shared with other -- sometimes hostile -- devices. In this tip, I'll highlight the configurations that could open up your environment to outside attacks through storage networks, and discuss why you should keep your hypervisor and virtual machine storage separated.
Virtual machines that share a storage device with the hypervisor
If some of your virtual machines share storage devices with the hypervisor, there is a higher risk
of VMs acting as attack points to gain access to data that only virtualization hosts should access,
like virtual disk files. In some cases, the VMs may even be able to see all of the other virtual
machine and host traffic for a given storage device.
Most storage security relies on IP addresses, which are very easy to spoof, or challenge handshake authentication protocols which are usually not enabled. For example, let's say there are five VMs speaking NFS to the same NFS server as the virtualization hosts. There are now five-times as many attack points available than normal. NFS is one of the least secure file sharing protocols as it's susceptible to several types of attacks. What would be the risk to your organization if an attacker could gain access to those VMs and thereby gain access to VMDK files?
Pivot attacks
You may think you're not susceptible to the attack I outlined above. Your firewall and DMZ protects
you from this sort of thing right? Well unfortunately, they only protect you to a certain point. A
professional penetration test will show where you have weaknesses that need bolstering. If there is
a weakness in an external facing host, the host could be compromised and the attacker could then
upload their own tool suite and use that host as a way to pivot an attack further into your
network. The attacker would use as many pivots as necessary to achieve his or her aim. Unless, a
machine is "off the network," it could be accessible through pivoted attacks.
Multiple management appliances connected to storage
Another area of potential weakness is the use of multiple management appliance ports: one for any
management appliance (hopefully only on a management network), and another on the storage network.
This secondary management network link creates another attack point through the storage network
into your management appliance. Access to the management appliance could allow access to
everything. A VM could not only be used to attack the IP storage server, but also anything on the
storage network, such as a management appliance node. To mitigate this, I recommend erecting a
firewall around all management appliance networks from the storage network.
Attack the hypervisor
Just like attacks to the management appliances, storage networks could be used to directly attack
hypervisors. This clearly is more of a critical threat than the others combined for several
reasons.
In conclusion, I recommend that you keep the storage for hypervisors separate from the storage that can be directly accessed by your VMs. This way you can lower the number of attack points into the virtualization hosts and better protect your environment.
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.
This was first published in January 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation