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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
3 hours 36 min ago
- Please correct the URL for Salt Stack's web site
6 hours 48 min ago
- Android is Linux -- why no better inter-operation
9 hours 3 min ago
- Connecting Android device to desktop Linux via USB
9 hours 32 min ago
- Find new cell phone and tablet pc
10 hours 30 min ago
11 hours 59 min ago
- Automatically updating Guest Additions
13 hours 7 min ago
- I like your topic on android
13 hours 54 min ago
- This is the easiest tutorial
20 hours 29 min ago
- Ahh, the Koolaid.
1 day 2 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?