Windows Server 2008 Hyper-V Security

Server virtualization allows hosting of different virtual guest computer environments on one physical host computer. Organizations can use server virtualization to consolidate servers; build more cost-efficient and effective development, test, and preproduction environments; simplify disaster recovery; and easily port virtual servers across different hardware platforms.

Microsoft provides two server-virtualization solutions. The first is Microsoft Virtual Server—a free software package that you can use to build virtual servers on top of Windows Server 2003, Windows XP, and Windows Vista. Microsoft's most recent server virtualization solution is Hyper-V—an integral part of Windows Server 2008. Like Microsoft Virtual Server, Hyper-V allows for the virtualization of both Windows and non-Windows OSs.

This article focuses on the security aspects of the Hyper-V virtualization solution. It explains how securing virtual servers is different from the way you secure physical servers. With the guidance and best practices offered in the article, you'll be better able to protect your Hyper-V virtualization infrastructure. To start, let's look at the defenses Microsoft built into the Hyper-V architecture.

Hyper-V Architectural Defenses
When Hyper-V loads, it creates a thin abstraction layer (less than 1MB) called the hypervisor. It operates between the physical server hardware and the host OS. The hypervisor interfaces directly with the server hardware and loads before the host OS starts. You could also define the hypervisor as a mini OS that allows for the virtualization of other OSs on top of it. All OSs that run on a Hyper-V server (both the virtualized ones and the host OS) always run inside a virtual machine (VM) that's under the watchful eye of the hypervisor. Virtual Server uses a different approach in which the host OS runs beside the virtualization layer, and the host OS also directly interfaces with the hardware.

To support hypervisor-based virtualization, your system's processor must support what is referred to as hardware-assisted virtualization. This feature is commonly supported on state-of-the-art processors, such as the Intel VT and AMD-V processor lines. Processors that support hardware-assisted virtualization provide a highly privileged layer in the processor ring architecture that keeps the execution environment of the hypervisor fully separated and isolated from the rest of the system.

The hypervisor performs critical tasks such as memory management and ensures security isolation between the host OS and the different virtualized OSs. In Hyper-V, the environment in which the host OS or a virtual OS runs is known as a partition. You could also define a partition as a basic unit of isolation. The partition that runs the host OS is called the parent partition, and the partitions that run virtualized OSs are called child partitions.

The parent partition is a privileged partition. It creates and manages child partitions, owns the resources not owned by the hypervisor, and takes care of power management and the management of hardware-failure events.

The parent partition must run 64-bit Server 2008. Microsoft's choice of 64-bit for the parent partition is primarily driven by 64-bit platform's expanded memory and processing facilities. More memory simply allows for more VMs on one platform. But 64-bit Windows also brings security advantages: 64-bit Windows doesn't include legacy code and has been built from the ground up using the Microsoft Security Development Lifecycle (SDL) methodology. Microsoft developed SDL for building more secure software and to add more repeatability and predictability to the software development process. SDL tries to make software development more of a science than an art. You can find more information about SDL at the Microsoft Security Development Lifecycle site.

Given the important role of the hypervisor from a partition isolation point of view, and to further reduce the hypervisor's attack surface, Microsoft limits the code and services that run inside the hypervisor. The hypervisor doesn't include I/O stacks or device drivers. Child partitions communicate with the physical hardware through device drivers that are running in the parent partition. This approach to dealing with device drivers is referred to as a micro-kernelized hypervisor architecture. Although this architecture reduces the security risks for the hypervisor, it creates extra risks for the parent partition. For example, faulty or malicious device drivers might expose the parent partition. In the section titled "Protecting the Parent Partition," I give some advice on how you can harden the Hyper-V parent partition.

Leveraging Hardware Security Features
Hyper-V can leverage state-of-the-art hardware-related security features such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR). DEP is a buffer overrun prevention technique that prevents the injection of executable malicious code into data buffers in system memory. Hyper-V requires hardware-based DEP enforcement, which means you must have a processor that supports the No Execute (NX—the AMD term) or the eXecute Disable (XD—the Intel term) features. ASLR is a malware protection feature that randomizes the memory location of critical files between system reboots. Thus, it cripples malware (e.g., worms, Trojans) that repeatedly target the same memory address on different machines. For more information about DEP and ASLR, see "Vista and Server 2008 Malware Protection Gems."

Earlier I mentioned three important hardware requirements that Hyper-V leverages, directly or indirectly, as security defenses: hardware-assisted virtualization, hardware-based DEP, and 64-bit support. To check whether your system supports these Hyper-V requirements, you can use the SecurAble freeware tool. Or, if you have an AMD-V processor, you can use the AMD-V Hyper-V Compatibility Check utility. You can download the free SecurAble tool or AMD tool. Figure 1 shows the SecurAble tool interface; Figure 2 shows the AMD tool.

