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.
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
If it was that easy I wouldn't be posting about it. come on. I think we are all a little smarting than that.
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.
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
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
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."
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
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
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?
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
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:
Has version 1.4 been released/published yet? If so, where?
Will the version 1.2 script work on ESXi?
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.
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
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
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
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' >> /etc/host.allow
If your problem is not with VI Center access, then please describe your environment and problem in a bit more detail.
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.
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
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
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.