Ubiquity can be a good thing. No matter which city you travel to, for example, you'll always find the standard latte at the local Starbucks. But ubiquity has its downsides. No matter how hard you try to protect your new socks as you dress for a night on the town, they won't make it 10 feet without accumulating cat hair.
Today's hypervisors are an area where ubiquity is a good and a bad thing. Yet many IT professionals extol hypervisors' positives without acknowledging their hidden dangers. This tip outlines some of the security vulnerabilities created by the single point of failure in Microsoft Hyper-V -- although the problem affects all hypervisors similarly -- and how you can protect your virtual machines.
Hypervisors' single point of failure
A hypervisor in virtualization technologies such as Hyper-V creates a uniform surface to which you can attach virtual machines (VMs). Whether you install Hyper-V to a Dell server, a Hewlett-Packard server or a white box that you built out of old parts and duct tape, the upward-facing surface of its hypervisor looks the same to every virtual machine. In any "enlightened" -- that is, virtualization-aware virtual machine -- VM's device manager, you'll see the Microsoft Virtual Machine Bus Video Device as the driver to power its display, while the Microsoft Virtual Machine Bus Network Adapter always handles networking.
Yet that same uniform appearance for virtual machines has a downside. If an environment runs each of its VMs on top of the same piece of hypervisor code, it's dependent on that code's unerring functionality. If an enterprising attacker writes a worm that targets the hypervisor layer itself, unprepared environments could lose entire virtual infrastructures.
This is the nightmare scenario for a virtualization environment. One day, 60 virtual machines merrily perform their assigned tasks across their Hyper-V hosts. But later that afternoon, somebody visits the wrong website or reads ...
To continue reading for free, register below or login
To read more you must become a member of SearchServerVirtualization.com
the wrong email and inadvertently launches an attack on every hypervisor. In a best-case scenario, the hypervisor itself merely crashes, taking down the 60 VMs but preserving their state. In a worst-case scenario, the skillful malware author would code the exploit's payload to corrupt VM disk files before invoking the crash. The result would be an immediate loss of IT services, followed by a lengthy restore from long-term backups.
Either scenario can occur because the hypervisor creates a distributed single point of failure. It is for this reason (among others) that Microsoft requires hardware data execution prevention as a prerequisite for Hyper-V installation. Hyper-V hosts and their residing virtual machines must be patched diligently. Microsoft will release updates for Hyper-V by making these updates available through Microsoft Update and Windows Server Update Services (WSUS).
Because of its position in the system stack, any installation of a hypervisor update is likely to require a system reboot or a short outage of virtual machines that reside on the host. A high-availability infrastructure is critical for all but the smallest of environments. When an entire environment resides on top of a potential target for malware attacks, running virtual machines must be able to relocate at any time to quickly patch their Hyper-V host.
Adding a few extra layers of protection to Hyper-V hosts is also a good idea. Enabling the Windows Firewall with Advanced Security on Hyper-V hosts and locking down their configuration inhibits the potential spread of malware. Regular backups for VMs also ease recovery from a zero-day attack. Segregate Hyper-V host networking from virtual machine networking (and from iSCSI traffic) to provide a logical separation of traffic for further tightening of security. Finally, review Microsoft's monthly patches to look for those that may relate to Hyper-V.
Since this problem isn't limited to Hyper-V. Any virtual platform that uses a hypervisor has single point of failure -- neither should your solutions. To that end, the next article in this series discusses how networking is affected by a move to virtualization. Hyper-V virtual networks are much different beasts from any physical network.
About the author
Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.
