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)
0 Kudos
134 Replies
fritschj
Contributor
Contributor

twa3,

The hosts.allow & deny are not the issue. Even when I'm on the console, I'm unable to ping the gateway, or any other system on the network.

Prior to running the script, this was not a problem.

- Jonathan

0 Kudos
twa3
Contributor
Contributor

Ok, you could be right, but have you tried to blank out the files and reboot to see if the problem persists?

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

If it was that easy I wouldn't be posting about it. come on. I think we are all a little smarting than that.

0 Kudos
twa3
Contributor
Contributor

Your sarcasm isn't appreciated. I was simply suggesting you reverse one of the settings I know affected TCP traffic to your host.

From your original posting it was difficult for me to see if you have reversed any of the changes. Forgive me for my captain obvious moment, but I recently applied the script and experienced TCP traffic issues, resolved them with the steps I described to you.

http://mainesysadmin.com
0 Kudos
Texiwill
Leadership
Leadership

Hello,

If you are logged into the console of the ESX host, then you should check the following items to see if you can ping out. First run these commands and verify the output against what should be there.

esxcfg-vswif -l

esxcfg-firewall -q (or if you prefer iptables -n -L)

Can you ping the IP address of your SC? If not then the vSwif is no longer properly configured.

If this works and you can not ping the gateway then you can disable the firewall using esxcfg-firewall and see if things now start to work. If so then it is a firewall issue.

And now for back to basics suggestion, yes obvious, but sometimes an issue....

Is there a cable issue? I.e. check to see if you have the proper lights on the cards/ports of the switch.

Did the switch change something?


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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

Hello,

THe 1.3 version of the script removes the vimuser account. If you do this then you can not add ESX into vCenter. Just an FYI.


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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

This would have to be something that has changed in an update as I know we testing doing just that after running the script.

Also, during our conversations with VMware they informed us that the only use for vimuser was related to NFS. See the quote from someone from VMware that responded in this thread.

"So I checked on the four findings and whether it is OK to fix them (if

you are using the NFS funtionality that this provides) for the vimuser and the answer is yes. You can chang the UID and GID to something over 499 and you can remove the home directory from the vimuser

account. This should satisfy the four findings you sent. The option to

delete it altogether in this release is also just fine. Future releases

might require it, but for now it wont affect anything by the NFS

functionality.

I hope this helps."

0 Kudos
Texiwill
Leadership
Leadership

Hello,

Well it definitely did not do anything after I removed it, and since NFS is pretty popular at the moment removing it seems a bit premature, instead I would move its directory.


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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

Hello,

Okay, vimuser is not required, probably just a glitch in something I was doing. I now have a good working script. Need to work on some more details.


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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

Being that the vimuser is not used, and removed during the script process. There is the other vmware account left. Can this account be utilized for managing your ESX server from the VirtualCenter Management Server? If so, can you change the password. If not, what step, or account type can be created with root level access for the functionality?

0 Kudos
Texiwill
Leadership
Leadership

Hello,

I actually wrote my own script to satisfy DISA, CIS, Bastille, and VMware Hardening Guide.

Being that the vimuser is not used, and removed during the script process. There is the other vmware account left. Can this account be utilized for managing your ESX server from the VirtualCenter Management Server? If so, can you change the password. If not, what step, or account type can be created with root level access for the functionality?

VC uses the vpxuser user that is created when your ESX host joins vCenter. This is an account you can not login to, it is however used for accessing hostd and other tools. hostd is the main tool that translates commands from vpxuser to root.


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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

I'm about to start some dev/test work for ESXi in a secure PCI DSS zone and wanted to use the information in this thread. I have a some questions:

  1. Has version 1.4 been released/published yet? If so, where?

  2. Will the version 1.2 script work on ESXi?

  3. Section "3.3.1.6 Time Synchronization" of the ESX STIG says:

    (ESX0400: CAT II) The IAO/SA will configure all ESX Servers to use a hashing algorithm to authenticate the time source.

    Does anyone know what this means or how to implement it?

Thanks for the effort so far in this thread.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

I'm about to start some dev/test work for ESXi in a secure PCI DSS zone and wanted to use the information in this thread. I have a some questions:

DISA STIG SRR does NOT apply to ESXi. Actually there is not much you can do to ESXi to improve its security other than place the management interface behind a firewall, set isolation settings within the VMs, and NEVER enable the SSH server. If it was me, I would use all 3 guides out there and pick the appropriate sections that relate just to VMs and just to ESXi. It results in a slim set of instructions. But the SRR will not work within ESXi.


