Virtualization Security

[DarkyAngel]

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. Until recently, organizations had to leverage security controls not specifically designed to protect virtual environments. However, upgrades to VMware and Microsoft virtualization solutions provide better monitoring and segregation of critical virtual systems.

In this chapter, I address general concerns related to virtualization security. I focus on what questions you should ask during a risk assessment of a virtualized environment, using Microsoft and VMware virtualization solutions as examples to demonstrate concepts.

The Basics

Before we begin, let’s be sure we understand server virtualization technology as discussed in this chapter. Figure 10-1 depicts a high-level view of a VMware environment. Virtualizing servers allows various guest operating systems to run on a single hardware platform. The administrator can manage them from a single local or Web-connected computer.

Figure 10-1: VMware Configuration (VMware, n.d.)

Figure 10-2 drills a little deeper, showing the basic configuration of Microsoft Windows Server 2008 R2 virtualization. The Hyper-V layer is the hypervisor. Hypervisors exist in all enterprise class virtualization solutions. They abstract the host server’s hardware from the virtual machines. See Figure 10-3. It’s a very thin layer that

• Optimizes virtual machine (VM) interrupt calls
  
• Manages shared memory
  
• Generally 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
  

Figure 10-2: 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.

Figure 10-3: 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 describes partitions as 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 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 hypervisor and VM security. For details about the components depicted in Figure 10-3, see the supplied reference.

Manage 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:

• Harden the Host
  
• Harden the management and VM operating systems
  
• Ensure configuration of all user roles with least privilege access
  
• Use administrator roles to implement separation of Host, RP, and VM management
  
• Secure VM files, including hard disk, backups, and archives
  
• Enable auditing
  
• Enable log management and monitoring
  
• Patch archived VMs
  
• Use VLANs and multiple network interface cards (NICs) to isolate management and VM access
  
• Use virtual networks to isolate VMs on the same host
  
• Manage proliferation
  

Harden the Host

The Host consists of the hardware and operating system that underlie the hypervisor, as shown in Figure 10-2. 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 and the SANS guide to VMware virtualization hardening guides ([Green] http://www.sans.org/reading_room/analysts_program/vmware-guide-may-2010.pdf).

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.

In addition to the management operating system, each VM OS requires the same attention. Use the appropriate security recommendations for the virtual server OS and the server role. Treat each VM as you would a physical server; the same security policies apply.

Consider an important caveat when installing and configuring anti-virus software. Avoid scanning virtual machine and virtual machine management files. Failure to exclude these files from your AV scanning process might result in VM instantiation issues.

Finally, the management server 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.

Configure Admin Roles

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 hypervisor 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.
  
• 
  

In addition, consider separating physical security administration from hypervisor 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 VM management server application.

By default, Microsoft 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=width: 500, class: grid, align: center]

[tr]

[td]Name[/td]

[td]Description[/td]

[/tr]

[tr]

[td]Read service configuration[/td]

[td]Authorizes reading configuration of the Virtual Machine Management Service[/td]

[/tr]

[tr]

[td]Reconfigure Service[/td]

[td]Authorizes reconfiguration of Virtual Machine Management Service[/td]

[/tr]

[/table]

Table 2: Hyper-V Network Operations

[table=width: 500, class: grid, align: center]

[tr]

[td]Name[/td]

[td]Description[/td]

[/tr]

[tr]

[td]Bind External Ethernet Port[/td]

[td]Authorizes binding to an external Ethernet port[/td]

[/tr]

[tr]

[td]Connect Virtual Switch Port[/td]

[td]Authorizes connecting to a virtual switch port[/td]

[/tr]

[tr]

[td]Create Internal Ethernet Port[/td]

[td]Authorizes creating an internal Ethernet port[/td]

[/tr]

[tr]

[td]Create Virtual Switch[/td]

[td]Authorizes creating a new virtual switch[/td]

[/tr]

[tr]

[td]Create Virtual Switch Port[/td]

[td]Authorizes creating a new virtual switch port[/td]

[/tr]

[tr]

[td]Delete Internal Ethernet Port[/td]

[td]Authorizes deleting an internal Ethernet port[/td]

[/tr]

[tr]

[td]Delete Virtual Switch[/td]

[td]Authorizes deleting a virtual switch[/td]

[/tr]

[tr]

[td]Delete Virtual Switch Port[/td]

[td]Authorizes deleting a virtual switch port[/td]

[/tr]

[tr]

[td]Disconnect Virtual Switch Port[/td]

[td]Authorizes disconnecting from a virtual switch port[/td]

[/tr]

[tr]

[td]Modify Internal Ethernet Port[/td]

[td]Authorizes modifying the internal Ethernet port settings[/td]

[/tr]

[tr]

[td]Modify Switch Port Settings[/td]

[td]Authorizes modifying the switch port settings[/td]

[/tr]

[tr]

[td]Modify Switch Settings[/td]

[td]Authorizes modifying the switch settings[/td]

[/tr]

[tr]

[td]Change VLAN Configuration on Port[/td]

[td]Authorizes modifying VLAN settings[/td]

[/tr]

[tr]

[td]Unbind External Ethernet Port[/td]

[td]Authorizes unbinding from an external Ethernet port[/td]

[/tr]

[tr]

[td]View External Ethernet Ports[/td]

[td]Authorizes viewing the available external Ethernet ports[/td]

[/tr]

[tr]

[td]View Internal Ethernet Ports[/td]

[td]Authorizes viewing the available internal Ethernet ports[/td]

[/tr]

[tr]

[td]View LAN Endpoints[/td]

