MCTS Self-Paced Training Kit (Exam 70-652): Securing Hosts and Virtual Machines

Lesson 1: Securing the Resource Pool

When you want to secure Hyper-V hosts and management virtual machines, you need to work at several different layers in your Hyper-V installation. Each of these layers adds significant protection to your systems. Understanding these layers will help you protect host systems and the virtual machines they run.

Securing Hyper-V Resource Pools

Securing a virtual environment requires a different approach than securing a traditional physical network. A lot of opportunities for threats exist on a traditional physical network, but most of these potential security holes are becoming well known to most administrators. In a virtual environment, several new threats arise from the very fact that end user–facing machines are now virtual machines connected to virtual networks and running on virtual hard disks. This means you must take a different approach to the security of these systems, keeping the following guidelines in mind:

• VMs are also assets Virtual machines are important assets and must be treated as such. For example, you cannot apply an antivirus engine to host servers only—it must also be applied to VMs if you are to protect your entire environment.

• Control resource pool access If you take the time to segregate the resource pool environment from the virtual workloads it runs, make sure that only trusted individuals have access to the resource pool.

• Control resource pool tool access Also make sure that only trusted individuals have access to the remote administration tools for your resource pool. Too many organizations let users run with local administrative privileges and thereby allow users access to tools they should never have.

• Control virtual engine access If your users can install their own software on their systems through local administrative access rights, what is to stop them from installing their own software virtualization engine and creating and running their own virtual machines? Make sure that if your users need access to virtual machines, these virtual machines are built and secured through your administrative staff first.

• Control access to VM files One of the simplest attacks on virtual machines is the modification or even the replacement of a virtual hard disk drive. For example, if a malicious user has access to the files that make up VMs, it is easy for that user to replace a valid VHD with his or her own untrusted VHD. This could easily cause havoc in your virtual environment. Make sure that you secure VM file paths with NTFS access rights.

• Reduce host attack surfaces Run Server Core installations on your host servers to reduce the potential attack surface for that host.

• Implement proper tools Make sure your infrastructure includes all of the appropriate tools in support of a proper security policy—antivirus engine, anti-malware tools, update and hotfix package management tools, and so on. Apply this policy to both environments, and if you need to, segregate the tools for each environment. This lets you put stronger policies in the resource pool and more open policies for the VSOs.

• Segregate network traffic Make sure you protect network traffic from your resource pool. Use virtual local area networks (VLANs) to control the traffic that manages and maintains host servers, and separate it from any traffic that emerges from the virtual workloads.

These are only a few of the items you’ll need to think about as you secure both host servers and the VMs they run.

Understanding the Potential Hyper-V Attack Surface

Chapter 2, “Configuring Hyper-V Hosts,” discussed the creation of a segregated security context for resource pools. If you were running hypervisors from Citrix or VMware, the security context of the resource pool would automatically be separate from the Windows security context you run in your virtual workloads because both of these hypervisors run on Linux code. But when you are running host servers that rely on the same operating system as the virtual machines you run, you must make a conscious decision to segregate the security context of the resource pool from the virtual environment.

This means creating a separate Active Directory Domain Services forest for resource pools and for virtual service offerings and making sure they are not linked together in any way, such as through multidirectional trusts. When you segregate contexts in this way, end users have no access to the resource pool because they do not have accounts within the resource pool. The resource pool then contains only administrative and technical accounts. This also means that resource pool administrators and technicians must log on to the resource pool with different credentials than those they use in the virtual workload environment.

Remember that so far, your environment can be in one of two configurations. If you run only Hyper-V host servers in your resource pool and you run SCVMM to control them and the VMs they operate, you will have a homogeneous resource pool (see Figure 8-2). If you run multiple hypervisors in your resource pool and you manage them through SCVMM, you will have a heterogeneous resource pool (see Figure 8-3). In either case, the resource pool should be contained within its own AD DS utility forest. This forest can consist of one single root domain and should contain only administrative and technical accounts.

Few organizations deliberately build out heterogeneous resource pools from scratch. Instead, most of the organizations that run heterogeneous resource pools do so because they already had some form of virtualization technology in place when they introduced Hyper-V into the mix. Therefore, it is reasonable to assume that these organizations already have some form of security in place for the other hypervisors (in this case, Virtual Server and VMware ESX Server).

The new factor in both the heterogeneous and the homogeneous resource pools is Hyper-V and the Windows Server 2008 operating system it relies on. When you add the Hyper-V role to a host server running either the full or the Server Core installation of Windows Server 2008, the role changes the potential attack surface of the computer. It does so by modifying three aspects of the default Windows Server 2008 installation:

• Installed files New files are installed in support of the Hyper-V role.

• Installed services Services are installed in support of the Hyper-V role.

• Firewall rules Rules are modified or enabled with the addition of the Hyper-V role.

Maintaining the integrity of these three aspects is one of the main goals of the security implementation you perform on Hyper-V host servers.

Understanding Security Features for Host Computers

With Windows Server 2008, Microsoft has enhanced and improved the base security features of the operating system, as well as provided new security capabilities. The security features of Windows Server 2008 that apply to Hyper-V hosts include:

• Software restriction policies These policies can control which code is allowed to run within the network. This includes any type of code—corporate applications, commercial software, scripts, and batch files—and can even be defined at the dynamic-link library (DLL) level. This is a great tool to prevent malicious scripts from even being able to run in your network. In fact, in a Hyper-V resource pool, you can use this policy to disable all scripts except for PowerShell scripts which are more secure than other types such as Visual Basic scripts.

• Network Access Protection (NAP) Windows Server 2008 can now enforce client health levels before they are allowed to connect to your network. Given the right infrastructure, NAP can even update the clients before they are given full network access. In a Hyper-V utility domain, you can rely on NAP to make sure all of your administrative workstations are completely up to date in terms of security and other updates before they can connect to a host server or SCVMM management server.

• Windows Server Firewall with Advanced Security To facilitate the connections remote systems make with your servers, Windows Server 2008 now provides an integrated interface for IP-level security (IPsec), with incoming and outgoing communications controls. In a Hyper-V resource pool, you can ensure that any remote connections made to host or management servers are completely secure.

