VMware Cloud Community
pmorrison
Enthusiast
Enthusiast

ESX_SRRSecure - Script to allow ESX to pass a DISA Security Readiness Review.

Background: taken from the DISA website:

In a DOD facility all systems must pass the Security Technical Implementation Guide (STIGs) for the host operating system. The STIG is the configuration standard for DOD IA and IA-enabled devices/systems.

A Security Checklist (sometimes referred to as a lockdown guide, hardening guide, or benchmark configuration) is essentially a document that contains instructions or procedures to verify compliance to a baseline level of security.

Security Readiness Review Scripts (SRRs) test products for STIG compliance. SRR Scripts are available for all operating systems and databases that have STIGs, and web servers using IIS. The SRR scripts are unlicensed tools developed by the Field Security Office (FSO) and the use of these tools on products is completely at the user's own risk.

The problem:

As of this writing there is no “official” VMware ESX STIGbut it has been determined that since the ESX service console is *nix based it must conform to the latest Unix STIG.

The current Unix STIG is located here:

The current Unix SRR is located here:

When reviewing the results of the SRR, not all open issues are valid as the DISA SRR was written for UNIX, LINUX, and AIX. The ESX’s console operating system is based on the Linux Redhat Enterprise 4.5 version, but only contains a subset of the entire operating system and has been customized with specific functionality for interfacing the ESX kernel.

The solution:

Running the SRR will result in an open findings report. After remediating the open issues the SRR is re-run. The goal is to have as few open issues and to document the remaining items as either false findings or open issues with notes as to when they will be closed (patches from VMware) or why they need to be left open.

An example of an open issue is:

==========PDI=IAVA1115 Result========================

PDI Number: IAVA1115

Finding Category: CAT II

Reference: IAVA 2007-T-0042

Description: Sun JRE Web Start Multiple Remote

Vulnerabilities.

Status: Open – *will be fixed in a patch from VMware due

in June.*

For example:

IAVA1115: IAVA 2007-T-0042 - Sun JRE Web Start Multiple

Remote Vulnerabilities.

Outdated

/usr/lib/vmware/webAccess/java/jre1.5.0_12/bin/java, JAVA version 1.5.0.12

found on esx.philhome.dyndns.org.

Upgrade to JAVA version 1.5.0.13 on esx.philhome.dyndns.org.

=========================================================

An example of a false finding that will remain is:

==========PDI=IAVA0360 Result========================

PDI Number: IAVA0360

Finding Category: CAT I

Reference: IAVA 2003-A-0015

Description: There are multiple vulnerabilities in OpenSSL.

Status: Open – *This is a documented false finding as the

vulnerabilities were fixed but the version number was not updated.*

For example:

IAVA0360: IAVA 2003-A-0015

/usr/bin/openssl version 0.9.7a found on

esx.philhome.dyndns.org 2.4.21-47.0.1.ELvmnix.

==========PDI=IAVA0410 Result========================

The ESX SRR Secure script is a shell script which attempts to remediate all of the issues possible on an ESX 3.x host. Some prerequisites to running this script are as follows:

1. Must be run as root.
2.The host must be in maintenance mode.
3. Before beginning with the SRR its advised to install the LAuS library to increase auditing capabilities within the ESX service console, as by default there is limited auditing taking place within the service console itself. These libraries are located on the VMware ESX CD in the /vmware/RPM/ directory. (Note: It appears that this is installed by default in ESX 3.5 update 1)
4. </span>Make sure that all passwords meet the complexity requirements. 7 characters with at least 1 number, 1 symbol, 1 upper case and 1 lower case. This needs to be done for root and any additional accounts installed manually. (Do not change any accounts created by adding a host to Virtual Center).

Once the system is ready, run the script as root and allow the host to be rebooted. Re-run the Unix SRR and compare the open findings report. Below is an example of the summary section both before and after running ESX SRR Secure:

Before:

CAT I = 3/541, CAT II = 55/541, CAT III = 3/541, CAT IV = 0/541

After:

CAT I = 1/139, CAT II = 9/345, CAT III = 1/57, CAT IV = 0/5

