Security Tip
of the Month – September 2008
See other Security Tips of Month
- - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - -
Once you have updated the
Windows Server® 2008 operating system with the Hyper-V™ technology release bits
and enabled the Hyper-V role, you are ready to run virtual machines (VMs) on
your server, now called a virtualization server (also called a “host”).
How does this change your
security? Not much. Hyper-V is designed to be fairly transparent. You secure
your VMs the same way that you secure physical machines. For example, if you
run antivirus software on the physical machine, run it on the VM (not the
host). If you segment the physical server to a particular network, do the same
to the VM.
Securing the virtualization
server itself involves all the measures you take to safeguard any Windows
Server 2008 server role, plus a few extra to help secure the VMs, configuration
files, and data. For more information on helping to secure Windows Server 2008
workloads, see the “Windows
Server 2008 Security Guide.”
Microsoft recommends the
following best practices to improve the security of your Hyper-V virtualization
servers. Many of these practices apply to your other virtualization servers as
well.
Use a Server Core installation for the parent partition. A Server
Core installation of Windows Server 2008 presents the smallest attack surface
and reduces the number of patches, updates, and restarts required for
maintenance. For detailed information and guidance about how to install Server
Core, see the “Hyper-V
Planning and Deployment Guide,” which includes step-by-step instructions
for enabling the Hyper- V role on both Server Core and full installations of
Windows Server 2008. Note that there is no way to upgrade from a Server Core
installation to a full installation of Windows Server 2008. If you need the
Windows Server user interface or a server role that is not supported in a
Server Core installation, you will need to install a full installation of
Windows Server 2008.
You will manage Hyper-V on a
Server Core installation remotely, using the Hyper-V management tools for
Windows Server 2008 and Windows Vista® Service Pack 1 (SP1). For more information,
see article 952627 and article 950050 in the
Microsoft Knowledge Base. For more information about configuring tools for
remote management of Hyper-V see the “Hyper-V Planning and Deployment Guide.”
It is a good idea to build a
deployment image of Windows Server 2008 with Hyper-V role enabled to use as the
base operating system (OS) for your VMs. Robert Larson wrote a great step-by-step
article on how to use the Windows Automated Installation Kit (WAIK) for
Windows Server 2008 to slipstream the Hyper-V release-to-manufacturing (RTM)
update and the integration components into an image for easy deployment. Just
add Server Core to his recipe, and you are good to go.
Do not run any applications in the parent partition. Run all
applications on virtual machines, which use child partitions. For example, if
antivirus is required, be sure to run it on the VMs rather than the parent
partition. Keeping the parent partition free of applications and running on a
Windows Server 2008 core installation means fewer host updates, since nothing
needs software updates except the Windows Server 2008 core installation, the
Hyper-V service components, and the small (~600KB) hypervisor.
You can use Microsoft® System
Center Virtual Machine Manager to convert your server to a virtual machine and
run it on the virtualization server in a VM. In Virtual Machine Manager, this
process is called a physical-to-virtual (P2V) conversion. For more information
on P2V, see “Converting
Physical Computers to Virtual Machines.” If you don’t want to use the WAIK,
you can use P2V on your Server Core installation to use as the base for all
your VMs.
Use the security level of your
VM to determine the security level of your host. You should deploy VMs onto
your virtualization servers that have similar security requirements. For
example, if you classify the risk and effort to secure your servers into three
levels—secure, more secure, and most secure—you can put the highest degree of
compliance effort and control procedures into the “most secure” servers, and
lessen the amount of compliance and procedures with the servers that have a
lower security classification. This would be true whether the server is
physical or running on a virtual machine. If you deploy both “secure” and “most
secure” VMs on a host, then you should secure the host as a “most secure”
server. To make management easier, deploy VMs with similar security levels on a
virtualization server and do not mix VMs with differing security requirements
on the same host. This practice also allows you to move VMs among different
hosts with the same level of security without worry or extra effort—using, for
example, Virtual Machine Manager 2007 host groups.
Do not give virtual machine administrators permissions on the parent
partition. According to the principle of least privilege, you should give
administrators of a VM (sometimes called department administrators or delegated
administrators) the minimum permissions required. Managing the required
permissions on all the objects associated with a VM can be burdensome, and if
mishandled can lead to potential security issues. Role-based access control
(RBAC) allows you to specify access control in terms of the organizational structure
of a company. RBAC does this by creating a new object called a role. You assign
a user to a role to perform a job function. Hyper-V uses Authorization Manager
(AzMan) policies to achieve RBAC.
Ensure that virtual machines are fully updated before they are turned
on in a production environment. Because VMs are so much easier to move
around and quicker to deploy than physical machines, there is a greater risk
that a VM that is not fully updated or patched might be deployed. To manage
this risk effectively, use the same methods and procedures to update VMs as you
use to update physical servers. For example, if you allow the use of automatic
updates using Windows® Update, Microsoft System Center Configuration Manager,
or other software distribution method, ensure that VMs are updated and/or
patched before they are deployed.
You can use maintenance hosts
and quick migration in Hyper-V to accomplish this. A maintenance host is a host
that you can dedicate for patching stored resources and for staging virtual
machines before you move them into your production environment. For more
information about maintenance hosts see “Planning for
Hosts.” For information about using quick migration to move VMs to a
maintenance host see “Hyper-V
Step-by-Step Guide: Testing Hyper-V and Failover Clustering.”
To update the VMs before they
are turned on, you can use the Offline Virtual Machine Servicing Tool. For more
information on the Offline Virtual Machine Servicing Tool see “Offline Virtual
Machine Servicing Tool Executive Overview.”
Use a dedicated Network Interface Card (NIC) for management of the
virtualization server. By default, NIC0 is for the parent partition. Use
this for management of the Hyper-V server and don’t expose it to untrusted
network traffic. Don’t allow any VM to use this NIC. Use one or more different
dedicated NICs for VM networking. This allows you to apply differing levels of
networking security policy and configuration for your VMs. For example, you can
configure networking so that the VMs on the host have different networking
access than your host, including using virtual local area networks (VLANs),
Internet Protocol Security (IPsec), Network Access Protection (NAP) and
Microsoft Forefront™ Threat Management Gateway. In addition, if a VM uses too
much bandwidth, a dedicated NIC for the host allows you to access the
virtualization server and take action on the VM to correct the situation. For
more information about configuring networking, see “Configuring virtual
networks” in the Hyper-V Planning and Deployment Guide.
For more information about NAP
see http://www.microsoft.com/technet/network/nap/napoverview.mspx.
For information about Microsoft Forefront Threat Management Gateway and
Forefront Code Name “Stirling” (the next generation Integrated Security System
in the Forefront line of business security products) see http://www.microsoft.com/presspass/press/2008/apr08/04-08ForefrontBetaPR.mspx.
Use Windows BitLocker™ Drive Encryption to help protect VM resources.
BitLocker Drive Encryption works with features in server hardware and firmware
to provide secure operating system boot and disk drive encryption, even when
the server is not powered or operating. This helps protect data if a disk is
stolen and mounted on another machine for data mining. BitLocker Drive
Encryption also helps protect data if an attacker uses a different operating
system or runs a software hacking tool to access a disk.
Losing a physical disk is a
more significant risk in small- and medium-business and remote-office
scenarios, where physical security of the server may not be as rigorous as in
an enterprise data center. However, it makes sense for all hosts. You should
use BitLocker Drive Encryption on all volumes that store VM files. This
includes the VMs, virtual hard disks, configuration files, snapshots, and any
VM resource, such as ISOs and VFDs. For a higher level of security that
includes secure startup, BitLocker Drive Encryption requires Trusted Platform
Module hardware (TPM). For TPM management, see the “Windows
Trusted Platform Module Management Step-by-Step Guide.”
For more information on how to
configure BitLocker Drive Encryption to help protect your server and the VMs
running on it, see “Windows
Server 2008 Hyper-V and BitLocker Drive Encryption.”
See also “Windows
BitLocker Drive Encryption Frequently Asked Questions” and the “BitLocker
Repair Tool .“
Important: Use BitLocker Drive
Encryption in the Hyper-V parent partition only. Because BitLocker Drive
Encryption is not supported within a VM, do not run BitLocker Drive Encryption
on a virtual machine.
Additional Resources
- Virtualization Security Best Practices Podcast:
- Windows Server Virtualization and Windows
Hypervisor: