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.
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.
Check: esxcfg-advcfg -g /UserVars/ESXiShellTimeOut # This checks the current value, expressed in seconds Fix: 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.
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. 🙂