Toughening Up Virtual Server

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.

End of Article

   Previous  1  [2]  Next