Virtual Security: Combating Actual Threats
Securing your guests may be the easiest part of the process. You can use many of the same practices to secure your guests as you would a physical box. These practices include regular patching, using an antivirus, implementing host- (guest-) based firewalls and locking down unneeded services. If deploying a large number of VMs at once, consider using a common template to deploy your VMs. This standardizes your builds and makes securing and managing them easier. If you are deploying a specific application with its own set of security best practices (for example, Apache or MySQL) to a guest, follow those as well. Next, determine the criticalness and/or sensitivity of your guests, and, if necessary, place them in different security domains. It is quite possible to mix guests in different domains on a single host. It's also possible to segment your guests onto different host-specific or physical networks (more on this in the next section of this article).
In addition to any application controls, consider using some form of mandatory access control at the guest level, such as sVirt for KVM. sVirt uniquely labels guest processes running on the host to identify them to the hypervisor. This provides a framework for admins to determine which guests and/or processes are authorized to communicate with the hypervisor (see the sVirt sidebar). If you plan to provide remote access to your guests' OS, determine how your clients and/or admins will do so. Will they use SSH, VNC or remote desktop? Once you have settled on a remote access method, be sure to use a least-privilege model and follow any best practices for locking down your specific solution, such as using nonstandard ports and using certificates.
To verify that sVirt is in use, use virsh list to see the VMs that are running. Then, dump the VM's XML file using virsh dumpxml, and look for svirt in the label:
[root@systemname ~]# virsh list Id Name State ---------------------------------- 5 jbxp4 running [root@systemname ~]# virsh dumpxml jbxp4 | grep label <seclabel type='dynamic' model='selinux'> <label>system_u:system_r:svirt_t:s0:c335,c384</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c335,c384</imagelabel> </seclabel>
Once your hosts and guests are in place, regularly monitor your virtual environment. Doing so minimizes incidents of configuration errors or host/guest failures, unauthorized creation of new guests. There are many ways to monitor your virtual environment, but the best is to combine the internal OS logging on your guests with tools provided by your virtualization product (Figure 5). There is also a budding market of third-party products, such as Reflex Systems vWatch, which has extended monitoring capabilities, such as the ability to monitor for change controls and guest software/asset inventorying.
Also keep an eye on performance. Even with resource allocation in place, hosts can spike due to overpopulation or hardware failures. Most vendors' management GUIs have some form of performance monitoring. Open-source users can use virt-manager for KVM or Convirt to monitor performance on KVM and Xen systems (Figure 6). With reliable knowledge of your host utilization, you can plan future hosts better and improve your ability to consolidate, which in many cases, means improving ROI.
It always is good practice to automate your systems to alert you to failures or outages. This logic extends to virtual environments as well. Redundancy is great, but if a failure is not acted on in a timely fashion, it can cost you further time and money. Alerts also may help you with any service level agreements (SLAs) and compliance issues (such as PCI, Sarbanes-Oxley and so on). A number of management tools have alerting built into them, but it also is easy to integrate SNMP and other monitoring protocols with a solution like Zenoss to keep an eye on your virtual environment.
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!
- 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!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script