• Public Key Infrastructure Windows Server 2008 includes improved PKI, Active Directory Certificate Services (AD CS), that supports auto-enrollment and automatic X.509 certificate renewal. It also supports the use of delta certificate revocation lists (CRLs), simplifying the CRL management process. In large Hyper-V environments, you can rely on AD CS to support encrypted communications between host servers, management servers, and administrative workstations. These communications should always be encrypted because they contain sensitive information such as administrative passwords and configuration file paths.

  MORE INFO: ACTIVE DIRECTORY CERTIFICATE SERVICES

  For more information on Active Directory Certificate Services, refer to MCTS Self-Paced Training Kit (Exam 70-640): Configuring Windows Server 2008 Active Directory by Holme, Ruest, and Ruest. Find it at http://www.microsoft.com/learning/en/us/books/11754.aspx.

• Digitally signed Windows Installer Packages Windows Server 2008 supports the inclusion of digital signatures within Windows Installer packages so that administrators can ensure that only trusted packages are installed within the network, especially on host servers.

• Multiple password policies AD DS supports the application of multiple password policies, letting you require highly complex passwords for administrators and less complex passwords for end users. In environments that choose not to use a utility forest for the resource pool, you can rely on these password policies to ensure that resource pool administrators have highly complex passwords.

• Role-based access control (RBAC) Windows Server 2008 includes the Authorization Manager, which supports the use of role-based access controls for applications. RBAC stores can be in either Extensible Markup Language (XML) or within AD DS. In a resource pool, you rely on RBAC to assign least-privilege rights to administrators and technicians.

• Permissions management and access-based enumeration It is now possible to view effective permissions with Windows Server 2008 through the Properties dialog box for file and folder objects. Also, users will only be able to view items they actually have access to, as opposed to previous versions, where users could see all of the contents of a share, even if they could not open the documents. This is useful in resource pools where you can hide the files that make up VMs from unauthorized users.

• Auditing Auditing in Windows Server 2008 is now operations-based. This means that it is more descriptive and offers the choice of which operations to audit for which users or groups. You can also audit AD DS changes and use the audit reports to reverse those changes if they were performed in error. This is very useful in resource pools because it tracks all changes to privileged objects.

• Reset security defaults It is now much simpler to use the Security Configuration Wizard (SCW) to reapply computer security settings from base templates. In resource pools, you rely on the SCW to create the base security template for your host servers.

• Small footprint servers Through the use of Server Core, you can deploy servers that provide a limited set of services and a smaller attack surface. This is the preferred host operating system for any Hyper-V resource pool.

• Constrained roles and features Each role or feature only installs components that are absolutely required to make it run. This lets you control exactly what is installed on your servers. For example, when you enable the Hyper-V role, you can know exactly what has changed on your host system.

• BitLocker drive encryption You can now fully encrypt system and data drives on servers so that malicious users cannot access their contents even if they disappear with the server. This is an absolute must on any host server that is not properly protected through an access-controlled datacenter.

• Device control Through device control, you can ensure that malicious users cannot connect rogue Universal Serial Bus (USB) devices to your servers, or even to your workstations, to steal the contents of your shared folders or collaboration environments. In resource pools, this policy ensures that no one can take unauthorized copies of your VHDs.

This list includes a few items that can help secure your resource pool environment. Some are simpler to implement than others and in some cases, only larger installations will implement the full suite of features.

Securing Hyper-V Hosts

When you prepare to secure the resource pool, you need to look at different security aspects. This pool must include very strict protection strategies because it is so easy to walk away with an entire virtual machine. After all, a VM is nothing but a set of files in a folder. As such, the security plan for resource pools requires that particular attention be paid to the levels identified in Table 8-1.

Table 8-1 Applying the Security Plan to Resource Pools

Content	Comments
Data protection	Pay special attention to the storage containers that include the files that make up virtual machines.
Application Hardening	Secure the installations of Windows Server Hyper-V. Rely on the Hyper-V Security Guide and the contents of this chapter to do so.
Physical environment	Make sure datacenters have sufficient power and cooling resources to run host servers.
Physical access controls	Pay special attention to physical access to servers. All servers, especially remote servers, should be under lock and key.
Communications	Make sure all resource pool administrators and technicians understand their responsibilities in terms of security practices. These are highly trusted roles.
Surveillance	If possible, have sign-in and sign-out sheets for administrators physically accessing the datacenter.
Security configuration	Pay special attention to the following: Server Core configuration Service hardening Security Configuration Wizard settings for host servers Limited role installations on each host; do not run any other role on the host parent partition Configuration of virtual machine management systems BitLocker Drive Encryption for host servers in remote offices Device control to ensure that unauthorized USB disk drives cannot be connected to any physical server.
Anti-malware and antivirus	Implement Windows Defender along with proper antivirus technologies on the parent partitions of host servers. Configure antivirus software to bypass Hyper-V processes and directories for improved performance. This means you need to exclude the VMMS.exe and VMWP.exe processes (in %SystemRoot%\System32) as well as the directories that contain virtual machine configuration files and VHDs from active scanning. You have two ways to do this. You can exclude the actual directories, which contain the VHDs and the configuration and other files that make up the VMs; this is the recommended approach. Or you can exclude the VM file types such as .vhd, .avhd, .vfd, .vsv, .xml, and .bin. This latter approach entails more risk because it can include files that are not necessarily part of a VM. Also run antivirus engines from within the VMs to scan their own contents.
General AD DS security	Implement very tight permissions management on the utility forest. Implement software restriction policies to ensure that no malicious code is allowed to run in this domain.
File system	Secure the file system with NTFS permissions to protect VSOs. Rely on digitally signed Windows Installer packages for all third-party or custom product installations.
Print system	Limit the print systems in this network. If printing is required, administrators can copy the contents to the production network.
.NET Framework security	Applicable to the full installations used in the System Center Virtual Machine Manager systems you create to administer the resource pool—they rely on Windows PowerShell to run cmdlets.
Internet Information Services (IIS)	Avoid the installation of IIS as much as possible. Deploy Microsoft Virtual Server through SCVMM to install it without IIS if you need to add life to 32-bit hardware. If you use a Self-Service SCVMM Portal, run the portal in controlled virtual machines.
System redundancy	Ensure business continuity and redundancy of your host servers. This was covered in Chapter 3, “Completing Resource Pool Configurations.”
User identification	Rely on smart card or two-factor authentication for administrators in very secure environments.
Resource access	Only administrative accounts are required in this network.
Role-based access control	Assign least-privilege access rights to both administrators and technicians in this network.
Access auditing/monitoring	Turn on auditing, as well as AD DS auditing, to track all changes.
	Consider running System Center Operations Manager in larger environments.
