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.

ESXI5-VMNET-000010 – Must Not Use Native VLAN On Portgroups

There’s really not an issue with this check, only a note that I want to make so everyone is aware.

In a physical world a native VLAN is simply the untagged traffic on a trunk.  If you have multiple VLANs on a trunked interface anything that enters that interface that is untagged belongs to the native VLAN, which is whatever VLAN the networking guys have it set to.  ESXi has absolutely zero concept of native VLAN, and it shouldn’t because quite frankly it’s annoying in my opinion.  🙂

If you need to place VMs on the native VLAN take care not to tag them via the port group.  If you tag the native VLAN on a tunked interface the physical switch will drop the packets.  In other words, if, for example, you have a trunk that has a native VLAN of 100 and you tag traffic in ESXi on VLAN 100 on that trunk the traffic WILL BE DROPPED at the physical switch.  Don’t get caught troubleshooting that one, trust me.

ESXI5-VMNET-000013, ESXI5-VMNET-000014, ESXI5-VMNET-000015, ESXI5-VMNET-000016 – Forged Transmits and MAC Address Changes to Deny

Forged Transmits and MAC Address Change Policies.  Again, nothing directly wrong with these checks, just some education.  Many do not understand what each policy does.

Forged Transmits compares the effective MAC address of the VM (the one the OS NIC is using) to the MAC address contained within the Ethernet frame (the one the OS actually sent).  There are very valid reasons for NOT setting the Forged Transmit policy to deny.  One many reason is clustering, be it MSCS, Veritas, etc.  Clustering software absolutely forges MAC addresses between nodes, so if you set this policy per the STIG your clustering software will likely not work.

MAC Address Change policy compares the “effective” MAC address, which is the one the OS NIC transmits, to the “initial” MAC address, which is set and configured by vCenter.  If these do not match, the port is shut down.

Two great articles on this topic can be found over on Chris Wahl’s site.

How The VMware Forged Transmits Security Policy Works
Rejecting VMware MAC Address Changes Explained

ESXI5-VMNET-000020, ESXI5-VMNET-000026 – Restrict Total Ports and Auto-Expand on All Portgroups

This is the “no unused ports” and “disable auto-expand” on the port group check.  Look, this is a CAT III, and I really don’t want to go on record saying don’t do this or that, but please think very carefully before you comply with these two checks.  Not only will your administrative overhead skyrocket here, you will also severely limit your interoperability with vCloud Director, vCloud Automation Center, and possibly more.  If you really find the control in these checks important find another way, such as vCenter roles, to control the network memberships.  I really look at this is using a sledge hammer to hit a nail.  There are better tools in your bag for this and if you swing the big ass hammer the SITG is suggesting, you will regret it in terms of usability and interoperability going forward.

SRG-OS-000056-ESXI5, GEN000240-ESXI5-000058 – NTP Configuration

So SRG-OS-000056-ESXI5 tells you to set ESXi Server NTP to a time source local to your enclave.  GEN000240-ESXI5-000058 says to set ESXi Server NTP to a DoD approved time source.  Which is it?  Who knows, but NTP talks over the management interface, and typically management networks do not have N(S)IPR access.  Also, anyone worth their salt syncs time to a master router or AD in the enclave, then out to DoD.  Roll the dice, but I’ll be suggesting to DISA that they clean this up.  I would set everything local to your enclave then argue at CCRI time that it’s a DoD approved time source by abstraction, so long as something is actually syncing up to a DoD source.

SRG-OS-000095-ESXI5 – Inetd Must Be Disabled If Not Used

So this one is slightly tricky if you are a “letter of the law” kind of person.  Both ESXi 5 and 5.1+ use inetd.  You’ll see this when you cat the /var/run/inetd.conf file.  That being said, technically, to be compliant you must run ps and grep on the services found in the conf file, and they must show up, in order for it to not be a finding.  Here’s the trick, they only show up if you are actively using them.  Not logged in via SSH?  Then SSH will not show in a PS list.  Want the proof, login via ssh and rerun the check section of the STIG finding.  Authd is the same way, only it’s not as easy to trigger it to run so you can see it in the PS list.  My opinion, mark this compliant and move on, but that’s just my opinion and it’s really hard to provided you basis for that other than to tell you that Inetd is being used, even if the check doesn’t show it the way the STIG has intended.

