Objective 6.1 – Manage authentication and end-user security

Add/Edit Remove users/groups on an ESXi host

Users can be granted permissions to an ESXi host in a few different places. Firstly they can be granted permissions from the vCenter server:

sec1

Alternatively the permissions can be granted directly on the host itself, to do this log onto the host using the c# client:

sec2

Customize SSH settings for increased security

SSH is disabled by default on an ESXi host. In order to connect to a host via SSH you first need to enable the SSH service. In the vSphere client you can do so by selecting the host you want to enable SSH on > Manage > Settings > Security Profile > Services > Select SSH then select Edit:

 

sec3

You can also enable SSH using the DCUI by browsing to the TroubleShooting Options:

sec4

 

You should enable SSH only when strictly necessary for troubleshooting purposes. Leaving SSH open creates a security vulnerability, and consumes host resources.

ESXi Shell Timeouts – The shell timeout setting allows you to specify how long an inactive session is left open. By default the value is zero, meaning that the session will remain open even if it is inactive. If you change the value to 15 then if the timeout period passes, then the user would have to authenticate again. These values can be set either through the DCUI or as an advanced option on each host, as shown in the screenshots below:

sec5

sec6

You can also set this options using the CLI:

sec7

A further way to increase security is to only allow connections from defined IP addresses by editing the SSH Server service firewall rule:

sec8

Enable ESXi lockdown mode

This can be done on the host via the vCenter or on the DCUI as below:

Select the host you want to put into lockdown mode > Manage > Settings > Security Profile > Lockdown Mode > Edit

sec9

On the DCUI select “Configure Lockdown Mode”

sec10

Enable strong passwords and configure password policies

ESXi host password length and complexity rules are documented on page 90 of the vSphere Security Guide. As stated there, ESXi uses the pam_passwdqc.so plug-in, by default,  to set the password policy/rules. Out of the box, ESXi doesn’t place any complexity restrictions on the root account’s password. However, non-root user accounts will be subject to the default rules defined in pam_passwdqc.so. As described in the security guide, in order to configure password complexity you can change the following parameters:

  • retry is the number of times a user is prompted for a new password if the password candidate is not sufficiently strong.
  • N0 is the number of characters required for a password that uses characters from only one character class. For example, the password contains only lowercase letters.
  • N1 is the number of characters required for a password that uses characters from two character classes.
  • N2 is used for passphrases. ESXi requires three words for a passphrase. Each word in the passphrase must be 8-40 characters long.
  • N3 is the number of characters required for a password that uses characters from three character classes.
  • N4 is the number of characters required for a password that uses characters from all four character classes.
  • match is the number of characters allowed in a string that is reused from the old password. If the pam_passwdqc.so plug-in finds a reused string of this length or longer, it disqualifies the string from the strength test and uses only the remaining characters.

Setting any of  the parameters about to -1 directs the pam_passwdqc.so plug-in to ignore the requirement, whilst setting any of the parameters to disabled will disqualify any passwords that include that characteristic. In order to configure the plugin we need to edit the host’s passwd file, which is found in /etc/pam.d/. An example of the content of the passwd file is shown below:

sec11

It is the ‘password requisite’ line that we are interested in:

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

The line is constructed as follows:

password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4

In the example above we can determine that:

  • retry=3: A user is allowed 3 attempts to enter a sufficient password
  • N0=8: Passwords containing characters from one character class must be at least 8 characters long.
  • N1=8: Passwords containing characters from two character classes must be at least 8 characters long.
  • N2=8: Passphrases must contain words that are each at least 8 characters long.
  • N3=7: Passwords containing characters from three character classes must be at least 7 characters long.
  • N4=6: Passwords containing characters from all four character classes must be at least 6 characters long.

Identify methods for hardening virtual machines

There is a laod of documentation on heardening, so a good place to start is the VMware Security Hardening Guides: here

Limiting Exposure of Sensitive Data Copied to the Clipboard

By default, copy and paste operations are disabled. If copy and paste functionality is enabled, you are able to copy and paste between the machine running the console and the guest operating system.

This functionality is controlled with two advanced settings, on a per-virtual machine basis:

sec12

These advance settings can only be changed when the virtual machine is powered off.

Removing Unnecessary Hardware Devices

