Hidden dangers of Hyper-V: Dormant virtual machines

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

    Requires Free Membership to View

    Login

    When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.

    Cathleen A. Gagne, Senior Editorial Director

    By submitting your registration information to SearchServerVirtualization.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchServerVirtualization.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.
,
However, it introduces a massive security problem into your infrastructure: the stacks of dormant VM disk files that will eventually start collecting on a network. Why? Consider the following situation: Let's say you create a virtual machine named "\\server1," with the intention of using its configuration as the starting point for other VMs. While you may want to use \\server1 as the basis for every VM in a network, you may eventually need other "golden images" for different purposes. For example, you could create \\server1a, which is like \\server1, but with SQL Server installed to reduce installation time, and \\server1b is also based on \\server1, but with a set of developer tools to speed the creation of test and development machines. And \\server2 may be created for a developer project, but its starting point is \\server1b instead of \\server1. A genealogy of virtual machines begins to form.

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

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.


This was first published in September 2009

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

Back to top