Perimeter networks	There should be no perimeter network in the resource pool, but you should still properly configure the Windows Server Firewall with Advanced Security to control access to host servers.
Virtual Private Networks (VPNs)	Rely on VPN connections for all remote administration.
Routing and Remote Access (RRAS)	Implement a remote access authentication service for administrators working remotely.
Secure Sockets Tunneling Protocol (SSTP)	Ensure that all remote communications, as well as internal intra-server communications, are encrypted.
Public key infrastructures (PKIs)	Implement Active Directory Certificate Services in support of smart card deployment and software restrictions.
Network Access Protection (NAP)	In larger environments, implement NAP to ensure that all machines that link to the resource pool have approved health status.

Resource pools are a new concept in IT and therefore need particular attention to detail when it comes to the implementation of their security settings. Make sure you fully understand the scope of protection you need to apply to this infrastructure.

In Hyper-V, your security plan must focus on several key aspects of the host server:

• Begin by properly configuring the server installation. As mentioned in Chapter 2, you should run Server Core installations. Only enable the settings that are absolutely required to remotely administer this installation as per the instructions in Chapter 2.

• Have multiple network interface adapters for each host server. You run multiple adapters to be able to dedicate an adapter to administration traffic. In fact, this is a basic recommendation of the Hyper-V Installation Wizard (see Figure 8-4). When an adapter is not assigned to virtual networks, it will only communicate with the physical host server. Make this a best practice for each host server configuration.

• Focus on the Hyper-V architecture during the application of your security measures. As documented in Chapter 1, “Implementing Microsoft Hyper-V” the Hyper-V architecture is based on partitions. The parent partition runs the core operating system for the host and manages all virtual machine communications with physical resources. Child partitions run guest operating systems as virtual machines. Ideally, they will be running enlightened guests and use proper communication channels through the VMBus. If not, the VMs will require device emulation, which is one more channel to manage.

• Make sure that applications only run in child partitions or VMs. You should not install any additional applications—except for utilities such as antivirus engine, SCVMM agent, and so on—in the parent partition to minimize the operational overhead of this partition as well as minimize the requirement for updates.

  

  Figure 8-4 The Hyper-V Installation Wizard recommends reserving one adapter for management purposes.

• Secure the storage containers that will include the files that make up your VMs. Ideally, you will have redirected the default locations for both VHDs and virtual machine configuration files in Hyper-V as outlined in Chapter 4, “Creating Virtual Machines.” In addition, you should store the files that make up VMs on separate spindles from the operating system for the parent partition. If possible, this storage should be separate from the host server itself. If you are running clustered host servers (as you should in most cases), you will be using separate shared storage to store VM files. VM files should also be kept together as much as possible to make them easier to manage and protect. If the VM configuration file is in one location, the VHD files are in another, and potential snapshots are in yet another, properly securing VM files becomes difficult if not impossible. When you move the default locations, you must ensure that NTFS access rights are configured properly. Most are configured by default—including Administrators, System, and Creator Owner permissions—but some must be configured manually. The settings that must be configured manually are for three special accounts found in the local system: Interactive, Batch, and Service accounts. Use the Advanced Settings in the Security dialog box of a folder’s properties to assign the required settings for each of these three special accounts (see Figure 8-5).

  

  Figure 8-5 Assigning proper permissions to the three special accounts: Interactive, Batch, and Service

• Centralize all file resources—such as ISO files, update files, and virtual floppy drives—so that all host servers can access them from a single location. In larger sites, this location will be a clustered file server to make sure it is highly available.

• Consider encrypting all virtual machine files and resources to protect them from theft. Use BitLocker Full Drive Encryption to do so because you cannot use the Encrypting File System to store virtual machine files. Keep in mind that encryption adds some overhead to the operation of the VMs.

  EXAM TIP: BITLOCKER AND VMS

  

  Remember that BitLocker is not supported in a VM because it cannot access either a USB port—not supported in this version of Hyper-V—or the Trusted Platform Module (TPM) chip that might be contained on the server’s hardware. Therefore, you cannot run BitLocker in a child partition.

• Make sure that the administrators and technicians that have access to the parent partition are granted only appropriate rights. Anyone who can access the parent partition can make global modifications to the Hyper-V configuration and possibly break all of the child partitions that run on this host. This is why it is so important to assign role-based access rights. RBAC assignments are covered further in this lesson.

• Consider the security or sensitivity level of the VMs you run on a particular host. Do not run unsecured VMs on a highly secure host. Instead, try to match security levels between hosts and the VMs they run.

Child partitions are automatically segregated from the parent partition through Hyper-V’s internal architecture. However, it is easy to blur this segregation when administrators are responsible for both the resource pool and the virtual workloads it runs. Ideally, you will be able to assign separate roles to your IT administration team and ensure that the operators that perform one duty are not responsible for the other. If you cannot have different administrators for each role, you should at least make sure your administrators use separate accounts for each operation as mentioned earlier in the introduction to this chapter.

These recommendations are summarized in Table 8-2, including important caveats.

Table 8-2 Parent Partition Summary Security Recommendations

Recommendation	Benefit	Caveat
Default Installation: Install Hyper-V on Windows Server 2008 Server Core.	The attack surface for the host server partition is minimized.	Management is either from a remote console, the command line, or through WMI actions.
	The host attack surface is reduced.	Server Core does not include the .NET Framework and therefore, no Windows PowerShell.
	System uptime improves because there are fewer components to update.	Initial installation and configuration must follow strict instructions (see Chapter 2).
