Microsoft Virtual Server Security: 10 Tips and Settings

Virtualization brings significant value to business managers and engineers attempting to keep pace with business pressure for additional servers. It enables maximum use of hardware resources while introducing an increased flexibility in how organizations design and implement new solutions. However, it also introduces new security concerns.

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.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

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

Name Description

Read service configuration Authorizes reading configuration of the Virtual Machine Management Service

Reconfigure Service Authorizes reconfiguration of Virtual Machine Management Service

Table 2: Hyper-V Network Operations

Name Description

Bind External Ethernet Port Authorizes binding to an external Ethernet port

Connect Virtual Switch Port Authorizes connecting to a virtual switch port

Create Internal Ethernet Port Authorizes creating an internal Ethernet port

Create Virtual Switch Authorizes creating a new virtual switch

Create Virtual Switch Port Authorizes creating a new virtual switch port

Delete Internal Ethernet Port Authorizes deleting an internal Ethernet port

Delete Virtual Switch Authorizes deleting a virtual switch

Delete Virtual Switch Port Authorizes deleting a virtual switch port

Disconnect Virtual Switch Port Authorizes disconnecting from a virtual switch port

Modify Internal Ethernet Port Authorizes modifying the internal Ethernet port settings

Modify Switch Port Settings Authorizes modifying the switch port settings

Modify Switch Settings Authorizes modifying the switch settings

Change VLAN Configuration on Port Authorizes modifying VLAN settings

Unbind External Ethernet Port Authorizes unbinding from an external Ethernet port

View External Ethernet Ports Authorizes viewing the available external Ethernet ports

View Internal Ethernet Ports Authorizes viewing the available internal Ethernet ports

View LAN Endpoints Authorizes viewing the LAN endpoints

View Switch Ports Authorizes viewing the available switch ports

View Switches Authorizes viewing the available switches

View Virtual Switch Management Service Authorizes viewing the Virtual Switch Management Service

View VLAN Settings Authorizes viewing the VLAN settings

Table 3: Hyper-V Virtual Machine Operations

Name Description

Allow Input to Virtual Machine Authorizes user to give input to the virtual machine

Allow Output from Virtual Machine Authorizes viewing the output from a virtual machine

Change Virtual Machine Authorization Scope Authorizes changing the scope of a virtual machine

Create Virtual Machine Authorizes creating a virtual machine

Delete Virtual Machine Authorizes deleting a virtual machine

Pause and Restart Virtual Machine Authorizes pause and restart of a virtual machine

Reconfigure Virtual Machine Authorizes reconfiguring a virtual machine

Start Virtual Machine Authorizes starting the virtual machine

Stop Virtual Machine Authorizes stopping the virtual machine

View Virtual Machine Configuration Authorizes viewing the virtual machine configuration

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

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Panek, W. (2009). Windows Server virtualization configuration guide: Exam 70-652. Wiley Publishing Inc.