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.

Ah the dreaded STIG. For many, a necessity by way of policy, but an implementation headache for all. Sadly the ESXi 5 STIG, released at V1R1 on August 9th 2013, will be no different.

In the spirit of VMFieldTips I will be taking you on a journey over the next few weeks through the ESXi 5 STIG. I will hit the head scratchers, problem points, and the just plain crazy.  Also, where appropriate, I will try and loop in the official VMware Security Hardening Guides if possible.  I know @mikefoley will be proud.

What this blog series is not:  It is not an official implementation guide by any means.  It is a compilation of questions and answers from the field on how to address, or in some cases securely work around, the findings in the ESXi 5 STIG.  It is completely open for comment and can be driven by you.  If I have not covered a specific finding yet, ask me for it.  If you have a better way, throw it into a comment on the article.  I will review, discuss, and possibly even add it into the article itself.  Blogs are a way to learn, share, and in this case overcome and intense feelings of insanity as you muscle through the ESXi 5 STIG.

The ESXi 5 STIG is made up of three parts, ESXi Server, vCenter Server, and VM (vmx).  I will start this series off in the ESXi Server portion of the STIG, a few findings at a time to reduce the time between posts.  Already, just from the start, we are going to have our work cut out for us.

Posts that are a part of this series will be linked below.  I will also provide the full STIG ID(s) in each post for easy searching and Google indexing.  Ok, now let’s get to it.

Blog Series Table of Contents:

Blog Series: ESXi 5 STIG – ESXi Server SSH Daemon

Blog Series: ESXi 5 STIG – File and Setting Persistence

Blog Series: ESXi 5 STIG – ESXi Server SSH Client

Blog Series: ESXi 5 STIG – ESXi Server Password Complexity Requirements

10 thoughts on “Blog Series: ESXi 5 STIG – Dichotomy of Policy and Implementation

  1. Eric,
    Thanks for taking the time to do this. As one of the soldiers in the trenches my first reaction to this STIG was does DISA even run ESXi ?? I have found numerous errors which make me wonder if they tested it at all. I know there was an attempt to do a sanity check with DISA but apparently was not taken to heart by DISA.

    • Hi Lee,

      DISA is a huge VMware shop. However, I agree. There’s no way some of this was actually tested. I’ve submitted corrections for all three STIGs, which are due out in late October as Revision 2.

  2. Eric,
    Having talked to the DISA contractor that wrote the STIG, he assures me most of these items weren’t tested. Apparently he doesn’t have access to the support contract to open support cases either and DISA has no plans to acquire more versions of ESXi (no 5.1/5.5 in the works).

    FYI. Rev3 was issued without announcement because Rev2 picked up some unnecessary IAVA checks when it was automatically generated.

    The items I’ve found that aren’t addressed in your articles yet are:
    ESXI5-VMNET-000020 The system must ensure there are no unused ports on a distributed virtual port group.
    -In 5.1 there’s a pick list instead.

    ESXI5-VMNET-000026 The system must disable the autoexpand option for VDS dvPortgroups.
    -This becomes enabled by default in 5.1 but there is no way of disabling it.

    SRG-OS-000126-ESXI5 The system must set a timeout for the ESXi Shell to automatically disable idle sessions after a predetermined period.
    -This appears to set the SSH service to disabled after 15 minutes instead of just logging off idle sessions.

    GEN005900-ESXI5-00891 The nosuid option must be enabled on all NFS client mounts.
    -In 5.1 the there is no /etc/fstab to verify this. The STIG doesn’t have instructions on how to check this using “esxcli storage nas” commands.

    GEN002260-ESXI5-000047 The system must be checked for extraneous device files at least weekly.
    -How do you do that?

    SRG-OS-99999-ESXI5-000158 Unauthorized kernel modules must not be loaded on the host.
    -This check is quite painful. There should be an automated way to do this.
    -There are a couple of unsigned modules. What are these?

    Thanks!
    Albert

    • I’ll get better detail on this when I have the access, but I wanted to respond.

      Agreed on R3. R2 didn’t live long because I immediately got hold of the PM and had it pulled for the reasons you stated, and for the vCenter version having a missing xccdf.

      The support case / access to resource issue is a bit more complicated for them and really boils down to contracting rules. I have a plan on ace to remedy this for R4, whenever we get that revision on their calendar. We didn’t have direct access to the contractor during the original R0 and R1 cycles.

      The finding you list that I didn’t address is really appreciated. I hit the real bad boys first and didn’t get back to address these due to time. I’ll take care of that. The device check you mentioned is covered in my latest post on SetUID / SetGID.

      Thanks, as always, for the detailed feedback. It will benefit everyone.

  3. STIG ID: GEN005900-ESXI5-00891: I was wondering if you came across an answer for this STIG ID? IN ESXi5.1 and above, there is no /etc/fstab

    • Hi Jamie, glad to see you keep coming back. Personally I’ve not seen a solution to this. The STIG itself was based upon v5.0 of the product line with no updates planned for v5.1 or v5.5 of the product. Therefore, most agencies I talk to are just making this finding N/A since file systems are no longer mounted in this manner.

      I’m not saying that’s the right action, but it’s the most common one I’ve come across. Let’s just hope they publish a new STIG covering vSphere 6.0 so we can wash away all the pain of the current one. 🙂

  4. It is not like there is a big difference between 5.0 and 5.1/5.5…. uhhh wait there is that SSO thing. For what it is worth I attended a DISA sponsored course a couple of weeks ago about securing virtual environments. The topic of the ESXi 5.0 STIGs came out and our instructor said there is not even a DISA SRR course so pretty much DISA is not even checking the ESXi STIGs during inspections !

    • That’s very interesting Lee, thank you. I’m not shocked, not in the least, but very good information to have.

    • Looks procedural. If you have an expired cert on vCenter you should follow the VMW KB on how to replace that certificate, or use Derek Seaman’s excellent vSphere Cert Replacement too (my choice).

      Beyond that the STIG check itself is simply administrative. Do you have a plan in place to monitor SSL certificate expirations? Great, done. Note that this can be as simple as a reminder on your work calendar or a spreadsheet. They don’t say how, just that you do. Keep it simple and don’t sweat the little stuff.

Comments are closed.