[td]Authorizes viewing the LAN endpoints[/td]

[/tr]

[tr]

[td]View Switch Ports[/td]

[td]Authorizes viewing the available switch ports[/td]

[/tr]

[tr]

[td]View Switches[/td]

[td]Authorizes viewing the available switches[/td]

[/tr]

[tr]

[td]View Virtual Switch Management Service[/td]

[td]Authorizes viewing the Virtual Switch Management Service[/td]

[/tr]

[tr]

[td]View VLAN Settings[/td]

[td]Authorizes viewing the VLAN settings[/td]

[/tr]

[/table]

Table 3: Hyper-V Virtual Machine Operations

[table=width: 500, class: grid, align: center]

[tr]

[td]Name[/td]

[td]Description[/td]

[/tr]

[tr]

[td]Allow Input to Virtual Machine[/td]

[td]Authorizes user to give input to the virtual machine[/td]

[/tr]

[tr]

[td]Allow Output from Virtual Machine[/td]

[td]Authorizes viewing the output from a virtual machine[/td]

[/tr]

[tr]

[td]Change Virtual Machine Authorization Scope[/td]

[td]Authorizes changing the scope of a virtual machine[/td]

[/tr]

[tr]

[td]Create Virtual Machine[/td]

[td]Authorizes creating a virtual machine[/td]

[/tr]

[tr]

[td]Delete Virtual Machine[/td]

[td]Authorizes deleting a virtual machine[/td]

[/tr]

[tr]

[td]Pause and Restart Virtual Machine[/td]

[td]Authorizes pause and restart of a virtual machine[/td]

[/tr]

[tr]

[td]Reconfigure Virtual Machine[/td]

[td]Authorizes reconfiguring a virtual machine[/td]

[/tr]

[tr]

[td]Start Virtual Machine[/td]

[td]Authorizes starting the virtual machine[/td]

[/tr]

[tr]

[td]Stop Virtual Machine[/td]

[td]Authorizes stopping the virtual machine[/td]

[/tr]

[tr]

[td]View Virtual Machine Configuration[/td]

[td]Authorizes viewing the virtual machine configuration[/td]

[/tr]

[/table]

Secure VM files

By default, Microsoft VM files are located in two folders:

• %programdata%\Microsoft\Windows\Hyper-V\
  
• %users%\Public\Documents\Hyper-V\Virtual Hard Disks
  

VMware stores VM files, by default, in the directory /var/lib/vmware/Virtual Machines. Regardless of where you store your VM files, consider protecting them with the following controls:

Use network segments and access control lists to enforce least privilege for services and administrators. Block all other access.

Encrypt the folders/directories 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 virtual server administrator, allow access only to files for VMs he or she manages.

Enable Auditing

Auditing includes both file access and system monitoring. Windows TechNet (2009) provides audit policy implementation instructions. All files associated with Microsoft 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.

Enable Monitoring and Log Management

Most (hopefully all) security practitioners understand the importance of monitoring and logging network and device activity. Solutions exist in many data centers to centralize, correlate, and manage events. However, traditional solutions (pre-virtualization) cannot see what is happening in, around, and between VMs on the same hardware platform. The ability to see inside the virtual space with firewalls, IPS, IDS, and log management systems is called introspection.

Today’s hypervisors usually ship with excellent logging capabilities. The Syslog Collector in VMware vSphere 5 ([Green] http://blogs.vmware.com/esxi/2011/07/setting-up-the-esxi-syslog-collector.html) is a good example of a solution that aggregates VM logs for storage on any server you choose. Regardless of how you collect your logs, they should make their way to your SIEM application.

Packets must pass through an IPS so anomalous traffic is blocked. IPS solutions for virtual spaces are emerging, but many organizations are not prepared to configure additional devices, virtual or not. Figure 10-4 shows an optional configuration. All traffic between VMs must pass through a traditional IPS appliance before reaching its target. One downside to this approach is propagation delay. However, the delay is usually presents less risk than lack of introspection.

Figure 10-4: Routing VM Traffic through External Device (Olzak, 2011)

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 10-5 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 10-5: Virtual Machine Servicing Tool Process

(Microsoft TechNet, 2010, Servicing Offline Virtual Machines in a VMM Library)

If auto-patching of suspended VMs is not an option, create a procedure to include their files in your patch application activities. Use hardware completely isolated (logically or physically) from the production network, and launch, patch, and suspend all affected VMs.

Isolate VMs and the RP

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.

Physical Segmentation

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. In addition, consider only placing VMs with the same required trust levels on any given hardware platform.

At the most basic level, access to the management server on each hardware platform 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 hypervisor configuration. One or more additional VLANs are then necessary to connect the VMs via the remaining NICs.

Figure 10-6 shows the Microsoft 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 10-6: NIC Assignment

Virtual Segmentation

A virtual switch is created for each of the NICs you select in the process above, as shown in Figure 10-7. 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 in a Microsoft Windows Server virtualization implementation: 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 10-7: Virtual Switches

Figure 10-8 depicts a VLAN configuration using virtual switches in Windows Server 2012 to manage access across multiple VMs on the same hardware platform. Whether using virtual or physical switches, VLAN segmentation as described in Chapter 5 is a crucial part of attack surface reduction and isolation of servers sharing hardware resources.

Figure 10-8: Windows Server 2012 Virtual Switches (Microsoft, 2012, p. 10)

Manage Proliferation

Virtualization is a great productivity tool… if 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 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 procedures controls, and attitudes in place.

Conclusion

Virtualization 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.

Sursa