Best regards,
Edward L. Haletky
VMware Communities User Moderator, VMware vExpert 2009
====
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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

I know there hasn't been much traffic on this for awhile though I would love to see development continue (maybe with its own sourceforge site).

Something to note is that when performing udates to your ESX servers, some of the items that the script locks down are reopened. An example would be file permissions or things like the GRUB password. Right now I keep a toned down script on my system and as part of my update process I run that and then update my baseline as soon as the updates are complete and the servers are rebooted.

Though I am not an experienced scripter, I would volunteer to contibute is some way if the development were to continue.

Some things I would like to see are:

  • Prompts for each item (yes/no). In my environment, I have had to remove some items altogether because either they have already been locked down and the script makes modifications I don't need or we deviate from the item totally like the USB configuration in modules.conf (My newer servers require USB for keyboard access).

  • Prompts for IP addresses and config info for smb.conf/syslog.conf/snmpd.conf.

  • Maybe have the inclusion for adding/configuring LAUS.

  • Our site has not purchased any enterprise baselining software, but fcheck has proven to work ok. I would like to see the inclusion of something like that for those sites that don't have something better (no money).

  • Have the script automatically output a report or text document that would have justifications for things that cannot be fixed or are false positives (AT, Linux version, etc). These items can be given to the IAO as documentation.

Steve

0 Kudos
VmwareTSE
Contributor
Contributor

I am having an issue where a customer is unable to apply updates after securing their ESX hosts to pass the DISA Security Review. Is anyone else having this issue?

Thanks

Kevin Riley

Vmware Technical Support

kriley@vmware.com

0 Kudos
barkerc
Contributor
Contributor

First suggestion:

On your ESX host, view the contents of the /etc/hosts.allow file to confirm that your Virtual Center server IP is entered there.

If your Virtual Center server is on another subnet, then you'll definitely need to enter the IP into the ESX host /etc/host.allow file to gain remote access.

Using the IP address of your VI Center, on the ESX command line ... enter:

echo 'ALL: xxx.xxx.xxx.xxx' &gt;&gt; /etc/host.allow

If your problem is not with VI Center access, then please describe your environment and problem in a bit more detail.

0 Kudos
VmwareTSE
Contributor
Contributor

From my understanding of the issue the STIGS are requiring certain files to removed. For instance, samba, pegasus, etc. The updates are then failing because a lot of the RPM's the upgrade is looking for are missing. The customer is running update 2 and when they try to apply update 3 or 4 it fails.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

From my understanding of the issue the STIGS are requiring certain files to removed. For instance, samba, pegasus, etc. The updates are then failing because a lot of the RPM's the upgrade is looking for are missing. The customer is running update 2 and when they try to apply update 3 or 4 it fails.

The STIGs do not actually require many RPMs to be removed. However, they do expect certain settings and configuration files to be set. Samba Server for example should not be enabled, pegasus has never been a problem for me.

I ran through the latest STIG recently on a default install of ESX with no extra packages and no errors about RPMs came up other than the fact that auditd (LaUS) was not installed which is a requirement for the STIG.

Make sure you have the proper STIG ESX which depends on the UNIX STIG.

Yes, after every update the STIG SRR will need to be rerun.


Best regards,
Edward L. Haletky
VMware Communities User Moderator, VMware vExpert 2009
====
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 -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

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

I'm guessing they are referring to the following:

PDI Number: GEN002480

Finding Category: CAT II

Reference: UNIX STIG: 3.12.3

Description: There are world writeable files or world writeable directories that are not public directories.

Status: Open

For example:

/var/pegasus

/var/pegasus/trace

People need to realize that these are guides and even though DoD and other organizations require them, there may be exceptions at times. The administrators/security people need to examine the risks, test, and remediate or even possibly deviate. Even though my pegasus may come up with a hit on the SRR doesn't necessarily mean that I need to uninstall the application "breaking" the functionality of the system. It may just be a little permissions manipulation to resolve the issue.

Steve

0 Kudos
VmwareTSE
Contributor
Contributor

I did some more research on this issue with the customer yesterday. It seems I may have misunderstood the problem. The issues seems to be that when the customer installs say Update 3, he uses a script that keeps samba, pegasus, bind, etc from installing with Update 3. The issue is that then Update 3 isn't showing as installed in Update Manager or with Esxupdate -l query. I guess this causes it to show up on the security scans. Which I would assume could be written off as a false positive.

0 Kudos