Securing virtual environments: Three considerations

If you approach virtual environment security by viewing elements such as a hypervisor and management applications in isolation, you invite breaches and risk. This tip outlines three common risks to virtual environments and how to prevent them.

In virtual environments, there are three common problems that create security problems: (1) definitional issues concerning what compromises a virtual environment and, thus, the threats posed to that environment; (2) the management of applications and operating systems within virtual machines (VMs); and (3) the use of a virtual administrative network to manage virtual hosts. To better secure your virtual environment, this tip defines the scope of the virtual environment and discusses some of the security threats at the OS, application and network levels. The ultimate goal is for virtualization administrators to secure the entire virtual environment, not just a hypervisor or management appliance in isolation.

Virtual environment semantics
Uniform definitions of the security aspects of virtualization are of vital importance. If your definition of a secure virtual environment conflicts with prevailing standard definitions, it can create confusion and conflicting security recommendations. There are two major issues that need to be defined concerning virtualization. The first is, what comprises a virtual environment? The second is, what is considered hostile to that environment?

A virtual environment is more than just the virtualization host. It's everything that directly or indirectly touches the virtualization 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 virtualization security.

From the perspective of the virtualization 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 organization, should not reside on the following virtual networks connected to the VMware ESX host:

  • Storage network

  • VMotion/SVMotion network

  • VMware Consolidate Backup network

  • Management network

In essence, a VM should not be able to see or reach the same resources used by the virtualization 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 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 Shell (SSH). Access to the tools that manage the virtual environment like the VMware Virtual Infrastructure Client (VIC) should be limited to virtualization administrators.

This often causes issues as people want to install software using CD-ROMs. 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 VI Web Access, access to the VMware Infrastructure Software Developer's Kit (VI SDK) and any other monitoring tools that have access to the virtualization host management appliance.

Securing a Virtualization Administrative Network
Using a virtualization 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 of using a virtualization administrative network is placing the appropriate systems within this network.

Each virtualization administrative network should contain the VMware ESX or VMware ESXi hosts service console or management appliance, the VMware vCenter server and the VMware Infrastructure Management Appliance, or whichever system you use, whether virtual or physical, to manage the virtual environment.

Even though a Secure Sockets Layer (SSL) is used for all communication, this network should be firewalled from the other networks in the environment; it is 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 to access the virtualization administrative network. This network should be treated as though it is the door to the data center itself.

Not properly defining your virtual environment can lead to overlooking a key security issue. Failing to address the two concerns of guest OSes and your virtualization 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 a hypervisor or management appliance.

ABOUT THE AUTHOR: Edward L. Haletky is the author of VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers. He recently left Hewlett-Packard Co., where he worked on the virtualization, Linux and high-performance computing teams. Haletky owns AstroArch Consulting Inc. and is a champion and moderator for the VMware Communities Forums.

Dig Deeper on Server virtualization risks and monitoring