Microsoft’s server virtualization technology is easy to secure with the right policies and processes. Security requires consistent application of relevant standards and some discipline in the actions of IT professionals.

The Basics

Before we begin, let’s be sure we understand Microsoft server virtualization technology as discussed in this article. See Figure 1.

Figure 1: Microsoft Server Virtualization Components

Host Operating System

A virtualized hardware platform requires a foundational operating system (OS) into which system engineers install the virtualization components. In a Windows Server 2008 R2 environment, this requires a 64-bit version of Server Standard, Enterprise, or Datacenter. This is either a standard install or an implementation of Server Core. Later in this article, we see how the implementation you choose affects security.

Hyper-V

A hypervisor abstracts the host server’s hardware from the virtual machines. Microsoft named its hypervisor Hyper-V. It’s a very thin layer performing the following tasks (see Figure 2):

Optimizes virtual machine (VM) interrupt calls Manages shared memory In general, it enables VM use of system resources without having to access the host operating system, while managing those resources as configured in the management operating system

What it does not do is run anything else. For example, it will not run third party drivers. The small attack surface presented by Hyper-V is an out-of-the-box security control. Hyper-V and related management files are installed as part of installing the Hyper-V server role on the Host.

Figure 2: Microsoft Server Virtualization (Microsoft MSDN, 2011)

Partitions

Partitions are isolated operational entities within a virtualized environment. According to Microsoft MSDN (2011), “A partition is a logical unit of isolation, supported by the hypervisor, in which operating systems execute” (para. 2). A more workable definition is: partitions are the areas in which guest operating systems execute. However, not all partitions are equal. The Root (a.k.a. Parent) partition (RP) is a mandatory instance of Windows Server. The virtualization stack resides here, and administrators use it to create, initiate, stop, and manage VM instances. It also differs from child partitions in its ability to directly access hardware resources (Microsoft MSDN, 2011). Although the RP is important, no production systems are run within it. This is the role of child partitions. Child (or guest) partitions (CP) contain production systems and operate just as their hardware peers. The difference is their lack of direct access to resources provided by the underlying hardware platform. Instead, “they have a virtual view of the processor and run in a virtual memory address region that is private to each guest partition” (Microsoft MSDN, 2011, para. 4). The RP and the hypervisor enable use of internal and external resources, including connectivity to a physical network. I could dig deeper into the various services and interfaces enabling Microsoft Virtualization, but this high-level view is sufficient to begin a discussion about Hyper-V and VM security. For details about the components depicted in Figure 2, see the supplied reference.

Reduce the Attack Surface

The attack surface of a virtualized Microsoft server environment potentially consists of all the components discussed above, including all supporting files and drivers. Its actual size, however, depends on how well we perform the following steps: Step 1: Harden the Host Step 2: Harden the management and VM operating systems Step 3: Ensure configuration of all user roles with least privilege access Step 4: Use administrator roles to implement separation of Host, RP, and VM management Step 5: Secure VM files, including hard disk, backups, and archives Step 6: Enable auditing Step 7: Patch archived VMs Step 8: Use VLANs and multiple network interface cards (NICs) to isolate management and VM access Step 9: Use virtual networks to isolate VMs on the same host Step 10: Manage proliferation

Step 1: Harden the Host

The Host consists of the hardware and operating system that underlie the hypervisor, as shown in Figure 1. The Host operating system is subject to all vulnerabilities expected in a Microsoft Server implementation, including extra services. The best way to reduce the Host’s attack surface is to eliminate common vulnerabilities. Simply, just don’t install them. A Windows Server Core implementation is the best way to achieve this. Server Core is a minimal installation of Windows Server. According to Microsoft TechNet (2011), the purpose of Server Core is “…to eliminate any services and other features that are not essential for the support of certain commonly used server roles. For example, a Domain Name System (DNS) server really doesn’t need Windows Internet Explorer installed on it because you wouldn’t want to browse the Web from a DNS server for security reasons. And a DNS server doesn’t even need a graphical user interface (GUI), because you can manage virtually all aspects of DNS either from the command line using the powerful Dnscmd.exe command, or remotely using the DNS Microsoft Management Console (MMC) snap-in” (Full vs. Server Core, para. 2). Server Core is not without constraints. Third party drivers and services may not work properly. If this is a problem for you, then implement a full version of Server. Whether you use Core or a full implementation, use common sense and best practices to secure your Host. For more information on Server hardening practices, see Microsoft’s Server 2008 R2 Security Baseline.

