VMware Virtual Machine Security - Best Practices

We call them Virtual Machines but in practice and routine operations they are really just another host on our networks.  We should treat all hosts equally in this matter.  Security Best Practices apply to all devices on a network. In this article we talk about some sound advice for your Virtual Machine.

Before you jump into these steps it is HIGHLY recommended to download and install Nessus by Tenable.  Scan your system to get detailed information about your exposures.  Nessus has a cool feature where you can run a scan against popular "audit files" like those provided by DISA for example.  See step 4 below.  There are many levels of scanning you can do depending on how far you want to lock down your VM.

1. Install Antivirus software.  There are open source solutions like ClamAV for Unix.  There are commercial off the shelf (COTS) solutions too, like Symantec Endpoint Protection for example.
2. How cool would it be to copy from one system and paste the selection to a remote console?  Not so fast hot shot!  That's the reason we have separation between systems.  The problem is with the information while it exists in the Clipboard. If you MUST have this feature enable it, use it, clear the clipboard and disable the feature. In other words use it on demand - don't leave it enabled!  Set the configuration parameter "isolation.tools.copy.disable" and "isolation.tools.paste.disable" to "false."
3. Remove all unnecessary hardware (and turn off use of the USB ports!).  All devices are virtualized these days.  If they are not used - remove them.  Turn them off in BIOS, in the OS and in vSphere. These portable I/O devices can be shared via the vCenter Server if needed. 
4. Of course lock down your VM - harden its configuration to restrict or eliminate exposure.  Many of the items can be rolled into this one.  A thorough system lock down should include all of the steps I've mentioned.  DISA, NIST, NSA, CIS - all have free documents available online for you to follow.  It's a tedious task.  That's why I've automated it for many flavors of Linux, Oracle, Windows, etc. Reference OOMBA Security for more information.
5. Enable a host-based firewall.  All modern operating systems have them.  Sure some are better than others but the idea is to support defense in depth.  
6. If your Antivirus tool doesn't also have Malware protection then you need to install and configure Malware protection software today.  Especially if you have users that occasionally surf the web. 
7. Configure system updates to check DAILY for new patches.  Again, many modern operating systems have this feature built in.  Configure it to check daily and install automatically.  Good organizations have a server that performs this and then pushes out updates to all hosts as needed.  If you don't automate patching then you'll be doing it manually - just like we did in the 1990s!
8. In a VM you want to prevent a user or process from disconnecting devices and causing a Denial of Service (DOS) attack.  Edit the VM's .vmx file and add this line:  device_name.allowGuestConnectionControl = "false"  Ethernet 0 (eth0) is set to disallow disconnecting by default.
9. Limit guest memory writes to host. By default this is set to 1MB.  Vmtools is software installed on every guest.  It collects configuration information then sends it to the Host in the form of name-value pairs.  That is ipaddress=10.10.17.24 for example.  Rarely would you need to change the default value of 1MB to a larger value for this communication between the guest and the host. 
10. Enable logging on the VM.  Splunk, LogRythm and others are a goldmine of information for your organization. They will be that central logging server that collects massive amounts of logging information from ALL devices on your network if you configure it properly.  Set your guest VM to collect a suitable amount of logging information and forward a copy to your central Log Host.  The other half of this assigment is to set up Splunk or LogRythm to dig through all that data and alert on events. That's a full time job!
11. Look out for data in clear text!  When you enable two VMs with Fault Tolerance (FT) then you unintentionally open the door to clear text communications between the primary and secondary VM.  Including data!  The relationship between the primary and secondary VM is very close in order to ensure seamless fail over when the time comes. They share a lot of information. I wish VMware would encrypt that traffic flow by default.  But they don't so you need to make sure the network between the two VMs is private (RFC 1918 set aside private IP space for this).

In vSphere ESXi 5.0 the Service Console (aka Console OS) is GONE.  I think that was a good move on VMware's behalf.  It removes a layer of potential risk, maintenance, code, etc. It's been replaced with vCLI, esxcli, PowerCLI and the ESXi Shell.  vCLI and PowerCLI are used remotely while esxcli and ESXi Shell provide local access to host configurations.

Oh, by the way at the time of this writing vSphere 5.0 update 2 (v5.0.0.2) is the very latest.  A flaw in the way a library file is loaded can lead to privileged escalation was found in VMware vSphere Management Assistant (vMA pronounced vema)  v 5.0 update 1.  vMA is a management tool to assist admins and developers to run scripts and agents for hosts and vCenter systems. See http://www.vmware.com/security/advisories/ for more detail on that.

In summary, the best practice is a good defense!  Walk tall and carry a big STIG!