SRG-OS-000126-ESXI5, SRG-OS-000163-ESXI5 – ESXiShellTimeOut Value

Nothing wrong with this check, except maybe a little clarity.  Be careful here that you use minutes where it’s expecting minutes, and seconds where it’s wanting seconds.  If you do this from the command line it wants seconds, so if you put 15 you’re in for a surprise.  🙂  Use the command below and all will be well.

esxcfg-advcfg -g /UserVars/ESXiShellTimeOut      # This checks the current value, expressed in seconds

esxcfg-advcfg -s 900 /UserVars/ESXiShellTimeOut  # This sets the shell timeout to 15 minutes (900 seconds) per the STIG

SRG-OS-000144-ESXI5, SRG-OS-000147-ESXI5, SRG-OS-000152-ESXI5, SRG-OS-000231-ESXI5 – Only Allow Connections From Specific Network In Firewall

This one is pretty easy, but ugly as hell to implement.  I’m still working on a way to automate this for you, but for now I’m afraid your best choice if you want to comply is via the C# client and making the modification by hand.

GEN000380-ESXI5-000043 – GID Assigned To A User Must Exist

Here they want you too look at the local users and make sure they are a member of a group that exists.  Simple enough, except there’s a change to note between ESXi 5.0 and ESXi 5.1 and up.

In ESXi 5.0 you can use the vCenter Client, as called out in the check/fix section of the STIG finding, to verify the user/group membership.  All of this works, and from an ESXi 5.0 standpoint, there’s no issue here.  However, in ESXi 5.1+ the concept of local groups on ESXi no longer exists.  If you use the vCenter Client to view the user/group relationship, like the check/fix tells you to, you’ll notice that the groups tab is completely empty.  Never fear though, there’s hope yet.

In ESXi 5.1+, since the group tab in the thick client no longer shows groups, just login via SSH or the console and verify user/group membership by hand.  Compare the users in /etc/passwd to the groups in /etc/group.  While the check/fix isn’t accurate for anything above 5.0 you can still be in compliance with this finding, unless you have an inspector with blinders on.

GEN003510-ESXI5-006660 – Kernel Dumps Should Be Disabled Unless Needed

So here they are shaking a finger at core dumps.  I’m not going to debate their usefulness, or the security implications of having them enabled, but I do want to talk about your options and the behavior.

In this finding they have you disable the core dump partition using an esxcli command.  What they do not tell you is that it just enables itself again on next boot if you don’t set something else up.  Can we say “didn’t test this?”.  Yep, they didn’t test this at all.  So what do you do?  Well, you can ignore the finding and mark it N/A leaving your partition in place, because the finding actually says if core dumps are required this is not applicable.  Nice easy out they gave you there.  You could also offload your dumps to the ESXi Dump Collector as an alternative, deleting the dump partition on the local disk.  Either way works in my opinion.

If you want to disable and remove the dump partition, sending all core dumps to a network location, do the following.  (Do this at your own risk, not on production first please)

esxcli system coredump partition get  # Note the device ID of the dump partition
esxcli system coredump partition set -u  # This removes the dump configuration
partedUtil delete /vmfs/devices/disks/<disk id from above>  # This will delete the actual dump partition, be careful

Then, setup the network dump.

esxcli system coredump partition get  # Ensure it's not active or set
esxcli system coredump network set -i x.x.x.x -v vmkX  # Insert the IP address where you installed the dump collector, and vmk number that's on that network
esxcli system coredump network set -e true

Verify you're good.

esxcli system coredump partition get

As I said in the previous paragraph, I read an out in the STIG finding. If you want core dumps, the finding is N/A, not Open. Important distinction to be made there.

GEN008640-ESXI5-000055 – System Must Not Use Removable Media To Boot

