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:
Alternatively the permissions can be granted directly on the host itself, to do this log onto the host using the c# client:
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:
You can also enable SSH using the DCUI by browsing to the TroubleShooting Options:
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:
A further way to increase security is to only allow connections from defined IP addresses by editing the SSH Server service firewall rule:
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
On the DCUI select “Configure Lockdown Mode”
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:
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:
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:
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’:
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:
You can also disable logging entirely for a virtual machine:
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.
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:
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:
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.
The shell.log file lists all the commands entered into the ESXi shell. For example:
This is useful in tracking what has been run on a host, and from a security perspective is useful if unauthorized access is suspected.
The esxupdate.log file logs activity related to ESXi patching and upgrades, an excerpt is shown below:
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:
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 ‘firstname.lastname@example.org’ 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: