Isolating the Host from Its GuestsWhen building a virtual server, you should carefully configure the network components. The virtual server should have enough network adapters to properly segment the networks of VMs, but you shouldn’t place machines from multiple network security zones on the same host. The best solution is to place virtual guests with similar roles and similar security requirements on the same host.
You should isolate the host machine’s network from its guests so that only authorized users can access the host via a trusted network. The best way to do so is to have a network adapter connected to an isolated and dedicated management network. However, if that isn’t possible, you should make use of technologies such as Virtual LANs (VLANs), IPsec, VPNs, Secure Sockets Layer (SSL) tunnels, and packet filtering to limit who can connect to the host machine over the network.
When it comes to hardening the virtual guest OSs, you can usually follow the same methods you use to harden physical machines. One advantage of VMs is that because they’re a fixed hardware environment—the virtualized hardware drivers are always the same—you can easily build hardened baseline templates for the various server roles you use. Keep in mind, however, that you should carefully protect these templates so that they aren’t compromised and use tools such as the Offline Virtual Machine Servicing Tool to keep them up-to-date with current patches. System hardening is a time-consuming, and therefore often neglected, task. By using pre-hardened OS templates, you can ensure that every new VM meets a pre-determined baseline.
As I mentioned earlier, the greatest risk associated with VMs is that any user with access to virtual hard disk drives can mount them and bypass the guest OS security mechanisms. One way to combat this risk is to implement disk encryption on the guest OS, at least for sensitive data. Microsoft’s Encrypting File System (EFS) is a good solution for protecting data. In cases in which the data on the virtual guest is highly sensitive, full-disk encryption technologies, such as Windows Bitlocker Drive Encryption in Windows Vista or PGP Whole Disk Encryption, might be necessary.
With VMs, you can easily add or remove hardware devices. Therefore, it’s a good idea to attach devices only when needed, and remove them for production use. This practice is particularly important for devices such as CD-ROM drives that you have mapped to the host machine because guest VMs will also have access to CDs inserted in the host machine’s CD drive.
When you configure the VM’s hardware, you should also limit the processor usage. By default, a VM can use 100 percent of the physical machine’s processor, meaning that someone could perform a denial of service (DoS) attack on one VM that would have an effect on all the other virtual guests on the system. Limiting CPU usage ensures there are enough CPU cycles left in reserve for the host and other VMs to still operate. Finally, because accessing a VM in the Hyper-V Management Console is equivalent to physically being at the guest OS’s console, it’s necessary to strictly follow all security best practices, such as setting up password-protected screen savers and logging out of a machine when it won’t be used.
Protecting Sensitive MachinesThere might be times when you have a VM that’s particularly sensitive and needs a higher level of security. One benefit of VMs is the ability to easily take a system offline and quickly bring it back online using Hyper-V’s suspend feature. A root certificate server, for example, is so sensitive that you want to bring it online only for certain tasks.
To protect these sensitive machines, you can run them from a removable hard disk. When you’re finished with the machine, take the disk offline and physically lock it up. If you have a system that mostly stays offline, be sure to bring the machine online once a month to get the latest patches.
You can use startup passwords when appropriate to prevent unauthorized users from accessing sensitive VMs, although I don’t recommend using them for all systems. One way to prevent someone from booting a Windows VM is by setting a syskey password on the OS. You can do so by going to the Start menu, typing
syskey in the search box, and pressing Enter. Doing so will open the Startup Key dialog box, which is shown in Figure 3.
Click Update, select the Password Startup option, set a password, and then click OK. You don’t want to set a syskey password on all your servers because it requires someone to be there for the system to restart. A crash or unattended reboot would result in the system being stuck waiting for a password.
As you determine which of these security tips work best for your organization, be sure to update your written security policies to include them. Very few policies or standards account for the unique risks associated with VMs. Also, administrators and users need to be trained on how to treat a VM differently than a physical machine. There’s much you can do to make VMs nearly as secure as physical machines. All it takes is a little planning to get it right.
Register