Ok, so I bring this up only as a point of clarification.  This check is not telling you that you cannot have ESXi on removable media, which is how it’s installed on most servers today.  It’s saying that any removable media set in the boot menu that is NOT ESXi must be removed.  See that distinction here, because many are not, and I’ve had more than one person mention to me that they cannot use their servers now because they have ESXi on SD or USB memory.  DISA is not, in my opinion, trying to tell you that you cannot use servers that boot from SD Cards or USB Sticks, like many today do.  They are simply saying don’t have any OTHER types of removable media in the boot option menu.

SRG-OS-99999-ESXI5-000137 – Must Disable MOB

I only want to point this out because if you disable to MOB you may have difficulty installing certain things to the ESXi Server without the MOB active.  I’m not saying you will, because I don’t have enough solid evidence yet, but just keep this in the back of your head if a mysterious issue arises later and you don’t know what’s going on.  It’s easy enough to turn back on if you need it.

SRG-OS-99999-ESXI5-000152 – Must Remove authorized-keys File

This one is simple enough to comply with, but it rubs me a little wrong, so I’m going to vent here.  There’s a much easier way to prevent password-less login via ssh than inspecting a file for authorized keys.  Just look in the sshd_config file and comment out the AuthorizedKeysFile setting.  This is where SSH goes to look for those keys.  No setting, no keys, no worry.  Sometimes things are made harder than they need to be.

GEN002400-ESXI5-10047, GEN002460-ESXI5-20047, GEN002260-ESXI5-000047 – Weekly Check For setuid, setgid, and Extraneous Device File Changes

I’ve covered this in a separate article, linked below.

Blog Series: ESXi 5 STIG – setUID setGID and Device File Monitoring

Administrative and Common Controls

Apologies in advance, I know this list is annoying, but I wanted to be sure and list all the STIG IDs that are administrative or can be applied without issue.  I did this in an effort to be thorough, and for the Google index value.  If any of the below IDs are causing you issue, or you feel as though they were minimized incorrectly, please leave a comment to discuss.  I’m happy to hear from you and/or correct the article as necessary.

GEN002430-ESXI5, ESXI5-VMNET-000001, ESXI5-VMNET-000002, ESXI5-VMNET-000003, ESXI5-VMNET-000004, ESXI5-VMNET-000005, ESXI5-VMNET-000006, ESXI5-VMNET-000007, ESXI5-VMNET-000008, ESXI5-VMNET-000009, ESXI5-VMNET-000011, ESXI5-VMNET-000012, ESXI5-VMNET-000017, ESXI5-VMNET-000018, ESXI5-VMNET-000019, ESXI5-VMNET-000021, ESXI5-VMNET-000023, ESXI5-VMNET-000024, ESXI5-VMNET-000025, ESXI5-VMNET-000036, ESXI5-VMNET-000046, SRG-OS-000080-ESXI5, SRG-OS-000090-ESXI5, SRG-OS-000092, SRG-OS-000104-ESXI5, SRG-OS-000121-ESXI5, SRG-OS-000132-ESXI5, SRG-OS-000145-ESXI5, SRG-OS-000179-ESXI5, SRG-OS-000193-ESXI5, SRG-OS-000197-ESXI5, SRG-OS-000215-ESXI5, SRG-OS-000217-ESXI5, SRG-OS-000248-ESXI5, GEN002420-ESXI5-00878, GEN000100-ESXI5-000062, GEN000940-ESXI5-000042, GEN000945-ESXI5-000333, GEN001375-ESXI5-000086, GEN002120-ESXI5-000045, GEN002140-ESXI5-000046, GEN005300-ESXI5-000099, GEN005440-ESXI5-000078, GEN005460-ESXI5-000060, GEN005570-ESXI5-000115, GEN005900-ESXI5-00891, GEN007700-ESXI5-000116, GEN007740-ESXI5-000118, GEN007840-ESXI5-000119, GEN008460-ESXI5-000121, GEN008480-ESXI5-000122, GEN008500-ESXI5-000123, GEN008600-ESXI5-000050, GEN008680-ESXI5-000056, SRG-OS-99999-ESXI5-000131, SRG-OS-99999-ESXI5-000132, SRG-OS-99999-ESXI5-000135, SRG-OS-99999-ESXI5-000136, SRG-OS-99999-ESXI5-000138, SRG-OS-99999-ESXI5-000139, SRG-OS-99999-ESXI5-000141, SRG-OS-99999-ESXI5-000143, SRG-OS-99999-ESXI5-000144, SRG-OS-99999-ESXI5-000145, SRG-OS-99999-ESXI5-000146, SRG-OS-99999-ESXI5-000147, SRG-OS-99999-ESXI5-000150, SRG-OS-99999-ESXI5-000151, SRG-OS-99999-ESXI5-000154, SRG-OS-99999-ESXI5-000155, SRG-OS-99999-ESXI5-000156, SRG-OS-99999-ESXI5-000160, SRG-OS-99999-ESXI5-000161

