Virtual servers introduce real attack vectors
You know about zombies. No, not zombie computers, but the previously human, undead, flesh-eating kind. When the zombies are out, people invariably run into a house to lock the zombies out. This works fine until the they discover that one of the people inside the house has turned into a zombie. Now, the problem they were trying to avoid is in the protected space. The people are still protected from the outside zombies, but that is of little comfort when the one zombie inside the house is ready to eat your flesh.
Meanwhile, back in the land of the living, your virtual servers are well protected behind your firewalls and intrusion prevention systems. These virtual servers are typically interconnected by a virtual network that is independent of the physical network. Thus, communications between virtual servers is not filtered or inspected by the firewalls and IPS sensors out in the physical network. If one of those virtual servers is compromised, perhaps it becomes a zombie (no, not the previously human, undead, flesh-eating kind, but a computer zombie), the other virtual servers on the virtual network are now in the same protected space. That protected space, like the house in the zombie movie, is protected from outside attacks but not from attacks originating within. Traffic between virtual servers usually goes uninspected and unfiltered, increasing the likelihood of successful attacks across the virtual network. Cisco has a white paper that, while discussing their VN-Link technology, gives a good explanation of how traffic moves within a virtualized environment and the inherent risks within such an environment.
The virtual network is just one of several attack vectors that virtualization may introduce into an environment. Hypervisors, dormant virtual servers, rogue virtual servers, and shared hardware also run the risk of becoming attack vectors.
The hypervisor is a software layer between the common hardware platform and the virtual servers. Typically, it has administrator rights to all virtual servers. This makes it a bit of a holy grail for hacking into a virtual environment. Own the hypervisor, and all virtual servers are at your disposal. Realtime Publishers and eEye Digital Security explain this issue well in Understanding and Improving Hypervisor Security.
The ease with which virtual servers can be created presents a big challenge to security. Servers that are built for testing or other short-term uses can be left lingering on the network long after they have been in use and, more importantly, patched. These "built & forgotten" servers can become targets for attacks that you stopped worrying about because you eliminated that vulnerability with patches on all your virtual servers, yet the forgotten server(s) went unpatched. The same risks apply to rogue servers that may have been built outside of authorized procedures and have, therefore, never been monitored or added to a patch management regimen.
Shared hardware creates another potential attack vector. We don't think typically about hardware being hacked but keep in mind that most hardware has software built into it. In an InfoWorld article, Galen Gruman points out that these risks have the attention of the U.S. National Security Agency. Don Simard, the commercial solutions director at the NSA said, "graphics cards and network cards today are really miniature computers that see everything in all the VMs." So, this is similar to the hypervisor risk, in that these hardware components have access to all virtual servers.
The good news is that there are products to address these issues. Virtualization vendors such as VMware, IBM, Citrix, and Microsoft, continue to improve their own security measures, though often as options that must be installed and/or enabled. Additionally, products specific to virtualization security are available from Reflex Systems (www.reflexsystems.com), Vizioncore (www.vizioncore.com), Catbird (www.catbird.com), Altor Networks (www.altornetworks.com), and others.
So, given a range of possible solutions, one may expect that virtualization security is not an issue. However, Andreas M. Antonopoulos, who has been writing on virtualization security for NetworkWorld since 2004, says that a "whopping 69.3% [of companies] have no plans at all to do anything specifically aimed at securing their virtual environments" in Virtualization security: So far nothing. I have to echo Andreas' last sentence, "What are we waiting for?" Once you're zombie food, it's too late.
July 20, 2009Juls,
Thank you for giving us a good example of ways in which virtualization vendors are improving the security features built into their products. I appreciate the input.
July 18, 2009JulsHi,
Great article however, with Vmware 3.5 update 4 steps have been taken to patch the actual servers and guest Operating Systems. Using update manager you can patch an entire Virtual Center along with its hosts in a matter of hours. Which by the way happens to work well.
April 30, 2015
December 4, 2014
November 18, 2014