Network Configuration: Install at least two NICs: one for host management and other one(s) for child partitions.	Using a separate adapter for host communications ensures that there is no possibility of compromising management traffic. If you share host management communications with child partition communications, someone on the child network can possibly “listen in” on host communications.	Ideally, you reserve two adapters for host management to avoid a single point of failure. When an adapter is not selected during the creation of virtual networks, it is automatically reserved for host management communications. This must be a conscious decision on the administrator’s part.
Hyper-V Architecture: Segregate parent and child partitions.	The Hyper-V architecture provides natural segregation of parent and child partitions.	Run enlightened guest operating systems as much as possible to use proper communication channels through the VMBus and not device emulation.
Host Applications: Do not run applications in parent partitions.	The parent partition is designed to run the hypervisor only. Do not install any other application (core utilities are OK, of course) in the parent partition.	Install applications only in VMs. Installing an application or server role other than Hyper-V into the parent partition can impact performance and force you to update host systems more often.
Dedicated VM Storage: Configure separate logical partitions to store VM files.	Creating custom folders for VM file storage lets you bring all of a VM’s files together into a single folder and makes them easier to manage.	If you specify a different location, ensure that you set the appropriate permissions on the new folder.
Resource Storage: Configure separate storage for VM resource files.	Regroup all VM resource files—VFDs, ISO files, executables, and updates—in a shared folder that is accessible by all host servers.	Ideally, this shared folder would be highly available and would run on a failover cluster.
Storage Encryption: Use BitLocker to protect VM files and other file-based resources.	In highly secure or unprotected environments, modify the default location of file-based resources on host servers and run BitLocker Full Drive Encryption on these storage containers to protect from data theft.	Run BitLocker on both the system and the data partitions. You must include the system partition to protect the data partition encryption keys because they are stored on the system partition by default. Also note that you cannot encrypt storage area network volumes because they do not run the Windows Server operating system.
Host Management: Maintain a clear separation between the resource pool administrators and VM administrators.	Segregating security contexts between the resource pool and the virtual workloads helps protect resource access.	By default, child partition administrators are not granted administrative access to the management partition. Maintain this as much as possible. Also, place your host servers into a utility forest. This will require at least two additional domain controllers, but they can be virtual machines.
VM Sensitivity Level: Run sensitive VMs on highly secure hosts.	Match the sensitivity level of a VM with the security level of the host to provide adequate protection for the VMs.	Do not run highly sensitive VMs such as domain controllers on unsecured host servers. Ideally, match host and VM security levels. For example, you can create multiple levels of security for host servers: Low for test and development environments. Medium for VMs running open services such as public Web sites or public file shares. High for sensitive workloads such as DCs.

Use these best practices when working with Hyper-V hosts. This will secure the host but will not secure the remainder of the resource pool components. These must also be secured to ensure that the entire host environment is secure.

Securing the Resource Pool

The resource pool usually contains several components in addition to the host servers you run. These components can include both required and optional elements. Required elements must be part of the resource pool for it to function properly, whereas optional elements may not be necessary for small datacenters, but will be for medium to large datacenters. These components include:

• Host Servers Ideally, your host servers will be homogeneous and will rely on a single, secured configuration image.

• Domain Controllers Whether you use a utility forest or you run a mixed forest—where both host servers and production virtual machines operate—you need domain controllers, because Hyper-V hosts should belong to a domain to simplify access and centralize security settings. Even if you run a separate utility forest, these DCs can be virtual machines and can run on the same hosts as your production VMs. Make sure, however, that even if the DCs run on the same hosts, they are not connected to the same virtual networks as the production VMs you run.

• Central File Share This file share should store virtual machine resources such as ISO files, VFDs, executables, and updates. Again, this can be a VM, but it should use a segregated virtual network. Ideally, this file share will be highly available and will be running Failover Cluster services.

• Administrator Workstations Ideally, the workstations your administrators and technicians rely on will be running Windows Vista and will be using User Account Control (UAC) to ensure that they are aware of each time they perform an activity that requires elevated rights. These workstations can be virtual machines and can be accessed through Remote Desktop Connections. Using Windows Vista as the operating system for the workstation allows you to use network-level authentication for the connections, providing a higher level of security for the communication (see Figure 8-6). Again, if the workstations are VMs, they should not be connected to the same virtual networks as your production VMs.

  

  Figure 8-6 Using secure communications for the Remote Desktop

• System Center Virtual Machine Management Server (Optional) Larger environments will want to run SCVMM to simplify host and VM management. Again, this machine can be a VM that is on an isolated virtual network.

• System Center Database Server (Optional) Very large environments with more than 100 hosts should run Microsoft SQL Server on a separate system for the SCVMM database. Ideally, this machine will be clustered through Failover Cluster services to make it highly available. This database can run on VMs and could possibly be running on the same servers as the central file share. In addition, this server could provide the required database services for any number of additional System Center tools if you choose to run them.

• SCVMM Library Server (Optional) If you are running SCVMM, your central file share will be contained within an SCVMM Library. This can run on a separate VM and could share the role with the database servers.

• System Center Essentials (Optional) Small to medium environments—those with fewer than 500 PCs and 30 servers—may want to deploy System Center Essentials, a tool that regroups the functionality of other independent System Center products such as Operations Manager, Configuration Manager, and more. If you deploy System Center Essentials, it can share the database server with SCVMM. This machine should also be on a segregated virtual network. In terms of security, System Center Essentials supports controlled configuration management, updates to both hosts and VMs, and system monitoring.

• System Center Operations Manager (Optional) Organizations wanting to take advantage of Performance and Resource Optimization (PRO) in SCVMM will want to deploy OpsMgr along with SCVMM. This can also be within virtual machines and can also take advantage of the database server. This machine should be on a segregated virtual network.

  MORE INFO: OpsMgr AND SECURITY

  Operations Manager can also be used to control security because it includes the ability to centrally collect and filter audit records from source computers. If you run a number of Hyper-V hosts and you want to audit all access as well as privileged activity on these servers, you can use Windows Server 2008 to audit these events and then rely on OpsMgr to collate them centrally and alert you in the event of violations.