The Surgeon General warns that prolonged exposure to DISA STIGs can reduce your life expectancy and cause you to see security violations that just aren’t there.  Use with caution.  🙂

12 thoughts on “Blog Series: ESXi 5 STIG – ESXi Server Everything Else

  1. I would have asked this on Twitter but its too long, haha.

    So I am almost done with the STIG on my lab network when I ran into ESXI-000160. I’m doing up to CAT2 changes on the network and this one states that if I have local accounts that are non-AD and are not root or vpxd, it is a finding. ESXI-000154 is CAT3 and states that you MUST have AD authentication on… so my question is, what do I do about this? If I don’t need AD at CAT2, how do I comply?

    Thanks again for all your help Eric!

    • Hi Adam! Check ESXi-000160 is essentially telling you that if you configure your hosts to join AD automatically via host profiles that you MUST use the Authentication proxy. The real reason here is that the Host Profile stores the AD account password in the clear. The mitigation is to ensure that if you use Host Profiles to join hosts to AD that you use the vCenter Authentication Proxy, and properly configure it within the host profile. This will protect the password and not have it exposed in the clear via the host profile. If you do not use AD, this check is not applicable. Technically, if you join your hosts to AD manually this shouldn’t be applicable either, but the rule title vs. check text in this one is not consistent and a little unclear. Check ESXi-000154 confirms that was the intention, albeit not worded well.

      Check ESXi-000154 only applies if you have local accounts other than root/vpxuser. If you have no need for additional local accounts for access then the check is N/A and you do not have to configure AD.

      In summation, if you have no need for local accounts other than the default root and/or vpxuser then you do not need to configure Active Directory on the host. If you do, then you must control them via AD user objects and Host membership.

  2. GEN002400-ESXI5-10047, GEN002460-ESXI5-20047, GEN002260-ESXI5-000047 – Weekly Check For setuid, setgid, and Extraneous Device File Changes — Any idea when you will get around to discussing how you handled these items?

  3. Regarding ESXI5-VMNET-000026 — Am I mistaken but doesn’t the fix listed on Step 18 in the STIG:


    actually makes this a finding? Shouldn’t the AutoExpand be set to “false” in the above string?

    A coworker was working this configuration on one of the servers. He was sure that autoExpand was set to “true” and the configVersion set to “15”. He updated the Spec text field to “false” and “15”. We are now seeing both the AutoExpand and ConfigVersion displaying “Unset” on all the servers with this dvSwitch. Any thoughts?

  4. Hi Eric,

    First of all, I’d like to state what a treasure trove of information your blog is! Very helpful.

    Regarding GEN002420-ESXI5-00878, I’m applying the STIG to a 5.1 host and do not have a native /etc/fstab. Should I create that file and set the settings within it or is there another place that 5.1 retains mounting info? Thanks!

    • Hi, and thanks for the compliment. I appreciate that.

      The STIG itself is written for 5.0 only. The application of it on 5.1 and above was not the intention of DISA FSO when it was drafted.

      As of 5.1 there is no longer an /etc/fstab to modify. It’s up to you how to handle this, but many have simply marked this check N/A since it is no longer applicable for versions 5.1 and up.

Comments are closed.