The SecurAble tool has an important warning: "Passing the three SecurAble tests (64-bit support, hardware DEP, and hardware virtualization support) on a machine with an AMD processor doesn't always guarantee that you can install and run Hyper-V on your machine." The tool doesn't check for the presence of certain AMD chipsets and BIOS versions that are required to run Hyper-V. When you have an AMD processor, it's safer to also run the AMD utility. I ran both tools against my AMD Turion processor, and the results are illustrated in Figures 1 and 2. Notice that even though my processor passed the SecurAble tests, the AMD tool reports that my processor isn't compatible with Hyper-V.

Another interesting thing you might experience when you use SecurAble on a Server 2008 system that has Hyper-V up and running is that the tool reports that your processor doesn't support hardware virtualization, even though it told you your processor did support hardware virtualization before you installed Hyper-V. In this case there is nothing wrong with the SecurAble tool; this just illustrates one of the aspects of the Hyper-V hypervisor architecture. When the hypervisor launches, it hides certain CPU capabilities to the partitions running on the host (including the parent partition). It does this so that no software in the parent or guest OSs tries to use CPU functionality (e.g., hardware virtualization) that the hypervisor controls.

After you run these tools, to get started with Hyper-V, you must first install a Server 2008 64-bit OS. Then you install the Hyper-V bits (which you can download from Microsoft). Finally, add Hyper-V support by enabling the Hyper-V server role and reboot your system.

Protecting the Parent Partition
In the section on Hyper-V architectural defenses I referred to the critical role of the parent partition—the partition that runs the 64-bit Server 2008 host OS on a Hyper-V server. Next I will explain how you can reduce the attack surface of the parent partition to provide a better defense-in-depth for your Hyper-V virtualization server and the VMs it hosts. To secure the parent partition, you can leverage the Server Core Server 2008 installation option, as well as the Authorization Manager (AzMan) and BitLocker Drive Encryption (BDE) Server 2008 features.

Another approach to secure the Hyper-V parent partition is to use the standalone Hyper-V Server 2008 software for your virtualization server instead of installing Hyper-V on top of Server 2008 Standard, Enterprise, or Datacenter Edition. Hyper-V Server 2008 offers an out-of-the-box, small footprint, GUI-less virtualization platform—but doesn't support interesting features such as Windows Failover Clustering (WFC), an important high-availability provider as I explain later.

Server Core is a Server 2008 server installation option that provides a minimal environment for running certain server roles such as a domain controller (DC), a file server, and also the Hyper-V role. Server Core significantly reduces the maintenance requirements and the attack surface of a Windows server, and it is a security best practice to install your Hyper-V server on a Server Core installation. For detailed information on how to install Hyper-V on Server Core, read the Microsoft "Hyper-V Planning and Deployment Guide."

A Server Core installation doesn't include the traditional Windows GUI, and if you want to configure it locally you must do so from the command prompt. But you can also manage a Server Core server remotely using a Terminal Server connection, or using Microsoft Management Console (MMC) or command-line tools that support remote use. To manage your Hyper-V server remotely from a Server 2008 or Vista SP1 machine, you can use the MMC Hyper-V Manager snap-in that is included in the software update packages that are described in the following Microsoft articles. For Server 2008, see the Microsoft article "Description of the update for the release version of the Hyper-V technology for Windows Server 2008"; for Vista SP1, see "Description of the Windows Vista Management Tools update for the release version of Hyper-V."

To honor the principle of least privilege and ensure that VM administrators can manage only their own VMs and can't touch the parent partition, you should lock down the permissions that are given to VM administrators. On a Hyper-V server you can leverage the Authorization Manager (AzMan) to define specific roles for VM administrators and to ensure that they have permissions only on their respective VMs. Microsoft introduced AzMan in Server 2003 to enable developers and administrators to easily add role-based access control (RBAC) rules to their applications. Unfortunately, few Windows administrators have used AzMan or know how to configure it. For an excellent description of how to set up AzMan for delegating permissions on a Hyper-V server, see Dung K. Hoang's blog. Figure 3 illustrates how you can configure AzMan RBAC rules for Hyper-V from the MMC Authorization Manager snap-in. A Microsoft product that's worth mentioning in this context is System Center Virtual Machine Manager (VMM), Microsoft's enterprise management solution for managing virtualization servers and their VMs. VMM reduces the complexity of configuring and managing AzMan authorization rules, because the tool does this for you. More information about VMM is available at the Microsoft System Center Virtual Machine Manager 2008 R2 site.

