Just got this today from our Center for Policy Compliance guys.  🙂

CP&C is pleased to announce the availability of the Defense Information Systems Agency (DISA) VMware vSphere 5.0 compliance toolkit that is aligned to version 1 and release 3 (V1R3). The benchmark availability announcement was made on 30-Sep-2013 and we churned it pretty quickly! You can download the package using CCW tool and begin to use it.

If you use our vCM product you should download the new toolkit for this update.  As stated above it aligns with V1R3 of the STIG.

*** Update ***

The ESXi 5 STIG for ESXi Server and vCenter Server is now at version 1 revision 3.  The only difference between revision 2 and 3 is the removal of some IAVM findings incorrectly included in the previous release.  The certificate requirements have still been pulled and the below information valid for revision 3.

****

Ok, so yesterday DISA released the ESXi 5 Version 1 Revision 2 of the STIG.  Now this is only Revision 2 of the ESXi 5 Server and vCenter Server STIG, not the VM.  That is still at revision 1.

Why did they do it?  Just one thing, the removal of  the rule The system must not use default self-signed certificates for <ESXi / vCenter> Communication.  So, if you want to follow the STIG, you no longer have to replace the default certificates provided, or you could replace them with an internal CA.

Why did they do this?  Well, there’s a reason, but not one I’m going to put here on a public blog.  If you’d like to know why just ask your SE.  I will have either already informed them, or they can reach out to me for the information internally.

Note: This article covers material present in Version 1 Revision 3 and below.  Topics found below may be mitigated in the most current version of the ESXi 5 STIG.  Ensure you are using the most current version of the DISA STIG documents.

Before we move into Part 2 of the ESXi 5 STIG documentation we need to talk about file persistence and how to deal with it.

Note: This is UNSUPPORTED!  Also, changes made to the rc.local and/or local.sh file may not persist after an update or upgrade.  Take good configuration notes of your systems and verify once an update or upgrade is applied.

Those of you that have been using ESXi for a while now realize that files do not persist across reboots unless they are tagged by VisorFS as persistent.  While this may be inconvenient at times the reasons behind it are valid.

So, along the lines of the ESXi 5 STIG, we have a few things that we need to set and persist across reboots.  Findings that have us modify existing files on ESXi are fine.  We can modify those and they will persist, typically.  Always test with a reboot to ensure your settings stick.  What about the findings where the configuration file doesn’t exist?  The SSH Client (ssh_config) settings are a prime example of this.  ESXi 5+ does not currently have a ssh_config file present in /etc/ssh, so any attempt to create and populate one with settings will be lost on reboot.  That’s a problem for you SAs out there needing to comply with the STIG.

How do I create configuration files and make them persist you ask?  Smoke and mirrors my friend.  Persist by way of recreation at boot.  You could do this with a custom package file too, but that violates another STIG setting, so lets stick with this method for now.

Continue reading

Note: This article covers material present in Version 1 Revision 3 and below.  Topics found below may be mitigated in the most current version of the ESXi 5 STIG.  Ensure you are using the most current version of the DISA STIG documents.

** Updated 9/9/13 to include distinction on Privilege Separation between v5.0 and 5.1 and above **

Note: All settings within the sshd_config file are case sensitive.  Options are typically all lower case {yes|no} and are all expressed as <settings> <option> within the configuration file.  The easiest way to verify an issue during your configuration is to have a second console open and run 'tail -f /var/log/auth.log' while attempting a connection.

I’m going to start with the SSH daemon findings.  Why?  Because it’s been a topic of conversation internally for the past few days, and it’s just littered with problems to talk about.

So, here’s the format we’re going to follow.  I’m going to divide this into sections calling out the STIG ID and Rule Title.  If the rule causes no issue I’ll call it out, but that will be about it.  By the end of the article you’ll have a list of rules that you comply with, or at the very least you’ll know why you cannot.  Here we go…

The SSH daemon settings in the ESXi 5 STIG pose a bit of a problem for those implementing them.  To make it worse, there’s some confusion and lack of direction to several of the findings, plus one permanent finding that you cannot set on 5.0, but can on 5.1+.  Let’s get started with the SSH daemon settings below.  I’ll cover the SSH client settings in the next post. Continue reading