Virtual Security: Combating Actual Threats

The barriers between physical and virtual are disappearing rapidly in the data center. With virtualization's myriad benefits and the emergence of cloud computing, many shops are virtualizing their server and desktop systems at a breakneck pace. In this great migration to the virtual, admins face new security challenges in the transition that require a much broader knowledge of the enterprise. Couple these new challenges with the ease of access users now have to build their own virtual resources, and you quickly can find your environment in a state of “virtual sprawl”. The good news is that by following a few simple guidelines and utilizing a defense-in-depth strategy, you can minimize your risk whether you're deploying a new virtual infrastructure or just trying to manage sprawl.

In the course of this article, I discuss several high-level security concerns when deploying a virtual environment. In each area of concern covered, I offer basic guidance for dealing with the issues, and when possible, I offer technical solutions to address the associated risks. In keeping with a big-picture view, I don't provide detailed instructions for the specific solutions presented. The vastness of the product space and the limited format of this article also prevent me from delving into every solution available. Although I attempt to stay vendor-neutral, not every vendor offers a product or solution to address each security concern presented here. In those instances, I briefly look at those products/solutions that are available.

To keep this discussion focused, I won't delve into any esoteric arguments about type 1 or type 2 hypervisors, nor do I discuss the merits of para-virtualization versus hardware translation/emulation. I also stick to products that use a Linux-based hypervisor (including Linux KVM). The use of the term host in this article refers to the underlying physical system with direct access to the hardware. The term guests refers to those virtual machines (VMs) that run an instance of an OS on top of the host virtualization software or hypervisor.

The first area to consider is physical security. Virtualization is all about separating the hardware from the OS, but VMs still run on a piece of iron. As such, you can use the same best practices for hardening physical hardware to secure your virtual host. Use common-sense controls like placing locks on your racks and servers and securing keyboard-video-mouse consoles. Be aware of operational factors, such as power, cooling and cabling. As virtualization consolidates systems to achieve higher hardware efficiency, your host servers become hotter and draw more power as they are utilized more. Always make sure your data center has adequate power and cooling to maintain your systems' basic operations.

If building your host servers from scratch, properly size your systems before deploying them. Several vendors provide excellent sizing guides to do just this (Figure 1). Although these baselines may not be an exact representation of your final deployment, they are a good way to approximate your hardware needs. When thinking about hardware, keep performance and redundancy at the forefront. An overtaxed system is easier to penetrate, manipulate and deny access to. As a general guideline, install surplus storage and memory, because those are the typical bottlenecks on hosts. Buy as many of the fastest high-capacity disks you can afford. More disks usually mean more IOPS. You also should have an enterprise-grade array controller running your drives. Consider using a RAID level that has both a stripe and uses parity, such as RAID 10, 5 or 50. Memory should be fast and large in quantity. With excess storage and memory, you create a cushion against undersizing.

Figure 1. HP's ESX Sizing Tool

Consider using a separate physical network from your production network for your hosts. This reduces chatter on your other segments and makes it easier to secure the segment assigned to your hosts and their guests. When using networked or shared storage to store your VM's data files and virtual disks, use another dedicated segment to separate and streamline storage-related traffic.

In terms of redundancy, try to follow the old adage of “buy two of everything”. Look for cost-effective redundant options for your host systems, such as redundant power supplies and multipathed or teamed network ports. Storage also should be highly redundant. Consider the number of disks needed for each type and how many disk failures can be tolerated when selecting your RAID level. If using network storage, look into redundant options for your NAS/SAN/shelf. This can give you the ability to hot-failover VMs during system failure using tools like VMware's vMotion and Storage vMotion.