Virtual Security: Combating Actual Threats
Always make sure you take regular backups of your host systems. Although technology such as vMotion can make host backups seem trivial, backups still are vital to your disaster recovery options. Backing up a host typically entails running an operation from a command-line interface. In VMware, this is done from the virtual Command-Line Interface (vCLI) using the vicfg-cfgbackup.pl command. In XenServer, the command is xe host-backup. Because KVM runs on the Linux kernel, you simply can back up the kernel using normal methods.
Several options are available for backing up guests. At the data level, guests are made up of one or more files that contain a guest's configuration and virtual disks, so it is quite viable simply to back up those files on the host or wherever they might be stored. The downside to backing up guests this way is that the guest has to be powered down. You can avoid this problem with a variety of dedicated backup solutions that use snapshot technology to back up running guests. There are impressive offerings from Symantec (Backup Exec) and Veeam for VMware deployments. For XenServer environments, there is Alike by Quorum Systems (Figure 2). If you have a mixed environment with multiple hypervisor types, consider Arkeia's Network Backup, which can back up all of the major vendors' systems with the exception of Linux KVM. Linux KVM users have limited options, but one popular technique for backing up running guests involves taking a snapshot of a guest volume using LVM and then syncing the resulting snapshot file to another disk on a remote server. If you are unable to back up the guest's virtual data/disk files or take a snapshot, you always can use traditional backup methods to back up the guest OS.
Next up is the hypervisor. The hypervisor is the virtualization software (or layer) that controls communication between, and access to, the hardware and the guests. It usually is composed of a streamlined distribution of an operating system run from either internal or external storage and typically is segmented into its own special partition. With the exception of Microsoft's Hyper-V, hypervisors usually are a flavor of Linux. In the case of Linux KVM, it is actually a Linux kernel module, but I treat it as a hypervisor.
As much as the hypervisor is the heart of the virtualization, it also is a big juicy target. This was a major concern with virtualization early on, and it continues to be so. If you can exploit and control the hypervisor on a host, you can control every guest it controls. The primary factors in determining the hypervisor's security are its size and complexity. Fortunately, the current trend sees vendors reducing their hypervisor's footprint to an operationally minimal size, which reduces the threat surface. Regardless of size, the hypervisor still is software, and just like any critical piece of software, it is imperative that you patch it regularly.
In addition to patching, make sure to allocate your hardware resources appropriately on the host. This means setting limits/ceilings on your guest's hardware utilization. As a best practice, set limits on memory and processor utilization, or if you want to go further, set limits on network traffic. This ensures performance baselines are met across your guests and reduces the threat of DOS attacks or unintended hardware spikes bringing down the host or other guests. You can set these limits through most of the available management GUIs (Figure 3), or in the case of KVM, you can use cgroups.
When using any management GUIs that access your hosts, make sure to evaluate and develop a policy regarding access to them before providing access to users. Follow a least-privilege model for permissions, and when possible, use an external authentication source. Also consider using role-based access controls (RBACs) if they are available for your solution (Figure 4). RBACs provide granular control over operation-specific permissions, such as the ability to create new guests or move guests between hosts.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Doing Astronomy with Python
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Three More Lessons
- Build a “Virtual SuperComputer” with Process Virtualization
- Non-Linux FOSS: Flaky Connection? Mosh it!