Step 2: Harden the Management and VM Operating Systems

You must also harden the management operating system (MOS) running in the RP. The MOS is another instance of Windows Server. It is used by administrators to manage the overall virtualization environment. When deciding how much security is necessary, make sure MOS hardening is commensurate with the most sensitive information processed on any of the VMs on the MOS’s Host. Again, use the Microsoft Server 2008 R2 Security Baseline. In addition to the MOS, each VM OS requires the same attention. Use the appropriate security recommendations for the server OS and the server role. Treat each VM as you would a physical server; the same security policies apply. There is an important caveat when installing and configuring anti-virus software. Avoid scanning the following:

Virtual machine files Program files vmms.exe and vmwp.exe in c:WindowsSystem32

Failure to exclude these files from your AV scanning process might result in VM instantiation issues. Finally, the MOS instance is not a production server. Never run business applications there or use it to browse the Internet. Use it strictly as a tool to manage VMs. Restrict applications and browsing to virtual production servers.

Step 3: Configure Admin Roles with Least Privilege Access

To ensure separation of duties for security and compliance purposes, no one person should have the ability to perform all administrative tasks. For example, a Hyper-V administrator should not have permission to manage VMs. Microsoft provides three pre-defined roles to help separate critical duties:

Hyper-V administrator – Using the (MOS) in the RP, this role has permissions to make global changes affecting all VMs on a Host, including network and storage configurations. Delegated administrator – This role provides additional granularity for administrator access by restricting administrators to those Hosts or Host groups they must manage. Using Microsoft’s System Center Virtual Machine Manager (VMM), they can manage VMs on any hosts to which they’ve been assigned, but they have no access to other Hosts in the enterprise. Self-service user – The overall administrator can set access controls by VM or by sets of VMs using this role. This differs from the delegated administrator role by allowing privilege assignment at the VM level instead of limited control to the Host level.

Step 4: Separate Admin Roles of Host, RP and VM

In addition, consider separating physical security administration from Hyper-V administration. In other words, because an engineer has to maintain the Host hardware and OS does not mean he or she needs access to the MOS. By default, MOS local administrators have access to MOS management via the Hyper-V Manager Microsoft Management Console (MMC) snap-in. Further, using the Authorization Manager MMC snap-in provides granular control of administrative tasks. Microsoft (2009) provides lists of operations (see the following tables) you might consider when segregating management responsibility with your own roles (p.21). Table 1: Hyper-V Service Operations Table 2: Hyper-V Network Operations Table 3: Hyper-V Virtual Machine Operations

Step 5: Secure VM files

By default, VM files are located in two folders:

%programdata%MicrosoftWindowsHyper-V %users%PublicDocumentsHyper-VVirtual Hard Disks

Files of particular interest have specific extensions: .vhd, .vhdd, .vud, and .vsv. Whether you choose to leave them in their default locations or move them into a granular folder structure, consider protecting these files with the following controls:

Use access control lists to enforce least privilege for services and administrators. Block all other access. Encrypt the folders listed above or the volume containing them. Ensure you have a current backup. Enable auditing.

When applying access controls, remember that a VM administrator might not need access to all VMs. For each administrator, allow access only to files for VMs he or she manages.

Step 6: Enable Auditing

Auditing includes both file access and system monitoring. Windows TechNet (2009) provides audit policy implementation instructions. All files associated with VM and RP configuration and data storage are candidates for auditing. In addition to file access auditing, use Microsoft System Center Operations Manager, or similar monitoring tool, to alert on unwanted or high-risk behavior.

Step 7: Patch Archived VMs

Physical and virtual servers require the same administrative, logical, and physical controls—including participation in an aggressive patching process. Patching running VMs is straightforward. They look like any other server to your patching application. But what about VMs not currently running? It is never a good idea to add an unpatched server to a production environment. However, if you’ve archived a VM for several months, it might lack critical security patches. Microsoft TechNet has a solution for this. Using Microsoft’s Virtual Machine Servicing Tool (VMST) 3.0, you can apply updates and patches to any archived VM. Use of this tool requires one of the following:

System Center Virtual Machine Manager 2008 R2 System Center Configuration Manager 2007 SP2 Windows Server Update Services 3.0 SP2

Figure 3 depicts the patching/update process. Each archived VM is started, updated, and then stored and deactivated. Note the requirement for a maintenance host. Place this server in a restricted network segment. Ensure its security is commensurate with the highest classification of data in your enterprise.