• System Center Data Protection Manager (Optional) Environments wanting to centralize all backup and recovery operations for both hosts and VMs may want to deploy DPM. DPM provides the ability to centrally control all backups, collate all Volume Shadow Copy Services (VSS) snapshots into a central location, and restore to any point in the enterprise. More on DPM is covered in Chapter 9, “Protecting Hyper-V Resource Pools.” However, note for now that DPM can also run in a VM that is on a segregated virtual network and can also rely on the shared database server.

• System Center Configuration Manager (Optional) Larger environments wanting to centralize system configuration and application deployment can deploy SCCM within the resource pool. In terms of security, SCCM can offer configuration controls through its Desired Configuration Management feature and can control updates to both hosts and VMs. It should run within a VM on the segregated virtual network and share the database server.

• Windows Server Update Services (Optional) Environments that do not run either SCCM or System Center Essentials will want to deploy WSUS in support of a special update service within the resource pool and ensure that it is not linked to the production network in any way. This can also be a VM on a segregated virtual network and can also rely on the shared database.

• Network Access Protection Server (Optional) Larger environments will want to run a separate NAP environment to ensure that all machines comply with security standards before they can connect to the network. The NAP server can be in a VM on the segregated virtual network.

  IMPORTANT: NAP AND HOST SERVERS

  Be very careful if you run NAP in a host environment. Do not apply NAP rules to host servers because you may find that your host can no longer connect to any network, which would cause all of the VMs it runs to fail. Apply NAP rules only to workstations and other non-critical components. You do not want to find yourself in a situation in which your console cannot connect to a host in an emergency because you are not running the appropriate updates.

• Certificate Servers (Optional) Run Active Directory Certificate Services if you want to secure all communications with server-side certificates. AD CS lets you generate your own certificates and assign them to each server in your resource pool infrastructure—hosts, SCVMM, and more. Using certificates ensures that all hosts are properly identified when you connect to them and can support remote connection encryption through the Secure Sockets Layer. Certificate servers can also be useful to support virtual private network connections using the new Secure Sockets Tunneling Protocol (SSTP) built into Windows Server 2008. The certificate server is an ideal candidate for virtualization because the root server should be taken offline to protect it. Again, connect these servers to the segregated virtual network.

  MORE INFO: USING SELF-SIGNED CERTIFICATES

  In smaller organizations, you can also use self-signed certificates instead of the certificates you would obtain through AD CS. This avoids having to run an AD CS infrastructure. To use self-signed certificates, download the SelfSSL.exe, which is a utility in the IIS 6 Resource Kit that can be found at http://www.microsoft.com/downloads/details.aspx?familyid=56FC92EE-A71A-4C73-B628-ADE629C89499&displaylang=en. You can then use it to generate a certificate for each server and install this certificate within the Trusted Root Authorities container of each machine that will interact with the servers.

• Routing and Remote Access Server (Optional) You might require RRAS servers to support remote connections from outside your network. Rely on SSTP to support virtual private network connections and ensure all remote connections are completely secure. These can also be VMs and should be on the segregated virtual network.

As you can see, a complete resource pool can include several components (see Figure 8-7). It can become even more complicated if your host systems run different hypervisors. If so, you will need to rely on the vendor’s recommended security practices to tighten security on these hosts.

Using the Security Configuration Wizard

One of the best tools contained within Windows Server 2008’s full installation for the application of security parameters and the lockdown of servers is the Security Configuration Wizard (SCW). This tool is designed to generate security profiles based on the role of a server within your network. SCW lets you configure four key components of a system:

• Tighter service configurations through pre-defined role-based configurations.

• Tighter network security.

• Tighter registry settings.

• Implement an audit policy.

These are the default controls you’ll find in SCW. They are quite sophisticated.

Perhaps the best part of SCW is that it provides complete explanations for each of the settings it will modify. You now have a single place to determine what a particular security setting will modify and why. Just click the arrow located before the item name to see explanations for the item (see Figure 8-8).

You can use SCW to create new policies, edit existing policies, apply policies, and—perhaps its best feature—roll back the assignment of a security policy. Security policies are generated from a base server configuration. Unfortunately, SCW does not include specific information on the Hyper-V role, which is odd because it covers every other role contained within Windows Server 2008 (see Figure 8-9). It does, however, understand the Hyper-V services and can support the generation of a security configuration that supports Hyper-V (see Figure 8-10).

You launch the Security Configuration Wizard through the Administrative Tools on any Windows Server 2008 running the full installation. You can use a full installation of Windows Server 2008 with Hyper-V to generate the SCW configuration file and then apply it remotely to host servers running the Server Core installation.

SCW includes a corresponding command-line tool, SCWCMD.exe, which lets you mass-produce the application of security policies generated through the SCW graphical interface. However, this tool only works on the local machine and cannot apply security policies to remote machines. However, SCW produces output in XML format, which—although incompatible by default with Group Policy Objects (GPOs)—can be converted into a GPO. You can then use a GPO to assign the security settings to your Server Core machines.

To convert SCW output into a readable format for inclusion in a GPO, you must use the following command line:

scwcmd transform /p:PolicyFile.xml /g:GPOName

This transforms the XML file into a new GPO and stores it in AD DS. The GPO must then be applied using domain administrator privileges. Policies are saved by default under the %SystemRoot%\Security\MSSCW\Policies folder. The resulting GPO will include the contents of the SCW XML file and assign them to various sections of the GPO. These settings will include content for security settings, IP Security policies, and Windows Firewall (see Figure 8-11). This new GPO is stored in the Group Policy Objects container in AD DS and must be linked to appropriate organizational units (OUs) to be applied. Ideally, you create an OU for the host servers, move all of the host server accounts to this OU, and assign the GPO to this OU. It will then be processed by each of your host servers. Use the Group Policy Management Console to perform these tasks.

SCW policies are much more powerful than any other single component for the application of security settings to Windows servers.

Protecting Hosts from Removable Devices

