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.

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):

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:

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”

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

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:

with:

Restart the sshd service:

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:

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:

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:

with:

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…”

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.

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:

For example:

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:

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:

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

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

Thanks for reading,
mike