There are three common problems that lead to insecure virtual environments. The first of these problems is more of a semantic issue than it is an actual problem. Specifically, the issue is the definition of what belongs in the realm of virtualisation, as well as the definition of what constitutes a hostile environment from a virtualisation perspective.
The other two problems that lead to insecure environments are common issues within virtualisation today. They cover the management of applications and operating systems (OSes) within the virtual machines (VMs), as well as the use of a virtualisation administrative network to manage the virtualisation hosts. In this tip, I'll cover these three problems in depth so you can avoid the common pitfalls that lead to insecure virtual environments.
Virtual environment semantics
Uniform definitions of the security aspects of virtualisation are of vital importance. If your definition of a secure virtual environment conflicts with that of security experts, it will lead to confusion and conflicting security recommendations. There are two major issues that need to be defined concerning virtualisation. The first being what comprises the virtual environment? The second is what is considered hostile to that environment?
The virtual environment is more than just the virtualisation host. It's everything that directly or indirectly touches the virtualisation hosts. The components of a virtual environment include, but are not limited to, management tools, backup tools, storage and both virtual and physical networking. This is how I define the virtual environment when talking to people about virtualisation security.
From the perspective of the virtualisation host, the hostile environment includes all virtual machines. This is because the biggest risk to the virtual environment is a method to escape from the VM, thereby gaining access to the hypervisor in some manner. Thankfully, such a method has yet to be developed.
The other issue at hand is escaping the VM to reach the management appliance of the hypervisor. This could be done through the network today if the VMs could reach the network via the management appliance. Although many people confuse the two, access to the management appliance does not always grant you access to the hypervisor. VMware ESXi for example runs its management appliance within the hypervisor, while on VMware ESX the management appliance runs as a separate entity from the hypervisor.
Virtual machines, unless specifically vetted by the security organisation, should not reside on the following virtual networks connected to the VMware ESX host:
- Storage Network
- VMotion/SVMotion Network
- VCB Backup Network
- Management Network
In essence, a VM should not be able to see or reach the same resources used by the virtualisation host and vmkernel. The vmkernel resources include the storage and VMotion networks. The other resources that the host uses are for management and backup purposes. Access to these networks will allow for various attacks to the environment and there may come a time where one of them could succeed. Virtual machines are therefore hostile to the virtual environment.
With these definitions in mind, we can discuss the other two issues related to security.
Managing the Guest OS
Management of the Guest OS does not require access to the VM management tools; namely access to the remote console. It often does require access to a console, but that can be granted using tools like the remote desktop protocol (RDP), virtual network computing (VNC), or a secure socket shell (SSH). Access to the tools that manage the virtual environment like the VMware Virtual Infrastructure Client (VIC) should be limited to the virtualisation administrators.
This often causes issues as people want to install software using CDROMs. For these cases in a VM running Microsoft Windows, use a tool like VCD to mount an ISO image.
The main reason for limiting access to the virtual infrastructure client is that, currently, the roles and permission protections within the client are not granular enough to limit actions sufficiently. They also are often confusing to set up as they are the reverse of all the other types of permissions in most OSes. Just because the guest OS administrator can use it, doesn't mean they should. This also includes webAccess, access to the VMware Infrastructure software developer's kit (VI SDK) and any other monitoring tools that have access to the virtualisation host management appliance.
Securing a Virtualisation Administrative Network
Using a virtualisation administrative network is extremely tricky as access to any of the management tools could lead to deeper access whether by using the virtual infrastructure client, VI SDK, or other tools. The other part to using a virtualisation administrative network is placing the appropriate systems within this network.
Each virtualisation administrative network should contain the VMware ESX or VMware ESXi hosts service console or management appliance, the VMware Virtual Center server and the VMware Infrastructure Management Appliance, or whichever system you use, whether virtual or physical, to manage the virtual environment.
This network should be firewalled from the other networks in the environment, even though a secure socket layer (SSL) is used for all communication. The reason is that it is rather easy to implement an SSL man-in-the-middle attack even after you replaced the certificates in use. In some implementations, I have gone as far as using a virtual private network (VPN) to access the virtualisation administrative network. This network should be treated as if it was the door to the data center itself.
Not properly defining your virtual environment could lead to missing a key security issue. Not addressing the two concerns of guest OSes and your virtualisation administrative network could lead you down the path to insecurity. The security of the virtual environment starts with how you view the entire environment, not just the hypervisor or management appliance.
ABOUT THE AUTHOR: Edward L. Haletky is the author of VMware ESX Server in the Enterprise: Planning and Securing Virtualisation Servers. He recently left Hewlett-Packard Co., where he worked on the virtualisation, Linux and high-performance computing teams.