Virtualization software is the rage of the tech market. Vendors such as Microsoft and VMware offer both server and workstation virtualization products, and hardware support for virtualization is appearing in AMD and Intel processors. By taking advantage of virtualization technologies, you can finally get the most out of the overabundance of computing power that today's multiprocessor and multicore servers boast: On one hardware server, you can run multiple instances of OSs, each of which appears to network users as a real, dedicated server.

If you decide to use virtualization in your environment, you need to be aware of some concerns about the technology. In particular, virtualization comes with some real security concerns. Before taking the plunge, you need an overview of Virtual Server and its common security pitfalls, and you also need practical solutions that are applicable to just about any enterprise. Let's get started.

Careful Host Preparation
Virtual Server is incredibly easy to install, but there are some preparatory steps that you should take to ensure security. The host OS is the weakest link in Virtual Server: If the host OS is compromised, potentially every virtual machine (VM) that runs on it can be compromised. Therefore, you must house the physical server in a secure location.

When Virtual Server runs, it allocates physical memory from the host OS to each guest OS. The virtual disks that the VMs use are typically stored on DAS or Fibre Channel storage. If a malicious user has physical access to a machine, he or she can attach a physical debugger or run a software debugger and monitor the guest OSs as they run, capturing secrets such as passwords. The malicious user might also be able to get access to the virtual disks and read them as though they were raw files, potentially gleaning sensitive information by using freely available forensics tools or even a simple hex editor.

You must secure the host OS as carefully as possible. First, take the standard precautions: Remove unnecessary local accounts, and ensure that remaining accounts have strong passwords. Next, reduce the attack surface by removing any extraneous services and applications. Don't co-locate Virtual Server with other server products, such as Microsoft Exchange Server or SQL Server. Although you need to run Microsoft IIS on the host OS to administer Virtual Server, you shouldn't host additional Web sites. If a malicious user succeeds in remotely exploiting a vulnerability, he or she will be able to control the entire host OS and gain access to your VMs. Reducing the attack surface minimizes the likelihood that a hacker can find a remote vulnerability to exploit. An added advantage of reducing the attack surface is that you'll likely have fewer updates to apply over time. This benefit is important because applying updates can affect the availability of guest OSs.

If your host OS is a member server in a domain, you should ensure that users who don't have a legitimate reason are prevented from logging on to the host OS over the network—either to network shares or through Terminal Services. The implication is that the host OS isn't used for general file and printer sharing. You can use the Microsoft Management Console (MMC) Local Security Policy snap-in or a Group Policy Object (GPO) to configure the host OS's security policy. Launch the snapin, expand Local Policies, and click User Rights Assignment in the left pane. In the right pane, double-click Deny access to this computer from the network and ensure that users who have no legitimate access to the host OS (or groups of which they're members) are included in the list of those denied. Repeat this procedure for Deny logon through Terminal Services. Note that denying access over the network and through Terminal Services to the host OS won't prevent users from gaining access to services offered by the VMs on the server. If you want to restrict access to those systems, you must similarly configure them. To further secure the host, consider using Windows 2003 SP1's Windows Firewall and IPsec. However, remember that merely configuring the host OS's firewall or IPsec won't necessarily prevent users from accessing services in guest OSs.

You should also review your update-management strategy for host OSs running Virtual Server. For example, you shouldn't configure your host OS to use Microsoft Update (or an internal update mechanism such as SMS or WSUS) and reboot automatically after the application of an update. If your server were to reboot in such a case, all data in your VMs would be lost unless you first took steps to gracefully shut down guest OSs or at least save their state to disk. The practical implication is that you'll need to come up with a means for updating your host OS without affecting the availability of your guest OSs.

Initial Configuration
To install Virtual Server 2005 R2 Enterprise Edition, you must first download it. (See the Learning Path on page 31 for download information; registration is required.) You should also download the accompanying documentation, which contains useful and important information. Remember to install IIS prior to installing Virtual Server.

Double-click the downloaded file (i.e., setup.exe) to launch the Virtual Server Setup Wizard, and walk through the straightforward installation process. The wizard will prompt you to select the port on which the administration Web site will listen, and to configure the Web site for Constrained Delegation. Normally, the administration Web site will run under the context of the user connecting to it. In this configuration, all resource files (e.g., configuration files, virtual disks) must be on DAS. If you plan to access the resource files over a network—for example, if they're stored on a NAS device—you must configure Constrained Delegation, and the Web site will run as LocalSystem. For security reasons, and to improve performance, I always recommend storing the resource files locally. Also, don't enable constrained delegation. Change the Web site port only if you have a reason to do so.

Now, you need to secure the installation. Launch the Virtual Server administration Web site by clicking Start, All Programs, Microsoft Virtual Server, Virtual Server Administration Website. If the system prompts you for credentials, enter those of a user who is a member of the local Administrators group on the host OS; otherwise, you'll be denied access. (To prevent the system from prompting you for credentials each time you access the administration Web site, you can add the URL to the local intranet site in Microsoft Internet Explorer—IE.)

At the bottom of the Web page, you'll notice a warning that Secure Sockets Layer (SSL) isn't enabled for the site. Your first order of business is to obtain an SSL certificate to secure traffic to and from the administration Web site. If you're running Microsoft Certificate Services, you can use that to obtain an SSL Certificate; otherwise, you can obtain one from a third-party source, such as Verisign (although that route can be expensive). Open the MMC IIS snap-in, and expand the Web Sites node under the Web server's name. You'll find a Web site named Virtual Server; this is the site for which you need to request an SSL certificate. Don't forget to select a free TCP port for the SSL connection and configure the Web site to use it. I recommend that you also configure the Virtual Server Web site to require SSL connections. After you've configured SSL, you'll need to remember to use the new URL to connect to the Web site, specifying "HTTPS" instead of "HTTP" and entering the SSL port number that the site uses. You might want to create a URL shortcut and save it to your desktop.

