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
vancod
Contributor
Contributor

OK, guess I'm just a little confused why a shell script would have kiclstart directives in in. The script mentions "an example of a script" - I an guessing it's b example of an ESX KS file....

I use AB Edit (or vi in Cygwin), so ^M isn't an issue for me Smiley Wink

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

not sure you are looking at the right script then as I just did a search and could not find any references to "an example of a script". However, I have built custom install CDs in which this script is run automatically in the %post section.

Reply
0 Kudos
vancod
Contributor
Contributor

It's the script in the post I replied to:

http://communities.vmware.com/servlet/JiveServlet/download/1058030-13969/samplescript.sh?tstart=0&st...

It must have been munged by the vmware.com servers...

$ sh ./samplescript.sh

./samplescript.sh: line 1: {rtf1ansiansicpg1252deff0deflang1033{fonttbl{f0fswissfcharset0: command not found

./samplescript.sh: line 1: }}\r': command not found

./samplescript.sh: line 2: {*generator: command not found

./samplescript.sh: line 2: }viewkind4uc1pardsb100sa100f0fs20: command not found

./samplescript.sh: line 3: f0fs20: command not found

./samplescript.sh: line 23: fg: no job control

./samplescript.sh: line 24: fg: no job control

Reply
0 Kudos
shaun138
Contributor
Contributor

Has anyone heard if DISA will come out with the SRR specifically for the ESX Server?

Has anyone compiled a list of False Positives when running the regular SRR against the ESX Server? If so, can you please share...

Is the ESX_SRRSecure v1.4 lockdown script ready to be released?

thanks

Reply
0 Kudos
gavin8r
Contributor
Contributor

I've been following this thread from the beginning and it has proved to be a great resource for me. I'm also a consultant for DoD and have to ensure that our systems are locked down according to the ESX STIG.

We're running ESX 3.5 w/ VirtualCenter 2.5 (planning to go to Update 3 of both in our next testing window)

We've recently run into an issue in our test lab where after running the lockdown script v.1.2 HA stops working. Has anyone else seen this in their environment? This didn't occur on our development test deck but prior to digging in and spending a lot of vaulable time troubleshooting I wanted to check.

I'll drop more details here if anything turns up.

Reply
0 Kudos
perrymans
Contributor
Contributor

I finally get to weigh in on this post!

So I have a problem with the ESX0050 STIG itself, and since my ESX came from Dell, I can't "officially" call VMWare directly because my support is with Dell.

I submitted the following as a possible issue to DISA:

ESX0050 states the following:

Permissions for the virtual machine files will adhere to VMware's best practices. The configuration file (.vmx), will be read, write, execute (rwx) for owner and read and execute (r-x) for group and read (r--) for others (754). If these permissions are not set for the .vmx files then VMotion across ESX Servers may not work. The virtual machine's virtual disk (.vmdk) will be read and write (rw-) for owner (600).

The reference VI3 Security Hardening (p. 7, attached) states:

Be sure permissions for the virtual machine's files are set according to the guidelines in this section.

Permissions for the configuration file (.vmx), should be read, write, execute (rwx) for owner, and read and execute (r-x) for group (755). Permissions for the virtual machine's virtual disk (.vmdk) should be read and write (rw-) for owner (600). For all of these files, both the user and group should be root.

The error is obviously the .vmx permission requirement that states 755 in the hardening guide, but was changed to 754 in the STIG.

The incorporation of a 754 permission would require a manual chmod after the creation of every VM.

In response to my DISA email, I received the following answer:

Status or Resolution Summary: UNFORTUNATELY, THE STIG IS POLICY. THE 754 WAS AGREED AND APPROVED BY VMWARE BEFORE THE STIG WAS PUBLISHED. THERE WAS MUCH DISCUSSION OVER THESE PERMISSIONS AND THE 754 IS THE BEST CONFIGURATION. VMWARE MAY HAVE LESS STRINGENT REQUIREMENTS FOR THEIR NON-DOD CUSTOMERS. THANKS.

Even though the STIG contradicts itself by saying it is using VMWare best practice, but it obviously is not VMWare best practice, DISA is sticking by its document.

I did not know who else to ask, except coming here to VMware and hopefully determining if VMWare really suggested and agreed to 754 for .vmx files for government and why.

Thanks. Sean.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

I am not sure who was involved in that discussion but I think that 755/754 is way to open personally. I have locked them down to 700 with no issues.

At the moment all you can do to adhere to the STIG is a manual change as ESX uses 755.


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.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

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
abaum
Hot Shot
Hot Shot

I didn't see it anywhere, but the link to the latest STIG is now:

adam

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Check out http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links which will be kept up to date. It has a link to the latest ESX STIG, http://iase.disa.mil/stigs/checklist/esx_server_checklist_v1_r1-2_03sep2008pdf.zip and the UNIX STIG to which its dependent as well as a bunch of other useful links from a security perspective.


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.

Blue Gears and other Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

--
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
Vishy1
Enthusiast
Enthusiast

Hi Guys,

Does anyone know if there is version 1.4 been release yet?

Thanks,

If you found this information useful, please consider awarding points for Correct or Helpful.
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Nothing yet.


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.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

--
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
twa3
Contributor
Contributor

Great script, very impressive.

I reviewed the script, and ran it on one of my hosts to compare findings. I'm unable to putty/ssh to the host from my laptop. I was able to ssh from another esx service console. I'm trying to review the changes to find where SSH was affected. I understand root ssh was disabled, but were there some subnet restrictions added to ssh or iptables?

http://mainesysadmin.com
Reply
0 Kudos
twa3
Contributor
Contributor

I think this might have been affected by "hosts.allow" and "hosts.deny" changes. Can anyone confirm this?

GEN006620 - The access control program is not configured to grant and deny system access to specific hosts.

http://mainesysadmin.com
Reply
0 Kudos
twa3
Contributor
Contributor

I'm all set, it was definitely the hosts.allow and hosts.deny files.

http://mainesysadmin.com
Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

There was one ip address hardcoded in the hosts.allow i belive &lt;been a while since I could mess with it.&gt; there was talk previously in this thread where it was called out. I will search for it and reply again.

Reply
0 Kudos
pmorrison
Enthusiast
Enthusiast

OK I found it. If you want smb to work you have to search for 192.168.10. and replace with the proper network.

As for host.allow, the script does a lookup of the ipaddress of your esx box and adds just that network to the hosts.allow. If you have other networks trying to connect to the service console you would have to add those as well... but if this is on a DoD network this is a no no Smiley Happy unless all the boxes involved are on their own VLAN.

Reply
0 Kudos
barkerc
Contributor
Contributor

twa3

I experienced the same issue. I see from the other postings that you already have your solution.

The ESX_SRRSecure script does not make IP entries to 'hosts.allow' ; which would enable remote login from your Virtual Center or another remote management host. You could revise the script to accept data entry of IP addresses from a user. That is what I did. I revised the script and posted a version last September on this forum. You can copy that code from this revised version:

Reply
0 Kudos
twa3
Contributor
Contributor

Indeed ssh is restored, just a sanity check. Now I'll restore the secure files so that cross-vlan ssh is disabled. This forum is a lifesaver. I never thought I'd find a DISA SRR "get-ready" script out here. I was simply looking for an answer to one of the vulnerabilities that I was trying to solve. This is much better.

http://mainesysadmin.com
Reply
0 Kudos
fritschj
Contributor
Contributor

I've downloaded and ran the ESX_SRRSecure script, and rebooted. And know I can no longer ping or communicate with my ESX server. Can anyone tell me what I need to change to make it work again.

- Jonathan Fritsch

Reply
0 Kudos
twa3
Contributor
Contributor

@Jonathan -

If your ESX service console is on a different physical network (or vlan) from your the machine that you're trying to ping you'll need to modify the following files to regain mgmt access to your host:

/etc/hosts.allow

/etc/hosts.deny

Both files were emtpy before the script was run on your host. The script took the IP address from the SC and locked down hosts.allow to only allow TCP traffic from that network. hosts.deny is configured to block all traffic that is no explicitly allowed in the hosts.allow file.

http://mainesysadmin.com
Reply
0 Kudos