Once used mostly for testing and research, virtual machines (VMs) are rapidly becoming a critical part of the infrastructure at many organizations. Now that VMware provides its Virtual Server product for free, moving to virtualization is a possibility for even the smallest organizations. However, along with the capabilities VM technology brings to your infrastructure, comes the responsibility to take extra steps to ensure that your virtual environment is secure. Here are 15 tips for securing VMware’s Virtual Server. Although these tips are specific to the VMware product, you could easily adapt these concepts to any virtualization product.
Virtualization Security Issues
VMware Server allows multiple users to remotely access VMs (i.e., the guest OSs) running on a single physical machine (i.e., the host machine).
Although securing a guest OS in a VM is essentially the same as securing a physical machine, there are some important additional considerations to keep in mind. Because guest VMs exist as files on a host system, an unauthorized person could copy them, which is equivalent to stealing physical machines. Even worse, this theft, unlike theft of a physical machine, could go completely undetected.
To secure your VMs, it’s necessary to first secure the physical host machine they run on. It has long been known in the security industry that while you can do a lot to secure an OS, much of that security fails if someone gains physical access to the box the OS runs on. With physical access, an intruder can bypass the OS security controls by booting to an alternative OS or simply by mounting the VM’s hard drives and mapping them to a drive letter on the host machine.
In addition to severely limiting access to the host machine, you need to take a few extra security measures in the guest OS, and limit interaction between the host and the guest. The following tips will get you started with taking these security measures.
Tip 1: Isolate the Host Network
The first and most important step in securing VMware Server is to isolate the host machine’s network so that only trusted users can access the system. The best way to do this is to have the host machine's network adapter connected to an isolated and dedicated management network. However, if this 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 the users who can connect to the host machine over the network.
Any network adapter connected to public networks should either be configured to use an IP address blocked at your firewall or should simply not have an IP address at all. The host machine’s network adapter doesn’t need an IP address for the guest machines to access the network.
Because the VMs and the host machine can share the same physical network adapters, it’s important to prevent attackers from gaining access to the network traffic of other VMs on the same host. Techniques used by intruders such as MAC spoofing and promiscuous sniffing expose network traffic, but you can limit the VMs' exposure to these techniques by changing their configuration settings.
To do so, locate the .vmx file in the folder for the VM you want to configure, and right-click it to open it in any text editor, such as Notepad. Each network adapter in the physical system has settings that begin with ethernet0, ethernet1, and so on. To prevent MAC spoofing and sniffing, add the following lines for each adapter.
ethernet0.downWhenAddrMismatch = TRUE
ethernet0.noForgedSrcAddr = TRUE
ethernet0.noPromisc = TRUE
Tip 2: Use the Host Machine Only for Your Virtual Infrastructure
It’s critical that you secure the VMware Server host machine to prevent any possible break-ins that might allow access to VM files. The best way to do this is to not use the host machine for any server applications other than those you need to manage the VMs. For example, the host machine should not host Web sites other than the VMware Management Interface—if you even use that.
There is one non-management application that’s an exception to this tip: A VMware Server host machine is a good location for an intrusion detection system (IDS). Since all guest network traffic goes through the host machine’s network adapters, an IDS sensor on the host can monitor all the guest OSs. Furthermore, if you configure the host network adapter without an IP address, the IDS sensor can operate completely undetected.
Tip 3: Secure Remote Access Consoles
By default, VMware Server uses SSL for remote console connections to the server. However, it uses a self-signed certificate. Although a self-signed certificate supports traffic encryption, it doesn't provide any protection from man-in-the-middle attacks. (These attacks are perpetrated by unauthorized users who obtain access to files without the knowledge of authorized users on the host or guest machines.) To block these and other attacks, you should obtain a certificate signed by a Certificate Authority (CA).
If you have your own CA, you should create a certificate for the remote console. Otherwise, you might want to look at getting a free third-party certificate from CAcert (www.cacert.org). The VMware Server Help files provide instructions on how to manually install your own certificates.
Tip 4: Limit Local Logons on Host
Restricting access to the VMware Server host machine is a key strategy for protecting the guest VMs. If you create user accounts to allow remote access to VMs, make sure that you adjust any Group Policy (GP) settings to deny local logons from these users. The easiest way to curtail access is to create a group for nonadministrator users of VMs and use GP to deny this group local logons.
Tip 5: Encrypt Virtual Drives
As I’ve stressed before, the greatest risk posed by the guest OS on a VM is that any user with access to the physical host machine can mount the virtual hard drives and bypass the guest OS security mechanisms. One way to mitigate this risk is to implement disk encryption on the guest OS.
Microsoft’s Encrypting File System (EFS) is a good solution for protecting data, but it won’t protect the OS itself. Full-disk encryption technologies, such as Microsoft’s BitLocker Drive Encryption in Windows Vista or PGP Whole Disk Encryption, will protect the entire guest OS. By encrypting the entire virtual drive, you eliminate potential threats from others having access to the host machine. See the Learning Path for more information about encryption solutions.
Tip 6: Encrypt VM Backups
Because VM files are equivalent to physical machine files, it’s important that you encrypt any backups you make of these files. Furthermore, you must be very careful when granting backup privileges because any user with these privileges can take control of any VMs on a system.
Tip 7: Set a User Context
By default, a VM will either start up under the account of the user who starts the machine, or, if you have the VM configured to start automatically, under the local system account.
The user context determines which local and network resources the VM can access. It’s generally a good idea to isolate a VM by having it run under a dedicated user account. You could, for example, create a user account for each VM or group of machines. This allows you to carefully restrict file access and protect against any future vulnerabilities that might expose the file system.
To set a user account for the VM, open the VM with the VMware console, select Settings from the VM menu, and navigate to the Options tab. Select Startup/Shutdown and click the This user option as shown in Figure 1.
Tip 8: Use Hardened Guest OS Templates
One nice characteristic of VMs is that the environment is always fixed—the virtualized hardware is always the same. For example, no matter where you run a VMware VM, the guest OS will always use the same VMware video driver. This means that you can easily clone systems without having to worry about hardware differences. It also means that you can easily build preconfigured and prehardened OS templates for various roles.
Hardening a system by removing nonessential programs, reformatting the hard drive, installing only the basics needed for the computer to function, and so on is time-consuming, and therefore it’s an often neglected task. By using prehardened OS templates, you can ensure that every new VM meets a predetermined baseline.
Another benefit of having a fixed virtual hardware environment is that you don’t need all the extra hardware support that comes with the Windows OS. You can remove hundreds of drivers and other files from the Windows OS installed on a VMware guest because the VM will never use them. You definitely need to do some testing to make sure everything works right, but programs such as the freeware nLite (http://www nliteos.com) can help you trim a Windows installation.
Tip 9: Turn off Host and Guest Interaction
It’s important to isolate the host and guest from each other by preventing any interaction between the two. While we know that access to a host system can easily lead to access to any guest VMs, going the other way is much more difficult, but it can be done.
Because VMware allows you to map folders between the guest and host OSs, someone could potentially bypass security or network controls you might have in place. VMware lets you share a folder on the host machine that a guest OS can directly access without being subject to the controls the OS would encounter if trying to access the same folder over the network. The same potential for misuse exists when settings permit copy and paste and drag and drop between host and guest.
To disable these features on all VMs and the host, you can edit the global config.ini file on each VM and on the host. In Windows Server 2003 and Windows XP, this file is located in C:\Documents and Settings\All Users\Application Data\VMware\VMware Server. In Vista, you can find it in C:\ProgramData\VMware\VMware Server.
Open config.ini in any text editor and add the following lines:
isolation.tools.hgfs.disable = "true" isolation.tools.dnd.disable = "true" isolation.tools.copy.enable = "false" isolation.tools.paste.enabled = "false"
Save the file, and the settings will take effect the next time you restart VMware.
Tip 10: Take Sensitive VMs Offline
One benefit of VMs is the ability to easily take a system offline. You might have a VM that’s so sensitive that you want to bring it online only for certain tasks. For example, you might have a root certificate server for your organization. To protect a sensitive machine like this, run it from a removable hard disk. When you’re finished with the machine, take the disk offline and physically lock it up.
Just be sure to bring the machine online once a month to get the latest patches.
Tip 11: Use Startup Passwords
If possible, use startup passwords to prevent unauthorized users from accessing sensitive VMs. VMware allows you to set a BIOS password that must be entered at boot time. To set a BIOS password, press F2 on your keyboard as the VM starts up. Once in the BIOS setup utility, use the arrow keys to navigate to the Security menu, then to the Set User Password option. Set a new password, then scroll down to the Password on boot option and set it to Enabled. Press F10 to save your changes and exit.
Another way to prevent an unauthorized user from booting a Windows VM is to password-protect the system key on the guest OS. To do this, select Run from the Start menu and type syskey.exe. In the Securing the Windows Account dialog box, click the Update button to open the dialog box shown in Figure 2. Select the Password Startup option, and enter a password.
Tip 12: Disable Scripting in the Guest OSs
VMware has the ability to run scripts in the guest OS when you start and stop a machine. Although scripts are sometimes necessary (e.g., for startup and shutdown), you should always disable scripting if you aren’t specifically using it.
To completely disable scripting for a VM, open the .vmx file for the VM in a text editor and add the following lines:
toolScripts.afterPowerOn = "false"
toolScripts.afterResume = "false"
toolScripts.beforePowerOff = "false"
toolScripts.beforeSuspend = "false"
Save the file and scripts will no longer run.
If you do use startup and shutdown scripts, be sure to set strict permissions on each of the files so that no one else can modify them. When these scripts run, they run in the context of the local system account.
Another dangerous aspect of scripting is that VMware provides an API to automate tasks on VMs. The API allows any script on the host machine to run commands on a guest machine by using the credentials of the user currently logged on at the console. To turn off this feature, you can edit a VM’s .vmx file in a text editor, adding the following statement (all on one line):
guest.commands.anonGuestCommands RunAsConsoleUser="FALSE"
Tip 13: Remove or Disconnect Devices
VMware Server lets the host machine attach to multiple physical devices. You can easily connect or disconnect many of these devices while VMs are running. Because it’s so convenient to connect and disconnect devices, you can take the simple security measure of keeping most devices disconnected until you need them.
Consider disconnecting devices such as CD-ROM drives that you have mapped to the host machine, because guest VMs also have access to any CDs inserted in the drives. To disconnect a device, select the Settings option from the VM menu. Select the device you want to disconnect, and clear the Connected and Connect on power on check boxes as shown in Figure 3.
You might also want to keep VMs disconnected from sensitive networks and just reconnect them on the occasions when they need access. Simply connect the network adapter for access, and disconnect it when you’re finished.
Tip 14: Always Log Off a VM Session
The standard security practice of logging off after a session should be followed on VMs, just as it is on physical consoles. A VM is equivalent to a physical console, except for the added danger of unauthorized access because you can remotely access a virtual console. Because of this, best practices such as maintaining password-protected screen savers and logging off after each session are even more important.
Tip 15: Update Written Security Polices to Include VMs
Finally, as you determine which of these security tips for VMs work best for your organization, be sure to update your written security policies to include them. Very few policies or standards written for physical machines account for the unique risks of VMs; you must revise your standards and policies to bring them up to date for your virtual environment.
Follow Through on VM Planning
VMs provide a number of security benefits, but they also introduce unique security risks. Although the dangers are there, you can do a lot to make VMs just as secure as physical machines. All it takes is a little forethought and follow-through to get it right. For more information about virtualization and VMware, see the Learning Path.
