Hidden dangers of Hyper-V: Dormant virtual machines

Virtualization brings great power to modern data centers. Whether you use VMware's high-end vSphere system or are...

focused on Microsoft's low-cost Hyper-V, virtualization dramatically changes many of the daily activities of IT. Yet, as any superhero will tell you, with great power comes great responsibility. When it comes to virtual machines (VMs), that responsibility arrives as an entirely new set of virtual server security concerns.

In the physical world, systems security is relatively mature. Virtual servers, however, have an entirely different set of requirements. These servers replace physical networking with software-based virtual switches. They eliminate machine-specific drivers by abstracting the physical layer via a hypervisor. And they enable heretofore-unseen levels of rapid server deployment through virtual machine copy and paste.

But all these tantalizing new capabilities come at a cost. They make life easier for administrators, but they also make life easier for the bad guys who exploit VM security vulnerabilities. These vulnerabilities are not immediately obvious, but they can cause major pain if they're exploited.

Virtual machine security hidden dangers
The first of these hidden dangers is related to the nature of virtual machines themselves. A virtual machine requires a virtualization platform, a bit of memory and a set of processors to operate as a functioning computer, and that same VM needs nothing more than space on a disk when powered off. This ability to encapsulate a Hyper-V virtual machine into a single Virtual Hard Disk (VHD) file is one of its greatest benefits -- need a duplicate server, just copy and paste; want a backup, just replicate that disk elsewhere.

As any superhero will tell you, with great power comes great responsibility. ,

Even more painful are the transitory VM instances that get out of control. IT team members need to deploy a patch to \\dc01 that they haven't quite tested. So they power down the VM and create a copy as an emergency backup. Once they create that copy and apply the patch, they move on and forget to delete the copy. Another team member needs to test an Exchange version upgrade using production data. So he creates a copy of the production Exchange server onto a USB drive or file server, completes the test and later forgets about the duplicate.

In both situations, you can see how the accumulation of virtual machines quickly eats up the disk space in your environment. But these forgotten virtual machines pose another threat. No longer useful -- or even worse, in wait for later use -- these VMs lie dormant for long periods of time. As dead-end nodes on your network, they don't get patched and don't receive anti-malware updates. If enough time passes, these VMs can eventually deviate so far from the baseline that merely powering them on introduces a massive security hole on a network.

In short, unlike every other type of file on a server's disks, the file for a dormant VHD could take down your entire network. And that can occur by doing little more than powering them on.

While we haven't seen a massive, Internet-destabilizing worm in a while, only a fool would believe that more won't eventually pop up. Consider the recent Conficker worm or the SQL Slammer worm. In either of these cases, it is entirely possible that you could patch your environment to 100% compliance, only to re-infect yourself all over again when an unsuspecting admin powers on a six-month-old virtual machine.

In response to this clear and present danger, several tools have emerged to protect environments against dormant VMs. First, the no-added-cost Network Access Protection feature built right into Windows Server 2008 can create an infrastructure of enforcement, immediately and automatically relegating noncompliant machines to walled-off networks as they power on. And in recent years, third-party tools to assist with VM lifecycle management have also sprung up. Embodics' V-Commander, Vizioncore's vControl and McAfee's VirusScan Enterprise for Offline Virtual Images are three examples. These products take different approaches to scanning a network for VHD (and Virtual Machine Disk Format) files in its darkest recesses.

Virtual machines themselves are only one of the hidden dangers to be aware of for virtualization security. Part two of this series will focus on another pain point: The hypervisor itself.

About the author