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.
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.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- LiveCode Ltd.'s LiveCode
- Parsing an RSS News Feed with a Bash Script