Windows Vista introduced a new capability for the Windows operating system—the ability to configure removable device controls through the use of Group Policy. This is done through the control of device installations, letting you manage which devices can be installed on any given system. For example, you can use this policy to prevent a malicious user from plugging in a removable disk drive and walking away with your intellectual property. When you remember that a VM is nothing but a set of files in a folder, you soon realize that protection of these files is an important part of any host or resource pool security policy.

The application of this policy is simple. Basically, you create a list of approved devices on your network and include it in your GPO. For example, you might let users install USB mice and keyboards, but prevent them from installing either Flash memory devices or external disk drives. Apple iPods and iPhones, Windows Mobile Devices, and digital music players, for example, are also disk drives that can be used to transport very large amounts of information—most of these devices can store multiple GB of information. Because you can’t prohibit the use of these types of devices on your network, you must control their use through a properly designed GPO.

Ideally, you will assign this policy to both host servers and administrative workstations. This means that you should implement removable device controls in the resource pool so that no one can connect a USB drive to a server and use it to remove copies of your virtual machines. In addition, you should apply it to PCs linked to the virtual service offerings you run in production to ensure that no one can use a PC from your production domain to connect a device and somehow traverse the VSO domain to the resource pool utility domain and steal virtual machines. The best protection is complete protection.

In the resource pool, you will probably add these settings to a new GPO because they are required for both host servers and administrative workstations. And although you can use these controls to prevent installation of all devices, it is best to allow the installation of authorized devices. To do this, you need to be able to identify devices. You have two ways to do this:

• You can use device identification strings—which are contained both within the device and within the .inf file that comes with the driver—to block or authorize devices. The two different types of device ID strings are hardware IDs and compatible IDs. Hardware IDs provide the most direct match between a device and its driver. Compatible IDs provide a list of compatible drivers that can give you at least basic functionality for the device. If you use these IDs to allow or deny devices, you must include all of the possible IDs for the device. If not, multifunction devices especially might be blocked at one level but not at another.

• You can use device setup classes to control devices. Classes divide devices into groups that use the same installation process. Classes are identified by globally unique identifiers (GUIDs), which are complex numbers that uniquely represent a class of devices. For example, if you want to block USB disk drives, block the GUID for these devices and no USB disk drive can be installed on your systems.

Device authorizations are set up through Group Policy. Use a computer that has the Group Policy Management Console installed and follow these steps:

1. Launch the GPMC. To do so, click Start, click Administrative Tools, and then click Policy Management Console.

2. Because this policy affects every physical computer in the resource pool, apply it to the OU that contains both host servers and physical workstations. This can be applied through any GPO that would affect all physical systems. If the GPO exists, right-click and select Edit. If it doesn’t, create it, name it, link it to the appropriate OU, and then edit it.

3. Go to the Device Installation settings by navigating through Computer Configuration, then Policies, then Administrative Templates, then System, and then click Device Installation (see Figure 8-12). Also set up the policies for Removable Storage at Computer Configuration, then Policies, then Administrative Templates, then System.

   

   Figure 8-12 Setting device restrictions in a GPO

4. Set up the policies according to the recommendations in Table 8-3. Examine the explanation for each setting to learn more about its intent and configuration possibilities. Each setting that is not configured relies on the default behavior for that setting. Close the GPO when done.

5. Test the settings with various devices of each type you authorized and de-authorized.

Your host environment is protected as soon as you apply the GPO and the GPO is updated on each host and workstation.

Table 8-3 Secure Virtual Service Offerings

Location	Setting	Recommendation
Device Installation	Treat All Digitally Signed Drivers Equally In The Driver Ranking And Selection Process	Not Configured
	Turn Off Found New Hardware Balloons During Device Installation	Not Configured
	Do Not Send A Windows Error Report When A Generic Driver Is Installed On A Device	Not Configured
	Configure Device Installation Timeout	Not Configured
	Do Not Create System Restore Point When New Device Driver Installed	Not Configured
	Allow Remote Access To The PnP Interface	Not Configured
Device Installation Restrictions	Allow Administrators To Override Device Installation Restriction Policies	Configure only if you fully trust your administrators or anyone with administrative access rights.
	Allow Installation Of Devices Using Drivers That Match These Device Setup Classes	Enable and add the appropriate GUID entries.
	Prevent Installation Of Devices Using Drivers That Match These Device Setup Classes	Enable and add the appropriate GUID entries.
	Display A Custom Message When Installation Is Prevented By Policy (Balloon Text)	Enable and type in an appropriate violation of policy message.
	Display A Custom Message When Installation Is Prevented By Policy (Balloon Title)	Enable and type in an appropriate message title.
	Allow Installation Of Devices That Match Any Of These Device IDs	Not Configured.
	Prevent Installation Of Devices That Match Any Of These Device IDs	Not Configured.
	Prevent Installation Of Removable Devices	Not Configured.
	Prevent Installation Of Devices Not Described By Other Policy Settings	Enable.
Removable Storage Access	Time (In Seconds) To Force Reboot	Not Configured.
	CD And DVD: Deny Read Access	Not Configured.
	CD And DVD: Deny Write Access	Enable only in very secure environments. Users often rely on this for backups.
	Custom Classes: Deny Read Access	Enable only if you have appropriate GUIDs.
	Custom Classes: Deny Write Access	Enable only if you have appropriate GUIDs.
	Floppy Drives: Deny Read Access	Not Configured.
	Floppy Drives: Deny Write Access	Not Configured.
	Removable Disks: Deny Read Access	Not Configured.
	Removable Disks: Deny Write Access	Enable.
	All Removable Storage Classes: Deny All Access	Enable in very secure environments.
	All Removable Storage: Allow Direct Access In Remote Sessions	Enable in very secure environments.
	Tape Drives: Deny Read Access	Enable.
	Tape Drives: Deny Write Access	Enable.
	WPD Devices: Deny Read Access	Enable only if your users do not use smart phones or Pocket PCs.
	WPD Devices: Deny Write Access	Enable only if your users do not use smart phones or Pocket PCs.

Securing VM Files with BitLocker

With the release of Windows Vista, Microsoft introduced BitLocker Full Drive Encryption. BitLocker lets you encrypt the contents of your operating system volume so that malicious attackers cannot access them. BitLocker is most often used for mobile systems or systems that contain sensitive data and leave your office premises.

