Home > Blogs > VMware vSphere Blog


Virtual Appliances getting more secure with vSphere 5.5 – Part 3

Making DISA compliance easy

In Parts 1 and 2 we introduced the VMware Hardened Virtual Appliances and went over password management. In Part 3, we’ll focus on a new tool, dodscript.sh, to make configuring your VMware Hardened Virtual Appliances comply with enhanced security requirements like DISA and go over access control and time management.

Dodscript.sh Script

One of the coolest thing that I think many in the Federal space will jump for joy over is the new inclusion of a script for modifying many DISA required settings. These settings are:

  • Modification the password minimum length from 8 to 14 characters.
  • Modification of the default audit logs entries to meet the requirements of the STIG (/etc/audit/audit.rules.STIG) and enables syscall logging.
  • Modification of all default profile scripts to eliminate console messages (mesg n).
  • Modification of the default banner for the appliance welcomescreen and SSH to the Department of Defense approved banner
  • (/opt/vmware/etc/isv/welcometextDoD (or welcomtext.template on VCSA) for the console banner and /etc/issue.DoD for the SSH banner).

An example of the banner modification is called out in this picture.

dodscript4

How cool is that Fed folks??!! My hope is that tools like this will increase adoption of VMware Hardened Virtual Appliances in the Federal space and anywhere else compliance regulations come into play.

Non-DOD banners

The banner files can be modified to support non-DoD customer banners as well! Either edit the above files listed for the console and SSH banners, or create a separate file and use a symbolic link to activate the banner with the following commands (in this example, the new files are welcometext.CUSTOM and issue.CUSTOM):

rm /opt/vmware/etc/isv/welcometext
ln –s /opt/vmware/etc/isv/welcomtext.CUSTOM /opt/vmware/etc/isv/welcometext
rm /etc/issue
ln –s /etc/issue.CUSTOM /etc/issue
For VCSA, replace the /opt/vmware/etc/isv/welcometext.template with the preferred console banner text.

Secure Shell, Administrative Accounts, and Console Access

For remote connections, all hardened appliances include the Secure Shell (SSH). Because many appliances do not include default user accounts, the root account may still be able to directly login via SSH. To meet the compliance standards for non-repudiation, the SSH server on all hardened appliances comes preconfigured with the “AllowGroups wheel” entry to restrict ssh access to the secondary group wheel.

More about wheel groups.

