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:ProgramDataMicrosoftWindowsHyper-VInitialStore.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.

Isolating the Host from Its Guests
When building a virtual server, you should carefully configure the network components. The virtual server should have enough network adapters to properly segment the networks of VMs, but you shouldn’t place machines from multiple network security zones on the same host. The best solution is to place virtual guests with similar roles and similar security requirements on the same host.

You should isolate the host machine’s network from its guests so that only authorized users can access the host via a trusted network. The best way to do so is to have a network adapter connected to an isolated and dedicated management network. However, if that isn’t possible, you should make use of technologies such as Virtual LANs (VLANs), IPsec, VPNs, Secure Sockets Layer (SSL) tunnels, and packet filtering to limit who can connect to the host machine over the network.

When it comes to hardening the virtual guest OSs, you can usually follow the same methods you use to harden physical machines. One advantage of VMs is that because they’re a fixed hardware environment—the virtualized hardware drivers are always the same—you can easily build hardened baseline templates for the various server roles you use. Keep in mind, however, that you should carefully protect these templates so that they aren’t compromised and use tools such as the Offline Virtual Machine Servicing Tool to keep them up-to-date with current patches. System hardening is a time-consuming, and therefore often neglected, task. By using pre-hardened OS templates, you can ensure that every new VM meets a pre-determined baseline.

As I mentioned earlier, the greatest risk associated with VMs is that any user with access to virtual hard disk drives can mount them and bypass the guest OS security mechanisms. One way to combat this risk is to implement disk encryption on the guest OS, at least for sensitive data. Microsoft’s Encrypting File System (EFS) is a good solution for protecting data. In cases in which the data on the virtual guest is highly sensitive, full-disk encryption technologies, such as Windows Bitlocker Drive Encryption in Windows Vista or PGP Whole Disk Encryption, might be necessary.

With VMs, you can easily add or remove hardware devices. Therefore, it’s a good idea to attach devices only when needed, and remove them for production use. This practice is particularly important for devices such as CD-ROM drives that you have mapped to the host machine because guest VMs will also have access to CDs inserted in the host machine’s CD drive.
When you configure the VM’s hardware, you should also limit the processor usage. By default, a VM can use 100 percent of the physical machine’s processor, meaning that someone could perform a denial of service (DoS) attack on one VM that would have an effect on all the other virtual guests on the system. Limiting CPU usage ensures there are enough CPU cycles left in reserve for the host and other VMs to still operate. Finally, because accessing a VM in the Hyper-V Management Console is equivalent to physically being at the guest OS’s console, it’s necessary to strictly follow all security best practices, such as setting up password-protected screen savers and logging out of a machine when it won’t be used.

Protecting Sensitive Machines
There might be times when you have a VM that’s particularly sensitive and needs a higher level of security. One benefit of VMs is the ability to easily take a system offline and quickly bring it back online using Hyper-V’s suspend feature. A root certificate server, for example, is so sensitive that you want to bring it online only for certain tasks.

To protect these sensitive machines, you can run them from a removable hard disk. When you’re finished with the machine, take the disk offline and physically lock it up. If you have a system that mostly stays offline, be sure to bring the machine online once a month to get the latest patches.

You can use startup passwords when appropriate to prevent unauthorized users from accessing sensitive VMs, although I don’t recommend using them for all systems. One way to prevent someone from booting a Windows VM is by setting a syskey password on the OS. You can do so by going to the Start menu, typing syskey in the search box, and pressing Enter. Doing so will open the Startup Key dialog box, which is shown in Figure 3.

Click Update, select the Password Startup option, set a password, and then click OK. You don’t want to set a syskey password on all your servers because it requires someone to be there for the system to restart. A crash or unattended reboot would result in the system being stuck waiting for a password.

As you determine which of these security tips work best for your organization, be sure to update your written security policies to include them. Very few policies or standards account for the unique risks associated with VMs. Also, administrators and users need to be trained on how to treat a VM differently than a physical machine. There’s much you can do to make VMs nearly as secure as physical machines. All it takes is a little planning to get it right.