You can also use BitLocker to protect server drives because it is also included in Windows Server 2008. You might apply BitLocker to the storage container of your virtual machines so that even if malicious attackers steal the hardware or hard drives that make them up, they can’t access any data that may reside inside them. This, however, is an extreme measure that would only be applied in very secure environments, because partition encryption adds a certain amount of overhead to the operation of a server. A more likely scenario is the encryption of host server drives that are in remote offices. This way, if someone walks off with a physical server in a remote office, not only does she not have access to any of the virtual machines that may be located on the host, but the host server itself is also protected.

To be able to use BitLocker, your system must:

• Include a minimum of two NTFS partitions: a system volume and an operating system volume. The system volume is the boot partition and only requires about 1.5 GB of space.

• Include a USB flash drive and a BIOS that supports reading and writing to a USB flash drive at startup.

• Ideally, include a Trusted Platform Module (TPM) version 1.2 or later microchip.

• Ideally, include a Trusted Computing Group (TCG)–compliant BIOS.

BitLocker can either be run through the use of an external USB flash drive or through the TPM module. A flash drive can store the encryption key used to lock and unlock the operating system partition. However, using a USB drive is risky—it can be lost or stolen. This is why it is ideal to use a server that has the full TPM components. In this case, the encryption key is stored securely within the TPM chip and cannot be stolen.

If the host servers you use for remote offices include these capabilities and you intend to encrypt their contents, use the following procedure:

1. Begin by creating two partitions during installation. Both partitions must be primary partitions. In addition, the smaller partition should be set as active. Both partitions must be formatted with NTFS. You can use the installation media to create these partitions.

2. Install Server Core into the operating system partition.

   NOTE: THE BITLOCKER DRIVE PREPARATION TOOL

   If your drive partitions are already created and the operating system is installed, you can use the BitLocker Drive Preparation Tool to restructure the partitions as needed. Find the tool at http://support.microsoft.com/kb/933246.

3. When Server Core is installed, perform the post-installation configurations found in Lesson 1 of Chapter 2.

4. Install the BitLocker feature:

   start /w ocsetup BitLocker

5. Restart the system as soon as BitLocker is installed. When the system restarts, you’ll be ready to configure BitLocker. Begin by getting BitLocker to list compatible drives. Make sure you go to the appropriate folder to do this:

   cd\windows\system32
   cscript manage-bde.wsf -status

6. Encrypt the system drive:

   cscript manage-bde.wsf –on C: -RecoveryPassword NumericalKey –RecoveryKey
   BitLockerDrive –StartupKey BitLockerDrive

   BitLockerDrive is the drive letter you gave to the system partition. NumericalKey is a 48-digit number, divided into 8 groups of 6 digits, using hyphens to separate groups. Each group of 6 digits must be divisible by 11 but not greater than 720,896.

You can repeat the last command to encrypt any other drive on the host server. From this point on, all data on the drives is encrypted and must be decrypted with the proper key to be read.

Use BitLocker with caution on your host servers. Apply it only where it is deemed absolutely necessary.

Auditing Object Access in the Resource Pool

Highly secure environments will need to audit all object access within their resource pool to track who is performing which operation within the environment. Auditing lets you track resource usage and monitor log files to determine that users have appropriate access rights and that no user is trying to abuse his or her rights.

Auditing is a two-step process. First, you must enable the auditing policy for an event. This is done within a Group Policy Object. Then you must turn on the auditing for the object you want to track and identify who you want to track. Windows Server 2008 lets you audit several different types of events:

• Account logon events

• Account management

• Directory service access

• Logon events

• Object access

• Policy change

• Privilege use

• Process tracking

• System events

Use the following procedure to define the audit policy for the resource pool. Perform this procedure on a computer that has the Group Policy Management Console installed and use domain administrator credentials.

1. Launch the GPMC by clicking Start, clicking Administrative Tools, and then clicking the console shortcut. Expand the local forest when the tool is open.

2. Create a new GPO. Right-click the Group Policy Objects container and choose New. Name the Policy Audit Policy and click OK.

3. Right-click the new policy and choose Edit to launch the Group Policy Editor.

4. Expand Computer Configuration, then Policies, then Windows Settings, then Security Settings, and then Local Policies. Click Audit Policy.

5. Double-click each setting you want to change to modify it. For example, if you double-click Audit Logon Events, the Audit Logon Events Properties dialog box opens, letting you configure it to identify successes and failures as needed.

6. Repeat step 5 for any setting you want to turn on and then close the Group Policy Editor. Policies are automatically saved as soon as you make the change in the Editor.

The audit policy is turned on. Now you need to tell the system which objects you want to audit. For example, if you want to audit all changes to the folders where you store VM files, use the following procedure on a host server:

1. Launch Windows Explorer and move to the drive containing the VM files.

2. Right-click the folder containing the VMs—for example, VMStore—and choose Properties.

3. Click the Security tab and then click Advanced.

4. Click the Auditing tab. Click Edit and then click Add.

5. Type Authenticated Users, click Check Names, and then click OK.

6. In the Auditing Entry For VMStore dialog box, select This Folder, Subfolders And Files from the drop-down list (this is the default), select Full Control under Successful and possibly under Failed (see Figure 8-13), and click OK to close the dialog box.

   

   Figure 8-13 Auditing changes in a VM storage folder

7. Close all other dialog boxes and repeat these steps for any other folder you want to audit.

From this point on, object modifications in this folder will be tracked for all users. Audited entries will be listed in the Security Event Log and can be viewed in Server Manager under the Diagnostics node in the Tree pane.

Updating Host Servers

Host servers, like all other servers, must be updated on a regular basis. Applying updates during the installation of a server was discussed in Chapter 2 as you built your host systems. But after the server is running and hosting VMs, the process becomes slightly more complex.

As you know, many updates require a server reboot. Rebooting a host server can impact several production VMs and therefore must be done only when absolutely required. This is one reason why you should be running host servers in failover clusters. When you have highly available host servers, you use the following process to update each cluster node (see Figure 8-14):

