In case anyone missed it DISA posted a brand spank’n new ESXi 5 STIG revision on Friday, January 24th.

ESXi 5 STIG Version 1 Revision 4

Now, I want to point out a few things about this revision.  First off I teamed up with a great engineer working for DISA FSO to basically rewrite most of the ESXi 5 Server portion of this STIG.  We put a lot of work into that section and I was proud of the result.  If you’ve had trouble implementing the ESXi 5 Server piece in the past please take a look at the changes in revision 4.  You can see from the release notes alone that dozens of checks were changed, and several deleted all together.

Additionally, a lot of the posts on this blog are now moot if you’re using revision 4.  Why?  Because we essentially used this blog as a point of reference in the rewrite.  I’ll be leaving the posts up here, but note in them that it was pre-revision 4 information.

Finally I wanted to mention our Forge.mil Community Project for ESXi STIG Automation.  If you haven’t signed up for this project yet, please do so.  We will use revision 4 as the focal point for its development.

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.

Had a colleague point out to me that I gave a pass on a STIG finding for ESXi 5 Server that is, in fact, not that straight forward.  I wanted to take a moment to break that finding out and give some additional guidance.

SRG-OS-99999-ESXI5-000158 – Unauthorized Kernel Modules Must Not Be Loaded on Host

So the key word here is “unauthorized”.  What do they mean?  Well, they are talking about unsigned kernel modules, but there’s a trick to even that.  Per the STIG no kernel module may be loaded that lacks a digital signature… so lets look at how we can do this check.

Right off I’ll tell you there’s at least two ways, likely more, to knock this out.  By default there are a LOT of kernel modules on a default ESXi Server install, too many to go through by hand per the instructions in the STIG.  How can we make this easier.

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.

In this article I’m going to cover how you can setup the cron jobs necessary in ESXi 5.x to monitor for setUID, setGID, and device file changes per the ESXi 5 STIG.  I will walk you through adding a few scripts to your system that will provide log files that are date/time stamped.

Note: The following is unsupported by VMware.

The scripts outlined below are for educational purposes only to assist in your compliance efforts.  They are in no way meant to be a singular solution nor a replacement for a commercial OS baseline monitoring tool.

GEN002400-ESXI5-10047, GEN002460-ESXI5-20047, GEN002260-ESXI5-000047 – setUID, setGID, and Extraneous Device File Monitoring

First off, as before, the changes we are about to make will not persist across reboots without our help so please reference Blog Series: ESXi 5 STIG – File and Setting Persistence.  Keep that handy in the next tab over for reference.

So, we need to add some automated scripts to your ESXi host to parse the file system for suid, guid, and device files.  The method in which you review and/or determine changes have been made is up to you, ESXi provides you no mechanism to accomplish this.  All we are doing here is setting up the automated process of dumping the data required per the STIG.

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.

So we need to talk about GEN005537-ESXI-000111 – SSH Daemon Must Use Privilege Separation for a moment.  There’s a lot of confusion around this finding so let us sort through it together.

First off let’s draw a line in this discussion, nothing can be done about this on ESXi 5.0.  The setting just will not work.  The reason?  We did not compile chroot into ESXi 5.0.  However, in 5.1 and 5.5 it is absolutely configurable, with a little finesse and TLC.  Let’s take a look.

Note: The following instructions are not supported by VMware, nor were they tested in any way, shape or form by QA, so I cannot guarantee how they will react in your environment.  Please implement this on an isolated or single host first to make sure there are no unintended consequences.  To date I have not seen any reports of the below settings, if applied correctly, causing issue.

In addition to this article you are going to need to review Blog Series: ESXi 5 STIG – File and Setting Persistence.  This is necessary because we need to create the default chroot location for the privilege separation user.
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.

The total ESXi 5 Server portion of the STIG is 142 setting in total.  So far we’ve covered SSH Client, SSH Daemon, and Password Complexity separately.  This article will cover the rest.  A majority of these are either administrative in nature, or simply cause no issue what so ever.  I will list these by STIG ID at the end of this article, just to round things out.  However, there are a few tricks left up their collective sleeves to cover.  Let’s get started.

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.

Here we will review the password complexity requirements in the ESXi 5 Server STIG.  These are somewhat problematic, and scattered.  I’ll combine things here so it’s a little easier to implement.

Note: Be very aware of what you are doing here.  You can easily introduce a restriction that will puzzle you later.  I'll cover more below, but make sure your admins are aware of this change.

So, let’s get to it. First a list of the STIG IDs we will be covering here.  I’ll be doing this in a couple different groups, pointing out the issues as we go.

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.

Here we go, SSH Client findings.  There are eleven (11) total findings in this section, all involving the SSH Client configuration as laid out in the ESXi 5 STIG.  You will learn that at the time of this article ESXi 5 and above does not contain the configuration file necessary to make these settings persist.  However, you can use the File and Setting Persistence article to build the configuration file necessary at each boot.  This “work around” will become unnecessary in future versions of our product.

Note: Building the ssh_config file per the above article is currently not officially supported. However, it is the easiest way to accomplish the settings below.
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.

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.

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

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