As virtualization becomes more popular, so does the need to ensure that the platform is secure. Of course one of the biggest concerns is a compromise of the virtual host server. This can lead to hyper-jacking attacks when a hypervisor host is compromised. Hyper-jacking attacks attempt to take control of the hypervisor by the following methods:
• Injecting a rogue hypervisor beneath the original hypervisor
• Directly obtaining control of the original hypervisor
• Running a rogue hypervisor on top of an existing hypervisor
If multiple hosts were infected, this can lead to a guest-hopping attack in which a rogue server could bounce from virtual server host to virtual server host. It would be like chasing a ghost. A compromise of the hyper-visor host could allow a hacker to morph a virtual server running on the host into a compromised machine. Then the virtual server guest would change into a “Mr. Smith” agent, which could carry out a variety of attacks.
One of the most famous of these of attacks is the Subvirt Virtual Machine Based Root kit (VMBR). In 2006 the Subvirt VMBR was developed as a proof of concept, which caused quite a stir in the security community. Subvirt injected itself between the hardware and the original OS. Then Subvirt ran the original OS as a guest OS. Of course then Subvirt would be free to run other guest machines and other attacks potentially causing great damage. For more information on Subvirt, refer to http://www.eecs.umich.edu/virtual/papers/king06.pdf. At the time, it was argued that a VMBR would be very difficult, if not impossible to detect. However there are some significant differences between physical and virtual hardware and you have to know what to look for. Check out http://www.cs.cmu.edu/~jfrankli/hotos07/vmm_detection_hotos07.pdf for more information.
To my knowledge, no one has released a VMBR - yet. Even Subvirt requires administrator rights on the machine to run. But that doesn’t necessarily mean you should take virtual server security lightly. It’s probably just a matter of time, before someone does develop a VMBR or virtual server host attack. So what can you do to secure your virtual servers right now? Here's a list of items you can do today to increase the security of your virtual server environment.
• Reduce your virtualization host’s footprint. ESX installs only the necessary items to create the virtualization environment. The embedded version of ESX is arguably more secure than the non-embedded version of ESX because it does not include the built-in Web server. This reduces the attack footprint of ESX. Microsoft’s Hyper-V can be installed with Server Core or with the full version of Windows Server 2008. To keep the footprint as small as possible, install Hyper-V only on the server core and not on the full version of Server 2008. A properly installed hypervisor has a significantly smaller footprint.
• Host firewalls. Enable the firewall on virtual server hosts. Verify restricted access from specific management machines and block remote access from all other computers. Open only the necessary ports for remote management on the virtual server host firewall.
• Use a dedicated NIC for management of virtual server hosts. Consider installing an additional NIC that is dedicated to management. Make sure this network is physically separated from any networks that the virtual server guests are using. For the best security, don't use a VLAN, but use a physically separate switch for management access. VLANs can be compromised by flooding a switch with network traffic, essentially turning the switch into a hub. Of course restrict access to this management network to selected machines. If you’re using Virtual Center for VMware Server to manage a VMware Cluster or ESX servers, make sure that access to this management server is restricted.
• Remote access to hosts. Do not allow any remote access to virtual server hosts without a VPN tunnel. This is obvious, but I'm still amazed at the number of companies that allow remote access without a VPN. Verify that the endpoints that will access the virtual server hosts are well protected. A common tactic that hackers use is to compromise poorly protected endpoints to gain access to corporate resources.
• Server base images or templates. Often base images or virtual guest templates are used as a starting point to create new virtual server guests. These templates should be stored offline and used only when creating new servers. If a hacker manages to obtain access to a virtual server host they could compromise a virtual server image or template. Any new servers built from a compromised base image will have the same compromise.
• Programs on the host server. The programs running on a virtual server host should be kept to minimum. A backup agent, and possibly an antivirus program should run on the host. All other applications should run on virtual server guests.
• Virtualization segmentation. If you have servers that have particularly sensitive data, consider running them on a separate virtualization host, in a separate cluster or keep them on dedicated hardware.
• Patch management. Just like physical servers, it’s important to keep up with the latest patches for your virtual server hosts.
• Virtual server guest resource allocation. To protect against a Denial of Service (DOS) attack, configure virtual server guests so they cannot consume 100 percent of a virtual server host’s resources.
• Image backups of virtual server guests. Perform regular image backups of virtual server guests running on a host. Both ESX and Hyper-V allow you to back up the virtual server guest disk files, without shutting down the guest server. In the event that a virtual server host is compromised, you can quickly recover the virtual server guests as long as you have the image files backed up. Control physical access to virtual server hosts. USB keys are now large enough to contain one or more virtual machines (VMs). If someone has physical access to the host, they could copy the virtual server image from a USB key and run it on the host. If you’re running Server 2008 and your server has a Trusted Platform Module (TPM) chip, consider enabling BitLocker Drive Encryption to prevent a rogue OS from booting on the server.
Virtualization security products are just beginning to emerge. Announced earlier this year, VMware is working on a security Application Programming Interface (API), called VMsafe that will give security vendors access to the ESX virtualization environment. Expect to see a significant number of ESX-specific security products enter the market later this year. A compromise of a virtual server host could be extremely devastating to any virtualization environment. Protect them carefully!
