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.
|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|
|Trying to Tame the Tablet||May 08, 2013|
|Dart: a New Web Programming Experience||May 07, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Developer Poll
- git-annex assistant
45 min 39 sec ago
- direct cable connection
1 hour 8 min ago
- Agreed on AirDroid. With my
1 hour 18 min ago
- I just learned this
1 hour 22 min ago
1 hour 52 min ago
- not living upto the mobile revolution
4 hours 43 min ago
- Deceptive Advertising and
5 hours 19 min ago
- Let\'s declare that you have
5 hours 20 min ago
- Alterations in Contest Due
5 hours 21 min ago
- At a numbers mindset, your
5 hours 22 min ago
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.