The availability of EMC's VMware Workstation and Server evaluation software has ignited a firestorm of creative and sometimes unusual solutions to daily tasks and common problems. Some inspired applications target virtual sandbox environments, seeking to reduce or eliminate the potential for damage by unchecked wild malware or to examine malware under tightly controlled and well-monitored conditions. Other applications help IT professionals make their cases for migration. Still others let IT pros evaluate unverified or untested applications without permanently installing them and risking damage to the host operating system. What is yet widely unaddressed, however, is how to define security a virtualized environment, what security means in the context of a virtualized environment, and where and how best to implement it.
One common misconception is that virtualized server environments somehow obviate, or make unnecessary, any need for security control mechanisms and policies within a host domain. This is not the case, as evidenced by the multi-layer security features built into the VMware ESX Server architecture. At the same time, ensuring a relatively secure and proper virtualization environment is uncomplicated and mimics most existing security best practices.
Bear in mind here that security is a layered methodology, best understood as a process, which must be consistent and thorough and must account for all elements. This has many implications, one being
- install anti-virus, spyware, and other malware defense mechanisms in virtualized environments that may be exposed to such risks;
- maintain coherent logging features from the VM through the host and out to a central logging repository;
- and utilize encryption tunnels or network protocols to satisfy confidentiality requirements for particularly sensitive data transiting between VMs and host machines.
Access controls effective at the VirtualCenter (VC) console should be consistent with in-house policies regarding user and group privileges on the VMware ESX Server machine. The ESX Server is responsible for creating virtualized environments and serves as their container. The VM Kernel resides at the heart of an ESX Server, and controls hardware, schedules resources for VM workspaces, and has the added advantage of completely isolating resources and hardware from each active VM session. Only that which is made visible to a VM environment is accessible at run-time; the VM Kernel exports no public interfaces and is designed to resist arbitrary process execution. Still, authorized users should be granted only enough access rights to achieve their objectives and nothing more.
VMware's own Service Console (SC) is a tie-in for management functionality, administrative interfaces. It is also a framework that supports authentication and information exchange. The SC is a modified Red Hat distribution that bootstraps the ESX Server, initializes the virtualization layer and resource manager, and exposes a variety of functionality for harvesting system-wide information collected. Its capabilities include a limited-functionality Apache HTTP server and public SNMP interfaces. Both are made visible to the SC as a file system through the
/proc/vmware namespace but are otherwise accessible through their respective default port numbers. By default, any HTTP traffic is transmitted in clear text. Since ESX Server only supports SNMPv1, no confidentiality may be guaranteed against a well-placed protocol sniffer. Services considered unnecessary are disabled, and those known to conflict with security best practices are disabled entirely. Set-user and set-group identity capability is available only in limited form, and default permissions are configured to prohibit general access and manipulation.
Network-accessible ESX Server administrators should consider the following best practices in multi-user domains:
- Keep SC security settings locked in on 'High', which limits port availability to SSH/22, HTTP/80, HTTPS/443, and VMware's remote management ports 902 and 905, forcing secure access to both interactive shell logins and Web browser connections
- Use a dedicated network interface for SC server management or use VLANs or an isolated network from the VMs
- Restrict cleartext protocols and ports, providing suitable verifiable cryptographic replacements when possible
- Use registered server certificates to minimize the potential for man-in-the-middle attacks, which would especially target authentication schemes and processes to gain user credentials.
In summary, the security paradigm for a well-laid virtualized environment differs little from any real-world multi-user domain. Security must be exercised from the ground up, cable to console, and must take into consideration the many factors that can pose threats in any hostile environment. While virtualization does provide some interesting applications in the field of security research, it also requires security researchers to understand both the underlying security problems and potential threats, vulnerabilities and exposures and best practices routinely used to mitigate, remedy or work around them.
Ed Tittel is a full-time freelance writer and trainer based in Austin, Tex., who specializes in markup languages, information security and IT certifications. Justin Korelc is a long-time Linux hacker who works with Ed and concentrates on hardware and software security topics. Both contributed to a recent book on Home Theater PCs; right now, both are busy at work on a book about the Linux-based MythTV environment.
This was first published in April 2006