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

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.

HZW 1.5-1220937 Password Expired Error

HZW 1.5-1220937 Password Expired Error

Got this? Yep, that’s what I thought. If you’re working with the GA release of Horizon Workspace 1.5 (Build 1220937) dated July 30th, 2013 and you are performing a new installation (after September 8th 2013) you will be greeted with the screen above.  In this article I’ll walk you through how to fix this issue on existing Horizon Workspace 1.5 (Build 1220937) installations, and cover something you need to know in product that the KB does not tell you.  At least it doesn’t yet.

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

For years now as VMware has traveled down the path of the Virtual Appliance.  It’s nothing new, but the approach has changed thanks to a few very key people within the company.

The Virtual Appliance of the past typically almost never saw an OS patch, rarely was hardened, and quite frankly scared Federal Admins and IA groups for those reasons.  Truth be told, they all wanted to use them, but getting it approved was just too much of a hurdle.  That is quickly changing, and some of it has already and you didn’t even know it.

With 5.5 on the horizon you’re going to see a new breed of Virtual Appliance for products such as vCenter Server and vCenter Orchestrator that are all based upon a common OS, common set of services, and a common set of hardening.  No more one-offs, everything is going to a standard.  What does that mean for you?  A great deal from both the administrative and security point of view.

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