1. Use Quick Migration to move the VMs running on one host node off to another node in the cluster (see Figure 8-15).

2. When the node is empty of VMs, apply the updates to the node.

3. Reboot the empty node if required.

4. Move the VMs back to the original node when the process is complete.

   You can repeat this process on other nodes until your entire resource pool is updated. Remember that the first version of Hyper-V only supports Quick Migration and therefore will cause a temporary stoppage of the services provided by a VM. For this reason, you should perform this operation during maintenance windows when you will not impact users by pausing the VMs they rely on.

   

   Figure 8-14 Updating clustered hosts

The operation becomes much more complex when your host servers are not clustered. If you are running standalone hosts that support upward of 10 VMs each, you must wait until the appropriate maintenance window to update the hosts because all of the VMs can be shut down during the update process. Because you also have to update the VMs, this maintenance window must be considerable in length. This is one more reason why clustered host servers are the best host servers.

Practice: Creating the Management Virtual Network

One of the most important tasks you will perform as a resource pool administrator is the configuration of security settings on your host servers. This is the subject of this practice. In this case, you will prepare a management virtual network to link the resource pool VMs to this network and therefore segregate the traffic from this utility domain from production systems. Because of its nature, this practice is very similar to that of Lesson 3 in Chapter 2. Ideally, this practice is performed using a third network adapter in each host server, but it can also be performed with only two. In production environments, make sure you set this up with a minimum of three adapters. This practice consists of three exercises. In the first exercise, you begin to prepare ServerFull01 by creating a new public virtual network connection. This connection will be linked to the management network adapter if only two adapters are present. If three adapters are present, you link it to the third adapter. In the second exercise, you perform the same activity on ServerCore01. In the third exercise, you connect the VMs belonging to the utility network to the new management virtual network adapter. This will serve to segregate all management traffic from other VM traffic.

Exercise 1 Create a Management Virtual Network Interface on a Full Installation

In this exercise you will configure an additional virtual network adapter on the full installation of Windows Server 2008. This exercise is performed on ServerFull01. Log on with domain administrator credentials.

1. This operation is performed either with Hyper-V Manager or with the Hyper-V Manager section of Server Manager. Click ServerFull01 in the Tree pane under Hyper-V Manager.

2. Click Virtual Network Manager in the Actions pane of the console. This opens the Hyper-V Virtual Network Manager dialog box. Note the existing networks.

3. Create a new virtual adapter. Click New Virtual Network in the left part of the dialog box, choose External, and then click Add.

4. Name the adapter Hyper-V Management and make sure External is selected as the connection type. Choose the appropriate physical adapter from the drop-down list. If you have only two adapters, choose the one that is not bound to the Hyper-V External virtual network adapter. If you have three, choose one of the other two that are not bound to the Hyper-V External network. Click OK. Do not apply a VLAN to the parent partition at this time. Click OK. The Apply Networking Changes warning will appear. Click Yes. This creates the new virtual adapter.

5. Move to the Network Connections window to rename the connections. Renaming the connections makes it much easier to link the network with the network type when working in the Windows interface of the parent partition. Click Start and then click Control Panel. In the Control Panel view, click Network And Internet, then click Network And Sharing Center, and then click Manage Network Connections in the Tasks section of the window. This opens the Network Connections window.

6. Rename the physical connection to which you bound the new management network. You can check each connection’s properties to make sure you are renaming the appropriate network. This physical network adapter should only be bound to the Microsoft Virtual Network Switch Protocol. Right-click it and choose Rename. Type Management NIC and press Enter.

The new management virtual network is ready on ServerFull01.

Exercise 2 Create a Management Virtual Switch on a Server Core Installation

In this exercise you will create a new virtual network switch on Server Core. Perform this operation from ServerFull01. Log on with domain administrator credentials.

1. This operation is performed either with Hyper-V Manager or with the Hyper-V Manager section of Server Manager. Click ServerCore01 in the Tree pane under Hyper-V Manager.

2. Click Virtual Network Manager in the Actions pane of the console. This opens the Hyper-V Virtual Network Manager dialog box.

3. New Virtual Network and the External network type should already be selected. Click Add.

4. Name this adapter Hyper-V Management, make sure the External connection type is selected, and make sure the appropriate adapter is selected from the drop-down list. Use the same selection process as in step 4 of the previous exercise. Do not apply a VLAN to the parent partition at this time. Click OK. The Apply Networking Changes warning will appear. Click Yes.

5. To rename the network adapter in Server Core, you need to log on to the Server Core machine and use the netsh command to rename it. Log on with domain administrator credentials.

6. List the adapters, making note of the adapter ID number and then rename the appropriate adapter. Use the following commands. Your connection names may differ from the following example. Make sure you rename the appropriate adapter. This is why you run the show interface command first:

   netsh interface ipv4 show interface
   netsh interface set interface name="Local Area Connection 5" newname="Hyper-V
   Management"

If you run the show interface command again (hint: use the Up arrow to call the command back), you will see that the interface has been renamed. The new management virtual network is ready on this server.

Exercise 3 Assign Management VMs to the New Management Virtual Network

In this exercise you will change the properties of any VM that belongs to the utility management domain for your resource pool. Connecting these machines to this network automatically segregates management traffic from any other traffic linked to other production virtual machines. Perform this exercise on ServerFull01. Log on with domain administrator credentials. You perform this exercise with Hyper-V Manager instead of SCVMM because the SCVMM server is a VM and will be one of the VMs you modify.

1. Log on to ServerFull01. This operation is performed either with Hyper-V Manager or with the Hyper-V Manager section of Server Manager. Click ServerFull01 in the Tree pane under Hyper-V Manager.

2. Right-click SCOM01 and choose Settings; then click Network Adapter.

3. Click the drop-down list of adapters and choose Hyper-V Management. Click OK. This changes the network this VM is attached to but does not change any other parameters.

4. Repeat steps 2 and 3 for any resource pool VM that is on ServerFull01.

5. Click ServerCore01 in the Tree pane and repeat the operation for any resource pool VM that is on this host server. This includes SCVMM01 at the very least.

When the operation is complete, all of the resource pool VMs will be on a segregated network.