Securing Hyper-V

Virtualization is getting quite a bit of attention these days and still has enough steam to remain the killer technology of this decade. But despite all the attention virtualization receives, not much is said about the security implications of this technology. Because virtualization products, such as Microsoft’s Hyper-V, introduce some unique security risks, security certainly is a topic that needs to be addressed.

Although securing the OS on a virtual machine (VM) is similar to securing the OS on a physical machine, there are two important factors to consider when securing VMs. The first factor is that VMs share hardware resources, such as network adapters, which can introduce some security risks. The second, and most important, factor is that a VM’s configuration, disks, bios, and even memory contents exist as files potentially exposed on the host machine.

This second factor is significant because having access to a virtual disk file is essentially the same as having access to a physical disk. If you can pull the hard disk drive out of a physical computer, you can mount that drive on another machine with a different OS and any NTFS permissions you might have set will no longer apply. Likewise, you can insert a bootable CD that boots to an alternative OS and have mostly unrestricted access. Security experts have long agreed that if someone has physical access to a machine they can almost always compromise that machine. In the physical world, this isn’t a huge problem because you can place servers in a locked server room. However, with VMs having access to the Virtual Hard Disk (VHD), that’s equivalent to having physical access to a physical hard disk drive. Because someone might have access to those files over a network, they essentially have access to that machine over the network, which blurs the barrier of a locked server room. Furthermore, the risk with VMs is greater because someone could make a copy of a VHD and you might not ever know it was stolen. Because of these risks, securing a VM requires you to severely limit access to the host machine, take extra security measures in the guest OS, and limit interaction between the host and the guest.

Hardening the Host
Securing Windows Server 2008 configured for the Hyper-V role is especially important because the security of each guest OS depends on the security of the host server. Curiously, the Server 2008 Security Guide doesn’t cover the Hyper-V role; neither does the Security Configuration Wizard (SCW).

However, you can run the Hyper-V role with the new scaled-down Server Core installation that’s available in Server 2008. Server Core is a minimal Windows installation that lacks the Windows Explorer shell, dialog boxes, applications, and services that add overhead and potentially increase the attack surface. With a smaller footprint there’s less to attack and fewer files that might need patching each month, so the server requires fewer reboots. Although you don’t have the GUI tools to manage the server locally if you’re running Server Core, you can remotely manage the server from another system that has the GUI tools. Many examples in this article will refer to the GUI tools that you might use locally on a regular Server 2008 installation or remotely with a Server Core installation.

Reducing the attack surface is the key to securing an OS, so it’s best to dedicate a server to the single role of virtualization and not install additional software or services on it. One exception to this best practice is that a Hyper-V host machine is a great location for an Intrusion Detection System (IDS). Since all guest network traffic goes through the host machine’s network adapters, a single IDS sensor on the host can monitor all the guest OSs.

As I mentioned earlier, guest machines are particularly vulnerable to users on the host server. Therefore, it’s important to carefully consider user accessibility. The simplest way to control user accessibility is to let only a limited number of users access the system either locally or via Terminal Services. You can use Group Policy to determine which users can log on locally to the server. To do so, open the Local Security Policy console, expand Local Policies, and select User Rights Assignment. In the right pane, double-click Allow Log On Locally Policy. As Figure 1 shows, users can log on locally by default.

Next, highlight Users and click Remove. From there you can specify which users or groups of users can log on to the system.

Once you’ve determine which users can log on to the system locally, you can further define how users can access VMs using Authorization Manager. To do so, open the Authorization Manager console by typing azman.msc in the Start menu’s search box. You don’t need to wait for the search results to appear; you can press Enter and the Authorization Manager will open. From the Action menu, select Open Authorization Store. When the Authorization Store dialog box appears, select XML file and browse to the C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml file on the server. Note that the ProgramData directory is hidden by default, so you might have to manually type that part of the file path in.

Once you’ve loaded the authorization store, expand InitialStore.xml, Microsoft Hyper-V Services, Definitions, and then Role Definitions. In the right pane, double-click User and then select the Definition tab. From there, you can add or remove operations that users can perform. For more information about Authorization Manager, go to technet.microsoft.com/en-us/dd283030.aspx.

From a development perspective, Hyper-V excels over many virtualization products with its superior programmability and control via Windows Management Instrumentation (WMI). However, this programmability lets you control the guest OS in ways the guest OS might not anticipate; therefore, an unauthorized user could potentially bypass security controls in the guest OS.

Because WMI handles the automation interface, you can use WMI permissions to limit access to Hyper-V through WMI. Simply type wmimgmt.msc in the Start Menu’s search box and press Enter. Then, right-click WMI Control and select Properties. Select the Security tab and expand Root, Virtualization and then highlight ms_409, as Figure 2 shows.

If you click the Security button, you can fine-tune the user permissions as necessary. For more information about the specific WMI permissions you can modify, see Table 1.