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.

Now, lets get started.  You will need to SSH or console into your ESXi host and edit either the /etc/rc.local or /etc/rc.local.d/local.sh files (depending upon your version of ESXi).  Refer to the previously liked article on File and Setting Persistence if you have questions on which to use and where they are.  The file you edit {rc.local|local.sh} is the only difference here between versions.  All other information below is static regardless of the 5.x variant you are running.

At the bottom of this file, but BEFORE the exit 0 in local.sh (5.1+ only), you will want to add the following lines.

NOTE: The echo lines are one-liners, even though the blog justification looks otherwise.

shortname=$(hostname | cut -d'.' -f1)

if [ ! -d /etc/cron.weekly ]; then
     mkdir /etc/cron.weekly
fi

echo "/usr/bin/find / -perm -4000 2>/dev/null > /tmp/suid_list-${shortname}.\$(date +"%m%d%Y-%H%M%S")" > /etc/cron.weekly/suidcheck.sh

echo "/usr/bin/find / -perm -2000 2>/dev/null > /tmp/sgid_list-${shortname}.\$(date +"%m%d%Y-%H%M%S")" > /etc/cron.weekly/sgidcheck.sh

echo "/usr/bin/find / -type b -o -type c 2>/dev/null > /tmp/device_list-${shortname}.\$(date +"%m%d%Y-%H%M%S")" > /etc/cron.weekly/devcheck.sh

chmod 700 /etc/cron.weekly/*

/bin/kill $(cat /var/run/crond.pid)

/bin/echo "30 0 * * 0 /etc/cron.weekly/suidcheck.sh" >> /var/spool/cron/crontabs/root
/bin/echo "35 0 * * 0 /etc/cron.weekly/sgidcheck.sh" >> /var/spool/cron/crontabs/root
/bin/echo "40 0 * * 0 /etc/cron.weekly/devcheck.sh" >> /var/spool/cron/crontabs/root

/bin/crond

Save the file in VI and run ‘/sbin/auto-backup.sh’ to save your changes to the bootbank.  Now, you will either need to reboot to make the change effective, or run the script file ./etc/rc.local or ./etc/rc.local.d/local.sh.

So, what did we do here. Well, first off we created a new directory to hold our cron scripts called /etc/cron.weekly. Then, we added three scripts to that directory, each handling a different part of our search. The cron scripts will search for what’s in question {suid|sgid|device} and save the output to a file in the /tmp directory with the short hostname and date/time attached.  Finally, we added the scripts to the crontab for root so they would run five minutes apart starting at 12:30AM every Sunday, which would be weekly per the finding.

What’s up to you now is how you get those off the ESXi host to your IA team, if that’s a requirement.  Hint: Think about a shared storage location, since we’re appending the hostname to the log file.  You can modify the script to change the location, just replace /tmp/ with another path.

While the scripts above will persist across reboots, if you follow my instructions, the log files will not unless they are moved out of /tmp.  If your IA policy requires they be kept remember to shuttle them off somewhere.  The easiest way to do that would be to save the logs to persistent storage, off the host, which can be easily accomplished by modifying the script above.

Here’s an example of the script above in text format, just in case the blog butchers the formatting. Example Boot Script – UID and Device Search

7 thoughts on “Blog Series: ESXi 5 STIG – setUID setGID and Device File Monitoring

  1. Hello, Thanks for this, but is there a manually way to do this with out having it to persist? A script or command I can run to get the results.

    • Yes. Copy and past all three echo commands to the command line. Then, chmod +x the resulting script files. That will give you three scripts that you can run manually. Just remember they won’t persist unless they are put non-volatile storage.

    • Hi Kristen, the answer depends. There are some items, such as the ssh_config, should have been there in the first place. They will be added into future versions, and hopefully if I get my way, pre-populated with the proper settings. Another example would be privilege separation in SSHD. Two examples that are being scoped for the future.

      Beyond that contact your Sales Engineer and he can give you additional details one on one. If you don’t know who that engineer is let me know.

      • Thanks for the info. I was curious about that. When the draft came out in January I had calls in with support on some of these issues but the answers always came back that it was designed that way. Glad to know some of these issues will be fixed in future versions.

  2. Eric,
    Any thoughts for how to get the off the box over to someplace that can automate the comparison? SSHd is disabled so you can’t automate the SSH into ESXi. How hard would it be to scp the files someplace else (I assume you’d want to use ssh certificates here to avoid embedding passwords in script files).

    Thanks!
    Albert

Comments are closed.