Figure 3: Virtual Machine Servicing Tool Process (Microsoft TechNet, 2010, Servicing Offline Virtual Machines in a VMM Library)

Step 8: Isolating management and VM access physically

Isolating devices in a virtual environment follows the principle of network segmentation. Segmenting a network allows only explicitly permitted network traffic to reach a device. In a virtualized environment, there are two possible segmentation methods: physical and virtual. The final step in configuring a Host is connecting it and its VMs to the network. However, not all network connections are the same. Network segmentation is necessary to ensure only authorized traffic arrives at the most sensitive areas. This requires at least two network interface cards (NICs) installed in the Host. At the most basic level, access to the MOS should be over a dedicated management segment connected to one of the NICs. Using physical VLANs, this is simple and provides the first layer of security against unauthorized access to the Hyper-V configuration. One or more additional VLANs are then necessary to connect the VMs via the remaining NICs. Figure 4 shows the physical NIC assignment window. When configuring the Hyper-V server role, you are asked to assign a NIC to the VMs or to the MOS. An unchecked NIC is automatically assigned to the MOS.

Figure 4: NIC Assignment

Step 9: Virtual Segmentation isolates VMs on the same host.

A virtual switch is created for each of the NICs you select in the process above, as shown in Figure 5. You can also configure your own. According to Panek (2009), “Virtual switches help Hyper-V secure and control the network packets that enter and exit the virtual machines. You can limit the communications to or from a virtual machine and the VLAN. When setting up your network adapters, you can associate a single virtual switch with that adapter” (p. 98). The Hyper-V administrator creates one or more virtual NICs for each VM and connects them to virtual switch ports. Virtual switches function like physical switches, including allowing creation of VLANs to control traffic flow. Three types of virtual networks (VNs) are possible: internal, external, and private.

Internal virtual networks have no access to the outside world. They allow VMs to communicate with each other and the RP. An Internal VN is not bound to a physical NIC and is typically used for testing. External VNs allow VMs, and the MOS, to communicate over the physical network and with the physical server. Private VNs provide granular virtual network segmentation, allowing administrators to control traffic between VMs on the same Host. It isn’t always necessary for VMs on a single Host to access each other. In these cases, isolate them.

Figure 5: Virtual Switches

Step 10: Manage Proliferation

Virtualization is a great productivity tool… if it’s not abused. However, there is temptation to use it for quickly instantiating servers outside established change management processes. When this happens, all oversight to ensure attack surface mitigation is by-passed. Over time, out-of-control virtualization can become a bigger risk than it is a benefit. Keeping risk low is not difficult. Ensure any server showing up on your network is quickly identified and its authorization confirmed. Create policies that include ensuring all virtual server implementations follow a strict change management process. Finally, work with your engineers to get their buy-in. Proliferation risk is manageable with the right processes, controls, and attitudes in place.

Conclusion

Microsoft Hyper-V technology is a significant addition to business productivity tools. It provides flexibility, resiliency, and quick IT reaction times when business needs arise. In many ways, the same security policies apply to VMs and physical servers, but there are a few differences. Segregate administrative roles and control access to VM files based on least privilege. This might be difficult for small IT shops, but make every effort to ensure physical server, management operating system, and VM administration are not performed by the same person. Include archived VMs in your patching process. Treat them like running servers. Keeping them patched prevents surprises when you start them after a few months and without critical security patches. Use physical and virtual network segmentation to restrict traffic and access. This includes using virtual switches to segregate VMs on the same Host. Finally, control VM proliferation. Integrate VM creation, start up, and shut down activities into your change management and network monitoring processes.

References

Microsoft. (2009). Hyper-V security guide, Retrieved from http://technet.microsoft.com/en-us/library/dd569113.aspx Microsoft MSDN. (2011). Hyper-V architecture. Retrieved from http://msdn.microsoft.com/en-us/library/cc768520 Microsoft TechNet. (2009). Audit policy settings under local policies/audit policy. Retrieved from http://technet.microsoft.com/en-us/library/dd941595(v=WS.10).aspx Microsoft TechNet. (2010). Virtual machine servicing tool: Getting started guide. Retrieved from http://adventuresinsecurity.com/Papers/VirtualMachineServicingToolGettingStartedGuide.docx Microsoft TechNet. (2011). What is Server Core. Retrieved from http://goo.gl/x6y8j Panek, W. (2009). Windows Server virtualization configuration guide: Exam 70-652. Wiley Publishing Inc.