The next step is to configure who has access to the administration Web site. By default, any member of the local Administrators group has rights to administer Virtual Server. I recommend that you manually add users and groups of users who need administrative access, rather than simply adding them to the local Administrators group. To grant users permissions, launch the administration Web site, select Server Properties in the Web site's left pane, then click Virtual Server Security. You can use the Add entry button to add users and groups, as Figure 1 shows.

If you're adding a domain user or domain group to the list, you should specify the entry in the form DOMAINNAME\username or DOMAINNAME\groupname. Each user or group can have several permissions. The Virtual Server Administrator's Guide, which you can find in the Microsoft Virtual Server program group, details each permission. As its name implies, Full grants a user or group all permissions. In general, you should grant users only the permissions they need to perform their assigned tasks. Note that you can't remove the local Administrators group, which is always granted access even if you attempt to remove permissions. The practical implication is that any domain administrator has access to the Virtual Server administration Web site. If you don't want domain administrators to have this level of access, you'll need to remove that group from the local Administrators group on the host OS.

You should also secure the Virtual Machine Remote Control (VMRC) server. To configure the VMRC server, select Server Properties in the Web site's left pane, then click Virtual Machine Remote Control (VMRC) Server. The first option to configure is the Authentication method, as you see in Figure 2. Authentication is typically transparent to the user and is between the VMRC client and the VMRC server. Once authenticated, the user is connected to the VM's console, and isn't automatically logged on to the VM itself. The choices for authentication are Automatic, NTLM, or Kerberos. NTLM is a secure means of authenticating to a server but provides no means for you to verify whether the server is an impersonator. Use of Kerberos permits mutual authentication. You should select the Disconnect idle connections check box—this is the Virtual Server equivalent of a screen saver. It's enabled by default, and the timeout period is set to 15 minutes.

You should also enable SSL 3.0/TLS 1.0 encryption. By default, the communication between a VMRC client and a VMRC server is unencrypted; installing a certificate will secure that communication. Virtual Server can help you build a request for a certificate. Select the Request radio button, and fill out pertinent information in the form before clicking OK. When you click OK, a certificate request is generated for you, as Figure 3 shows. You can cut and paste the request and submit it to a CA. You can load the issued certificate back into the VMRC server by clicking Virtual Machine Remote Control (VMRC) Server in the administration Web site and selecting Upload. Doing so enables the Browse button, which lets you browse to the certificate file. Clicking OK again loads the certificate into the VMRC server.

Securing Resource Files
Virtual Server uses several resource files. Common files are virtual machine configuration (.vmc) files, virtual hard disk (.vhd) files, and virtual machine saved state (.vsv) files. In particular, .vhd and .vsv files contain sensitive information and require protection. An attacker who accesses these files might be able to glean documents, passwords, cryptographic keys, and other secrets. At a minimum, you should ensure that access to these files is restricted to users who have administrative rights on the virtual server—and to Virtual Server itself—by using discretionary ACLs (DACLs); when you configure who has administrative access to Virtual Server, the DACLs are set automatically, but you can change them manually. You can opt to run VMs under named user accounts by selecting the VMs from the administration Web site's Master Status page or selecting Virtual Machines, Configure in the administration Web site's left pane, selecting General Properties in the Machine Status pane, then selecting the Run virtual machine under the following user account check box and entering the username and password credentials of a valid user, as Figure 4 shows. You'll need to ensure that the named user is granted access to the resource files by editing the DACL.

Using a named user account to run a VM also lets you use Encrypting File System (EFS) to protect any .vhd files that the VM uses. Simply log on to the system with the credentials of the user account that a VM runs under, navigate to the .vhd files and use Windows Explorer or cipher.exe to encrypt each. You might need to permit the user interactive or Terminal Services access to Virtual Server to log on, but you can always deny such access after the .vhd files have been secured. (Note that you shouldn't EFS-protect .vmc or .vsv files in the parent folder. If you do, Virtual Server won't be able to start the VM.)

Virtual Server lets you map physical disks in the host OS to virtual disks in the guest OSs. I don't recommend such mapping because it can be difficult to ensure that no sensitive information is inadvertently exchanged between host and guest OSs. Corruption of files can occur easily, and it's a natural method for malware to spread from host to guest OS and vice versa.

Securing VMs
When Virtual Server runs a VM, you need to treat that system just as you would treat a physical system. You need to consider whether to configure and use Windows Firewall on each VM, independent of the host OS Windows Firewall configuration, the update strategy for each, and whether you need to use tools such as the Security Configuration Wizard (SCW) to lock down each VM. An infected or otherwise compromised VM can be as great a risk to your enterprise as an infected physical machine.

The Price Is Right
Microsoft is making virtualization even more attractive to the enterprise by restructuring its licensing terms for some of its products. Both Virtual Server and Virtual PC 2007 are now available as free downloads to qualified customers. Customers who purchase Windows 2003 Release 2 (R2) Enterprise Edition can now run as many as four virtual instances of the OS on one physical server without purchasing extra copies, and Windows 2003 Datacenter Edition users can run unlimited numbers of virtual instances.

Virtual Server is a powerful tool. However, its use comes with risks. Malicious users can potentially gather secrets in all forms from virtual hard disks, and can feasibly eavesdrop on communications between VMRC clients and the VMs themselves. This article's recommendations will help you secure your Virtual Server installations and protect the important data contained in your VMs.