Toughening Up Virtual Server

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

   Previous  [1]  2  Next