It is recommended that any unused virtual hardware is removed from virtual machines, as unused hardware could be used to breach virtual machine security. For example, a CD-ROM drive attached to a VM may be used to access information on the mounted ISO/attached drive.

As an alternative to removing a device, you could prevent a user from connecting or disconnecting it through the guest OS by editing the virtual machine’s VMX file, entering the following line:

device_name.allowGuestConnectionControl = "false"

Limiting Guest Operating System Writes to Host Memory

The guest operating system processes send informational messages to the host using VMware Tools. If the amount of data the host stored as a result of these messages was unlimited, an unrestricted data flow would provide an opportunity for an attacker to stage a denial-of-service (DoS) attack. By default the VM can send only 1MB of these messages, however this can be changed.

The setting to configure this behavior is:

tools.setInfo.sizeLimit

It is configured on a per-VM basis. You can increase the guest operating system variable memory limit if large amounts of custom information are being stored in the configuration file. You can also prevent guests from writing any name-value pairs to the configuration file. To do so, use the following setting, and set it to ‘true’:

isolation.tools.setinfo.disable

Configuring Logging Levels for the Guest Operating System

Virtual machines write to a log file on the datastore where the VM is located. An attacker could cause this log file to grow, with the intention of causing a denial of service, by generating events that will be committed to the log file. In order to prevent the possibility of this happening you can configure logging settings for a virtual machine to limit the total size and number of logs that are created. A new log file is created when the host is rebooted – so these files can grow to be quite large. VMware recommend that 10 log files should be retained, each with a maximum size of 1ooKB. This is configurable by adding/changing the following lines in the virtual machine’s VMX file:

log.rotateSize=maximum_size
log.keepOld=number_of_files_to_keep

You can also disable logging entirely for a virtual machine:

sec13

Analyze logs for security-related messages

For security the main ESXi log files to be aware of, along with the hostd and vmkernel logs are:

  •  /var/log/auth.log: ESXi Shell authentication success and failure attempts.
  • /var/log/shell.log: ESXi Shell usage logs, including enable/disable and every command entered.
  • /var/log/esxupdate.log: ESXi patch and update installation logs.

ESXi auth.log

The auth.log file records ESXi shell authentication success and failure attempts, which is useful in terms of security. The example entries below show a successful connection using the root account:

sec14

We can see in the output that this session was over SSH, from 192.168.0.9. The excerpt below shows an attempted, failed, login by the root account:

sec15

You can quickly find failed authentication attempts by running:

# cat /var.log/auth.log | grep failure

This command will display all the ‘failure’ instances found in the log file.

sec16

ESXi shell.log

The shell.log file lists all the commands entered into the ESXi shell. For example:

sec17

This is useful in tracking what has been run on a host, and from a security perspective is useful if unauthorized access is suspected.

ESXi esxupdate.log

The esxupdate.log file logs activity related to ESXi patching and upgrades, an excerpt is shown below:

sec18

This log can be used to see what has been installed on the host, including patches and drivers.

Manage Active Directory integration

You can configure ESXi hosts to use Active Directory, which can then be used to manage users and groups. You can join a host to the domain using an AD account that has the necessary permissions. Other pre-requisites are that DNS should be configured correctly for your hosts, and time synchronisation should be in place for the host(s) and the directory servers.

You can add a host to a domain either by specifying the fully qualified domain name alone, in which case the host’s computer object will be created in the default container in Active Directory, or you can specify the OU.

Joining an ESXi Host to Active Directory

To add a host, navigate to the host > Manage > Settings, then Authentication Services. Click Join Domain:

sec19

 

Once added, a computer object for the host will be created in Active Directory:

 

 

When a host is joined to Active Directory you can assign AD users and groups permissions on the host. For example, on this host I have added ‘james.cruickshank@vcroky.com’ to the host, with administrator permissions:

 

 

The ‘ESX Admins’ Group

By default, when you add an ESXi 5 host to Active Directory, the host will query AD for the existence of a group called ‘ESX Admins’. If this group exists it will be given administrator permissions on the host, by extension granting administrator permissions to all users that are members of the group.

The ESX Admins group is not created automatically. If it doesn’t exist the host will be joined to AD but then accounts/groups will have to be granted permissions manually.

Leaving a Domain

To set the host back so that it will use local authentication only, click the ‘Leave Domain’ button in the ‘Authentication Services’ window. You will be given a warning that all AD permissions will be removed from the host: