When it comes to securing virtual environments, you have to take different measures from those for traditional physical security.
With virtual security, new attack vectors
In this tip, we cover the kinds of attacks you should be concerned about as you develop a virtualization security strategy as well as considerations and best practices for the various components of your infrastructure.
There are many physical attack vectors, from physical consoles to a guest OS to the applications that run on an OS. To secure a physical system, you must have a locked data center that restricts access to the console. Next, you secure the operating system and applications, and finally, you implement security controls -- such as a firewall -- at the network layer. With virtual security, these breaches still apply, but there are other avenues by which an attacker can gain access to a VM.
Virtual security: protecting the management console
With virtual security, the main task is to secure the virtual host's management console. Think of a virtual host as an apartment building and the VMs as the residents, who have their own apartments with door locks for security. The management console is like a building manager: The manager has keys to every apartment and can access them if needed. But if someone has stolen the building manager's keys, for example, that person can access all the building's units. So, in virtual environments, the management console must be protected at all costs: Attackers that gain access to the console can then easily get into VMs that reside on the host. That includes any VM on the entire data store that the host has access to, even VMs running on other hosts.
For optimum virtual security, you should limit access to the host's management console. When granting access to the console, give super-user access only to those users who absolutely need it. Also assign each user only the privileges that he absolutely requires. In addition, make sure you have the network interface for the management console on an isolated VLAN. You can do so by using firewalls or by physical segregation. That way, only other hosts and administrators can access the console.
Attacks from within the VM
VMs add a whole new layer of vulnerabilities to an environment that physical security doesn't have to address. Not only is the management console an attack vector, but so is each machine on the host. And attackers can also maliciously ramp up a VM's resource usage to compromise an entire system.
When multiple VMs fall victim to these denial-of-service attacks, the host can become unusable. This attack is difficult to protect against, because it's not easy to identify malicious resource usage. Overusage can take many forms, from pegging a VM's CPU with 100% utilization, writing to all the memory assigned to a VM or causing an extremely high volume of disk reads and writes.
VM monitoring is important to virtual security, because it can alert you about malicious resource usage. Reporting systems that profile typical resource usage for VMs are particularly helpful, so you will know when abnormal behavior occurs. By using VM monitoring in conjunction with scripting, you can impose resource restrictions, isolate the offending VMs and even power them off.
Securing utilities and APIs
Other attack vectors to consider in your virtual security strategy include logging utilities and application programming interfaces (APIs).
VMs need to have a communication path from the guest OS to the hypervisor. VMware, for example, provides this path through the VMware Tools application, which installs on a guest OS. VMware Tools is a set of drivers and utilities that allow many guest/host interactions, such as time synchronization, memory management and copy/paste capabilities for remote consoles. VMware Tools also allows VMs to write to files on the host file system from within the guest OS, and it logs VM information that's useful for troubleshooting. Malicious applications can exploit these log files by writing so much data to them that the host data store becomes full -- a potential problem you wouldn't have to account for with physical security.
The hypervisor also has many APIs that allow third-party applications to interact with the hypervisor and the VMs. APIs are not easily breached, but they are a potential attack vector that could be exploited. Disabling and limiting this interaction when it's not needed helps provide better virtual security of APIs. You can put limits on log-file growth or completely disable interaction, limiting access to host operations and to VM consoles.
Securing virtual hard disk files
With physical security, you can pretty much disregard the possibility of actual theft. It's not easy to swipe a physical server or other hardware from a data center. But in the virtual security realm, the reality is that the data center itself is an attack vector.
Because VMs can be encapsulated into a single virtual hard disk file, they're easily transportable -- right in someone's pocket on a flash drive, for instance. An attacker could do this without even entering the data center, just by accessing the host data store devices. Hackers can access the host with a Secure Copy program through client management utilities, allowing them to browse data stores and download files.
Other possible avenues include access to the backup repositories or network access to VM storage devices. A hacker can simply download the entire virtual disk file from a host to any workstation, copy it to a removable USB storage device, then take it elsewhere. From any secondary location, an attacker could mount the disk or power on the VM, using the same hypervisor software, and access the VM's contents.
It's critical to protect virtual disk files as part of your virtual security strategy. Limit access to the host data stores where the VMs reside, implement logging to know when a breach occurs, and physically isolate the storage network so that only the storage devices and hosts have access.
In addition, be aware that when you delete or move a VM from a data store, the VM's data still resides on the disk. If a new VM is created on that disk, the new virtual disk may reside on the same disk blocks that the former VM's disk occupied. (This only applies to full allocated virtual disks.) Generally, the space for a new VM is allocated only once a guest OS has written to the blocks. Because they may not be cleared of previous data for a period of time, someone could access the old data that has not yet been removed. To protect this attack vector, you should either clear the disk blocks immediately when creating the new disk or use a utility within the OS to do so.
About the author
Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains vSphere-land.com, a VMware information site.
This was first published in October 2010