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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space