Wednesday, June 5, 2013 At 12:19PM
Nessus has the ability to run compliance checking scripts for many different services and servers, and is a great resource for aligning a server with “best practice” server hardening guides, such as those released by the Center for Internet Security (CIS). Recently VMware officially released the vSphere 5.1 Hardening Guide, for which Tenable have then released Nessus compliance scripts to check for the recommended configurations. When using these scripts, there are a few forum posts (provided by Nessus and Tenable) that provide some information, and although they can collectively provide good enough instructions on how to run the scan, they omit a few details that would have been very handy to know prior to performing these compliance checks.
So, taking my own experiences with the audit scripts, and merging these with the already available resources, I’d like to provide others with some straightforward answers to the questions and issues I had when first running the VMware vSphere compliance audit scans.
How to Perform a Scan
Our goal is to create a minimal compliance scan that is based around the VMware vSphere Compliance audit, and also reduces the number of plugins required to effectively run the scan. The reason we want to segregate the Policy Compliance scan (although it is not required) is that it will help teach us how to perform the compliance scan as a standalone scan, and can also help troubleshoot issues when learning the new scan type.
Jumping right in, let’s create a new Nessus Policy and modify it to fit our needs. Within the Policy, all of the General Settings can remain the same, and we want to modify the Plugins enabled for our new Policy. Only enable the following plugins so the scan will target the VMware Policy Compliance audit.
-
General
-
Service Detection
-
VMware ESX Local Security Checks
-
VMware vCenter/vSphere Compliance Check (under “Policy Compliance”)
The idea of selecting only these Plugins is to greatly reduce the amount of time Nessus will take when all we are concerned with is performing a compliance check scan.
After configuring the Plugin information, we want to change the Preferences to match our VMware configuration. Under the “Preference Type” drop-down menu we select “VMware SOAP API Settings”.
Now we fill in the administrative VMware user name and password. If the VMware host is using a self-signed certificate, ensure the “Ignore SSL Certificate” checkbox is selected.
After configuring our credentials, the last step to creating a policy is the select the appropriate audit file. Under the “Preference Type” dropdown, select the “VMware vCenter/vSphere Compliance Checks” and then browse to the appropriate audit file. We will be using “vmware_vsphere_5.x_hardening_guide.audit”.
Now that our Policy is created, we need to start a new scan and ensure our VMware host is set as the target. Once the scan has finished, we will see a Compliance option under the Scan Results indicating the VMware Policy Compliance plugin ran properly.
Interpreting the Results
Now that we have completed a scan of our VMware host we can start to review the results. It’s recommended that a copy of the relevant VMware vSphere Hardening Guide is available so that when you’re reviewing the results the best practice guide can be referenced. When reviewing the results, under the “Reference Information” the Profile directory correlates directly to the Profile provided in the hardening guide for each compliance check.
The profiles (taken from the VMware Guide) give context as to the type of requirements for your environment, and potentially compliance rules that are unnecessary for your needs.
-
Profile 3: guidelines that should be implemented in all environments
-
Profile 2: guidelines that should be implemented for more sensitive environments, e.g. those handling more sensitive data, those subject to stricter compliance rules, etc
-
Profile 1: guidelines that only be implemented in the highest security environments, e.g. top-secret government or military, extremely sensitive data, etc
When performing a scan using an unconfigured default audit file, one of the first things noticed will be the number of failed compliance rules. Since this is what I’ve done for this example, the list will go on for at least 50 failed compliance checks!
Once we dig deeper in some of the results we realize an un-tuned audit file can provide a poor representation of how our server is hardened. Reviewing the results manually gives us the ability to interpret a few categories of “false positives” in the sense that the audit cannot be run accurately because it is not configured to the local environment. In most cases, everyone will run the default audit file at least once before realizing that they should have tuned the configuration for their environment.
No Audit File Tuning
When the audit file is not tuned for the environment, all of the variables that are supposed to be set within the configuration will be flagged as failing their compliance checks. When viewing the Description for these false positive checks, you will notice “NOTE: Update {VARIABLE} to the appropriate value for the local environment” being present.
In order to correct these results, every variable that is supposed to be customized for the local environment will have to be set. This is done by modifying the original audit file that was added to the Policy.
VMware Tools Not Installed
If VMware Tools are not installed on the Virtual Machines, there will be the occurrence of “toolsNotFound” found within the Affected Host List. This information is much easier to view if the Nessus scan results have been exported to HTML first, and I recommend exporting the results to HTML and viewing them within Nessus at the same time, especially when scanning multiple hosts.
This can be fixed in one of two ways, by either installing VMware Tools on the guest operating system (which isn’t necessarily ideal for each situation), or by editing the audit file and remove the compliance checks that require VMware Tools.
Tips & Tricks
The following are some of the “gotchas” and things I wish I had known before performing these scans in test and production environments. These tips will hopefully reduce some confusion when interpreting the results, and ensuring the scan has run properly.
-
If there are multiple audit files selected during the compliance review under the “VMware vCenter/vSphere Compliance Checks”, they will not be able to be separated under the Nessus results because they will have the same plugin ID #64455. This can be problematic when the audit files are not configured properly because you cannot filter on each of the separate audit file’s results.
-
If you use multiple audit files when creating the Policy (as recommended by the Nessus forums), there will be duplicate entries within the compliance checks. Because you can’t separate the results this becomes even more problematic, and a better thing to do would be to use each audit file separately for a separate Policy until they are properly tuned.
-
You can test your credentials by installing and configuring the vSphere Client and attempting to authenticate using the client as one option. But, if this is not installed on your machine, you can’t install it, or don’t want to install it, a quicker test to see if your username and password are correct, and to verify that VMware vSphere is running the API, is to navigate to the /mob directory of the target.
Once properly authenticated you will be presented with the API interface.
This is a useful test when the credentials are being supplied by an external party, or are particularly long (and easy to fat-finger).
-
When creating the VMware vSphere Policy, it must be adjusted for every unique username and password combination for each host. So, if you are scanning multiple hosts and they do not have the same username and password, the Nessus Policy will have to be updated for each host scanned.
-
If you’ve run a scan and want to filter out Compliance Check results more efficiently to match the hardening guide, a suggestion is to export the data to a CSV file and open it with a spreadsheet application that can use more complex filtering requirements that Nessus does not provide:
-
Plugin ID is 64455 (vSphere Compliance Plugin ID)
-
AND Contains FAILED in the Description
-
AND does not contain “update {” in the Description
-
AND does not contain “NOT found” in the Description
-
This will omit the false positives that occur from a lack of an audit file configuration and can provide you with a quick-win before you have the ability to properly configure the audit file for the local environment.
Author: Sam Bertram
©Aon plc 2023