NOTE: For separation of duties, the “AllowGroups wheel” entry can be modified in /etc/ssh/sshd_config to use another group (such as sshd). The wheel group is enabled with the pam_wheel module for su access, so members of the wheel group are allowed to su – to root (password for root is required). Group separation provides a method for users to ssh to the appliance, but not have the ability to su to root. Do not remove or modify other entries in the AllowGroups field to ensure proper appliance functionality. Any change will require a restart of the ssh daemon (# service sshd restart).

Prior to removing root SSH access, create local administrative accounts that can both use ssh and/or are members of the secondary wheel group. To create a local account on the appliance, run the following command as root:

# useradd –g users –G wheel –d /home/username –m –s /bin/bash username

 

Substitute “foo” for the group specified in AllowGroups for ssh access. To add multiple secondary groups, use a comma to separate the groups. Example:” –G wheel,sshd

# passwd username

 

Switch to the user to provide a new password so that password complexity checking is enforced:

# su – username

 

username@hostname:~> passwd

 

NOTE: If the password complexity is met, the change of the password will complete successfully. If the password complexity is not met, it will revert back to the original password, so re-run the command to set a compliant password for the user.

Once login accounts are created to allow SSH remote access and wheel access (su – root), the root account can be removed from both SSH direct login direct login.

NOTE: Do not modify the PermitRootLogin setting on VCOPs appliance vApp.

Prior to disabling direct root access, thoroughly test to ensure that authorized administrators can access ssh (via AllowGroups) and can su to root (via wheel group). To remove direct root login to ssh, modify the /etc/ssh/sshd_config file with the vi editor, and replace the entry:

(#)PermitRootLogin yes

 

with:

PermitRootLogin no

 

Restart the sshd service:

# service sshd restart

 

SSH access should also be restricted with the proper entries to limit access. All VMware Hardened Virtual Appliances include the tcp_wrappers package to allow tcp supported daemons to control the network subnets that can access the libwrapped daemons. By default, the /etc/hosts.allow file contains a generic entry to allow all access to the secure shell:

sshd: ALL : ALLOW

 

It is recommended that this entry be changed for production environments to include only the localhost entries and the management netwotk subnet for secure operations, such as:

sshd: 127.0.0.1 : ALLOW
sshd: [::1] : ALLOW
sshd: 10.0.0. : ALLOW

 

This example will allow all localhost connections and connections made by clients on the 10.0.0.0 subnet. Change the IP subnet to match your subnet settings if necessary.

By default, the hardened appliances allow direct login to root via the console. Once administrative accounts have been created for non-repudiation and tested for wheel access (su – root), direct root logins can be disabled by editing the /etc/securetty file as root and replacing the entry:

tty1

 

with:

console

 

Time Sourcing and Synchronization

All hardened appliances include at least two mechanisms for time synchronization: vmtools and the ntp service. It is recommended that virtual appliances use ntp to synchronize for time sensitive environments.

NOTE: The hardened vCenter Server Appliance allows time to be configured with the VAMI user interface. Please refer to the vCenter Server Appliance administration guide on how to configure time services.

VMtools: Time sourcing with vmtools uses the time of the ESXi host for synchronization. To verify vmtools time synchronization, log into the vCenter server web client (https://ip_of_vcenter_server:9443). Under vCenter, navigate to the virtual machine, right click the targeted VM, and select “Edit Settings…”

webclient5

Select the “VM Options” tab, then click on the “VMware Tools” drop down menu to expose the “Time” field. If the “Synchronize guest time with host” box is checked, then the appliance is using vmtools. Uncheck the box if planning to use ntp for time synchronization.

vm option7

 

NTP: Time sourcing with ntp leverages the ntp client in the appliance to synchronize time. To configure ntp, first use the above instructions to ensure that vmtools time synchronization is disabled. As root on the appliance, edit the /etc/ntp.conf file to add ntp servers to the list of time sources in the form of:

server ntpservername options

 

 

For example:

server time.nist gov burst iburst

 

Add the number of local and centralized time sources as required for the compliance standard of the organization. For trusted time sourcing, the “key” specification can be leveraged to support key based authentication when listing time sources in the form of:

server time.nist.gov burst iburst key 1

 

Where “1” is the key listed as “1” in /etc/ntp.keys file. For more information on setting up ntp keys, refer to the Linux man page on ntp and key authentication or documentation at ntp.org.

Once the /etc/ntp.conf file is properly configured, start the ntp service as root:

# chkconfig ntp on
# service ntp start

 

To check the status, run the following command as root:

# service ntp status

 

service ntp status8

Pretty cool, eh? To wrap up this series, check out Part 4!

Thanks for reading,
mike

This entry was posted in Security, vSphere and tagged on by .
Mike Foley

About Mike Foley

Mike Foley is a Senior Technical Marketing Manager at VMware. His primary focus is on security of the core platform (vSphere). He is the current keeper of the vSphere Hardening Guide. His primary goal is to help IT/VI Admins build more secure platforms that stand up to scrutiny from security teams. Previously, Mike was on the evangelist team at RSA where he concentrated on virtualization and cloud security and contributed as a member of the product architect team. Mike has a blog at http://yelof.com and contributes to the VMware vSphere and Security blogs as well. Follow him at @vSphereSecurity on Twitter

6 thoughts on “Virtual Appliances getting more secure with vSphere 5.5 – Part 3

  1. Pingback: Jase's Place » VMware vCSA 5.5 – Ready for Prime-time & the War Fighter

  2. Pingback: Welcome to vSphere-land! » vSphere 5.5 Link-O-Rama

  3. Michael Ellis

    I will have to perform these DISA STIGS on a new VMware environment. Your articles are a big help. How do you get the Dodscript.sh or where is it. I did not see a link in the articles.

  4. Bob Jennings

    We recently upgrade from 5.1 to 5.5.. I do not see the dodscript.sh in the /etc folder

    Where can I download this script or find it?

    Thanks

Comments are closed.