BDE is a volume-level encryption solution that Microsoft bundles with Server 2008 and Vista. BDE offers offline data protection, meaning that it ensures that data is in an encrypted state when your Windows machine is not powered up or operating. BDE also enforces a multifactor authentication sequence when the protected system is booted. This ensures that malicious persons can't bypass the BDE protection by booting the system from another OS or using a hacking tool. You can use BDE on Hyper-V machines for securing access to volumes that contain VM-related files such as virtual hard disks (VHDs) and configuration files. More detailed information about Hyper-V BDE support can be found in the Microsoft white paper "Windows Server 2008 Hyper-V and BitLocker Drive Encryption."

Finally, you must also remember the following "classical" security best practices to secure the Hyper-V parent partition. You should never install or run unneeded applications in the parent partition, and you should define a dedicated physical NIC to manage the parent partition. This rule implies that you should never expose the dedicated management NIC to untrusted network traffic. Thus, you must set up a separate VLAN for the management LAN, leverage strong authentication tools such as smart cards for administrator access to the management LAN, and not give any VM access to the NIC that's used for parent partition management.

Patching VMs
Like for any other Windows machine, keeping your VMs up-to-date with the latest software and security patches and fixes is important. As for physical servers, you can use standard Microsoft automatic patching solutions such as Windows Update, Windows Server Update Services (WSUS), or System Center Configuration Manager (SCCM).

An interesting patching problem is how to ensure that your VMs are adequately patched before they are turned on in a production environment. Organizations typically build a standard VM image, update it with the latest patches, then leave it in that state until the need arises to create a new VM based on that image. To deal with the patches that have been released in the period between the creation of the image and the introduction of a new VM based on that image in the production environment, you need additional automated patching tools. Failing to use automated tools will leave a window of opportunity for malware to infect the machine when it's introduced in production and before it actually receives the latest patches.

A good solution is to create so-called maintenance hosts. A maintenance host is a machine that you reserve for patching stored VM images before they are released to production. The notion of maintenance hosts is also supported in VMM.

Microsoft also provides a special tool called the Offline Virtual Machine Servicing Tool to help customers adequately patch VM images. The Offline Virtual Machine Servicing Tool manages the workflow for updating large numbers of offline VMs. The tool works with VMM and with Microsoft's enterprise-level software update management systems WSUS and SCCM. You can learn more about how to set up maintenance hosts in the TechNet article "Planning for Hosts." You can download the Offline Virtual Machine Servicing Tool from Microsoft.

Ensuring High Availability
Patching your VMs is important, but it's equally important to ensure the high availability of your virtualization servers and their VMs. Clusters are a typical answer to the high-availability question. In Server 2008, Microsoft includes important changes for its Windows-based failover cluster support, WFC. The WFC enhancements include simplifications in cluster setup and configuration, and enhancements in the areas of reliability, stability, scalability, networking, and security. In Server 2008, Microsoft also makes it easy to leverage WFC for building clustered Hyper-V servers.

If you're not familiar with clustering terminology, a failover cluster is a group of computers that work together to provide high availability for applications and services. The clustered computers (known as cluster nodes) are interconnected via physical cables and software. If one of the cluster nodes fails, the cluster logic ensures that another cluster node automatically starts to provide the service. The process of switching between nodes is called cluster failover.

Using Server 2008 WFC you can, for example, set up a two-node cluster for the Hyper-V parent partition and configure the VMs as cluster resources. The VMs can then fail over to a different node when one of the cluster nodes fails. More information about how to set up a clustered Hyper-V server is available in the TechNet article "Hyper-V: Using Hyper-V and Failover Clustering."

You can also benefit from WFC for performing maintenance and servicing tasks on your Hyper-V server's parent partition (the host OS) with minimal production disruption. For example, if you want to apply the latest security patches on the active node of your Hyper-V cluster, you can manually fail over the cluster to the passive node. Microsoft refers to this as Hyper-V Quick Migration. For more information about Quick Migration, see the Microsoft white paper "Quick Migration with Hyper-V." Even though WFC Quick Migration is nice from a high-availability point of view, it's not the same as migrating a machine in its running state. Microsoft includes live migration support in the Server 2008 R2 version of Hyper-V. Live migration can also be done with other virtualization solutions, such as VMware's VMotion or XenServer's XenMotion.

Virtually Secure
I've given you a basic understanding of Server 2008 Hyper-V architecture and illustrated how Microsoft designed Hyper-V with security and defense-in-depth in mind. I also pointed out some areas in which securing VMs is somewhat different or more complex than securing physical machines.

This isn't an exhaustive list of the security measures you should take for your virtualization servers. For example, I didn't emphasize that on a VM, it's as important to run antivirus and antispyware tools, and to keep these tools up-to-date, as it is on your physical machines. Microsoft plans to include an exhaustive list in an upcoming release of the Windows Server 2008 Security Guide. In the meantime, this article and the links to further information give you numerous tools to better protect your Hyper-V virtualization infrastructure.

Related Reading: