The much anticipated vSphere 5 Security Hardening Guide was just released last week by VMware and includes several new guidelines for the vSphere 5 platform. In addition to the new guidelines, you will also find that the old vSphere 4.x guideline identifiers (e.g. VMX00, COS00, VCENTER00) are no longer being used and have been replaced by a new set of identifiers. You might ask why the change? Though I can not provide any specifics, but rest assure this has been done for a very good reason. There is also a change in the security guidance levels, in the vSphere 4.x guide, you had enterprise, SSLF and DMZ and with the vSphere 5 guide, you now have profile1, profile2 and profile3 where profile1 provides the most secure guidelines. To get a list of all the guideline changes between the 4.1 and 5.0 Security Hardening Guide, take a look at this document here.
I too was impacted by these changes as it meant I had to add additional logic and split up certain guidelines to support both the old and new identifiers in my vSphere Security Hardening Script. One of the challenges I faced with the old identifiers and creating my vSphere Security Hardening Script is that a single ID could be applicable for several independent checks and this can make it difficult to troubleshoot. I am glad that each guideline is now an individual and unique ID which should also make it easier for users to interpret.
To help with your vSphere Security Hardening validation, I have updated my security hardening script to include the current public draft of the vSphere 5 Security Hardening Guide. You can download the script here.
Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.
The script now supports both a vSphere 4.x environment as well as vSphere 5.0 environment. In addition to adding the new guideline checks and enhancing a few older ones, I have also included two additional checks that are not in Hardening Guide which is to verify an ESX(i) host or vCenter Server's SSL certificate expiry. I recently wrote an article on the topic here, but thought this would be a beneficial check to include in my vSphere Security Hardening Script. If you would like to see the verification of SSL certificate expiry in the official vSphere 5 Security Hardening Guide, please be sure to provide your feedback here.
Here is a sample output for the Security Hardening Report for a vSphere 5 environment using "profile2" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html
UPDATE (06/03/12): VMware just released the official vSphere 5 Security Hardening Guide this week and I have also updated my script to include all modifications. If there are any feedback/bug reports, please post them in the vSphere Security Hardening Report VMTN Group.
If you have any feedback/questions, please join the vSphere Security Hardening Report VMTN Group for further discussions.
vSpider says
Are you aware that v1.0 of the hardening guide is now available at:
http://communities.vmware.com/docs/DOC-19605
Will you be looking to update your script in the near future??
William says
@vSpider,
Yes I'm aware, I contributed to the final document. There will be an updated script that should be out later this week with the updated changes.
William says
@vSpider,
I've just published the latest version of the script which is based on the GA version of vSphere 5 Security Hardening Guide
Abdullah^2 says
Much thanks :-).
Anonymous says
Hi and thanks for an excellent script.
I do however have a bug report.
For example the SSLF only reports VMX20 and VMX24 when running the script with recommend_check_level sslf. recommend_check_level dmz reports VMX02 and recommend_check_level enterprise reports VMX01, VMX12 and so on.
The VMware vSphere 4.1 Security Hardening Guide states that:
"Unless otherwise specified, higher security levels include all recommendations from lower levels. For example, a DMZ environment should implement all level Enterprise and DMZ recommendations, except when otherwise specified (e.g., a parameter that should be set to one value at level Enterprise but a different value
at level DMZ)."
William says
@Anonymous,
Based on the individual checks from the latest vSphere 4.1 Hardening Guides, this is not a bug as the script does follow the recommendations as per the guide. Though I do agree the verbiage is a little confusing and I will relay this feedback to folks responsible for the guide.
Thanks
Anonymous says
Hi William,
Thank you for your great work on developing these scripts. They are very appreciated and save us all a lot of time and effort.
I wanted to double-check direct from the source that the script is READ-ONLY and doesn't actually make any changes to the environment. (Apart from writing an output report, etc).
Regards,
Jose
William says
Hi Jose,
That's correct, it's all read-only.
sarah lee says
Fine information, many thanks to the author. It is puzzling to me now, but in general,
the usefulness and significance is overwhelming. Very much thanks again and good luck!
security company
Leandro Latorre says
Hi William, in order of priority, thanks so much in a name of all for your contribution with this script, this will reduce a lot of work hours to us.
I have a question about if exists a planning for update this script to compliance with the "vSphere 5.5 Security Hardening".
I dedicated a few days to find any script or tool that check these, but I don't find anything. Do you recommending me any tool or script to this job?
Thanks in advance, Leandro Latorre