The remaining open issues should be documented and should be sufficient to present to the DISA FSO for approval.

Since this is the first “public” exposure for this script, please consider this an early release and test this in a NON-production environment until verification can be made that it does not break something. Also, please give feedback as we would love to see what the community thinks and are continuing to try and make this process better.

Updated script with some corrections and begin to address ESX STIG findings.

Tags (4)
Reply
0 Kudos
134 Replies
Texiwill
Leadership
Leadership

Hello,

Who made the determination that it must conform to the latest *nix STIG? That would be interesting information. In this case, the STIG may be satisfied but there may still be vulnerabilies as this test is NOT VMware specific.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354, As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

The DISA group made that determination. I believe the up-and-coming ESX STIG that is currently in draft will also have a direct finding that explicitly states it must pass the unix STIG. Of course, this is based on a draft so things may change. I do know that in order for the FSO to approve hooking up the network for the current project we needed to pass the SRR and document the remaning open issues.... Which is how this whole script started.

Reply
0 Kudos
Pennguino
Contributor
Contributor

Hey P,

Received this email. Figured I would pass it along.

The Field Security Operations (FSO) has released the ESX Server Security

Technical Implementation Guide (STIG), Version 1 Release 1 and the ESX

Server Checklist, Version 1 Release 1. The requirements of the ESX Server

STIG become effective immediately.

Classification: UNCLASSIFIED

Here is the PDF

I have not read it as of yet. Just found it about 15 minutes ago. Came across your website that referred me to this link. Hope it helps. Hopefully we will be able to say that ESX3i is an appliance and get away from the DISA requirements for a bit.

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

Thanks! I heard about this last night but have not had a chance to post it. My collegue and I have already made some modifications to the script based on this new STIG. We will post an update as soon as we work out the bugs.

Thanks for the heads up.

Reply
0 Kudos
vmjim
Contributor
Contributor

Does anyone have a suggestion or script on how to comply with the following UNIX STIG requirement?

•3.1.1.1 GEN000140 - Create and Maintain System Baseline

Confirm with the SA that a system baseline (all device files, all sgid and suid files, and system libraries and binaries), to include cryptographic hashes of files in the baseline, has been created and is maintained.

If a system baseline (all device files, all sgid and suid files, and system libraries and binaries), to include cryptographic hashes of files in the baseline, has not been created and is not maintained, then this is a finding.

The posted script was very helpful.

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

Thanks for the feedback! I will check around and see as I know of some redhat specific lockdown scripts that might address that finding.

Reply
0 Kudos
vmjim
Contributor
Contributor

I expect the solution is a simple script that finds all the requires files and performs an md5 hash. Something like "find / -name ??? -print |openssl dgst -md5 &gt;/tmp/test.txt". This example is close but does not print the file name, only the md5 hash.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

There are several tools I know of that will produce this type of baseline. One is the Tripwire code that comes with most Linux distributions. The one from Tripwire.com will also work. The other is TCT (The Coroner' Toolkit) with its follow-on named Sleuthkit (Brian Carrier's replacement for TCT), and the last tool would be Tara Tool a fork of the Tiger tool.

TCT/Sleuthkit will produce MD5s/SHA1 for each file. However, you really want sha1sum instead as md5's are not forensically sound. And forensics is the reason for the baseline.

Once more you will want to ignore all files in /vmfs when doing this as they will definitely change over time. If you use a well known tool you will have less to worry about going forward.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
perrymans
Contributor
Contributor

For some reason the links in the Unix STIG for tools no longer go anywhere.

Tripwire is the most common.

FCheck is the easiest to install and configure (only requiring Perl). Just make sure you touch the database file for it, for some reason the install script doesn't do it.

Thanks. Sean.

Reply
0 Kudos
dhand
Contributor
Contributor

To address GEN000140, I use this script:

echo "suid and sgid files" > checksum.txt

find / -type f \( -perm -4000 -o -perm -2000 \) \-exec /usr/bin/sha1sum {} \; >> checksum.txt

echo " /usr/bin files" >> checksum.txt

find /usr/bin -type f -name "*" \-exec /usr/bin/sha1sum {} \; >> checksum.txt

echo " /etc files" >> checksum.txt

find /etc -type f -name "*" \-exec /usr/bin/sha1sum {} \; >> checksum.txt

Add in any other directories you would also like to save...

Compare the results with a previously saved version, for example

  1. mv checksum.txt checksum.2008_0703

  2. diff checksum.2008_0703 checksum.2008_0624

The checksum files should also be saved wherever the IAO stores all system baselines (some other machine).

Reply
0 Kudos
perrymans
Contributor
Contributor

We also wrote our own fix scripts, but this one is far better scripting. We did have a few more extras which drops our Open Findings from 63 to 18.

Take away the 1 from our development 'Changeme' password, 2 NA'ed for at (not installed on ESX), and 8 NA'ed for no auditd in 2.4 kernel, I get only a couple of busniess cases left to write.

GEN006600 does still fail on us though, so maybe someone can point out where the script is going wrong. We haven't looked into it yet, but think it may be because sendmail isn't there to trigger these logs.

Thanks for the great script! Wish I had it 1.5 months ago when we started our architecture review!

Thanks. Sean.

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

Just to let everyone know, I updated the first post with a newer version of the script (it is now at 1.2). More updates to follow as we are beginning to try to tackle the ESX findings in the new ESX STIG. I believe the 006600 finding was fixed but if it still does not get repaired with this version let us know and we will work it out.

Reply
0 Kudos
green_lantern
Contributor
Contributor

You may not need to do anything special.

TCS Security Blanket will lock down your system. But to get a baseline, you can build a system with jumpstart, and include scripts for configuration. This way every system you jumpstart should have the same thing. Then to ensure your system is not tampered with integrity checkers like tripwire, BART (native for Solaris), or swatch (simple watchdog, its tripwire like).

I think if you had a good jumpstart environment, you should be fine.

Reply
0 Kudos
Aaron_Lineberge
Contributor
Contributor

I was able to run the latest v1.3 script after an initial install of ESX but now am unable to log in as root on the console after the reboot. I'm wondering if some of the password complexity changes have caused this. has anyone else run into this issue, and does anyone know of a way to get back into the ESX Linux OS without reinstalling the ESX server?

Thanks in advance!

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

have you tried logging in with an unprivilaged account and then su - to get to root access? I know as part of the STIG checklist logging onto a host directly as root is not allowed as they want to be able to track user accounts that use sudo or su -.

I will double check on this end but I believe in 1.3 you should still be able to log on directly at the keyboard of the ESX box as root. We have been talking about locking that down as well since it can show up as a finding but I will doublecheck on my end.

What version of ESX? I know in 3.5 durring the install you should have been prompted to create an unpriv account.

Reply
0 Kudos
Aaron_Lineberge
Contributor
Contributor

Hi,

This is version 3.5. Unfortunately I was not the one who went through

the initial install, and the person who did did not create any

unprivlidged accounts. The only thing I can think of is if the password

did not meet the complexity requirements put forth by the script then

for some reason the authentication is failing. Which by the way the

complexity requirements have changed and become less restrictive as of a

few months ago. It is now a length of 14 with 1 upper, 1 lower, 1

numeric, and 1 special character which is not reflected in the script.

Thanks!

Aaron

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

Don't know why I didn't think about this earlier.

From any machine with VI3 client installed, try connecting directly to the host and using the known root/password. If you can connect go to the users tab and add a user (make sure to check the box to allow console access). Once you have done that you should be able to log in from the console as this new user and then be able to su to root.

Reply
0 Kudos
Aaron_Lineberge
Contributor
Contributor

We were able to boot into single user mode at the console and change the password to meet the complexity requirements. I'll have to remember to change all the passwords to meet complexity requirements prior to running the script next time.;)

Reply
0 Kudos
surfup
Enthusiast
Enthusiast

Philip,

For the ESX script, is there a way to output it to the log file for later review. Since went I ran the script I have notice some errors ... but it went by so quick that I could not read what it's for? Or, how to pause the script at certain point to see what is going on. I am new to UNIX and script language so I would ask first.

Cheers,

Reply
0 Kudos