Objective 8.3 Topics:
- Enable and configure ESXi Lockdown mode (Strict / Normal)
- Configure a user on the Lockdown Mode Exception Users list
- Customize SSH settings for increased security
- Enable strong passwords and configure password policies
- Configure vSphere hardening of virtual machines according to a deployment plan
Enable and configure ESXi Lockdown mode (Strict / Normal)
Starting with vSphere 6.0, you can select normal Lockdown mode or strict Lockdown mode, which offer different degrees of lockdown.
Normal Lockdown Mode
In normal lockdown mode the DCUI service is not stopped. If the connection to the vCenter Server is lost and access through the vSphere Web Client is no longer available, privileged accounts can log in to the ESXi host’s Direct Console Interface and exit lockdown mode. Only these accounts can access the Direct Console User Interface:
- Accounts in the Exception User list for lockdown mode who have administrative privileges on the host. The Exception Users list is meant for service accounts that perform very specific tasks. Adding ESXi administrators to this list defeats the purpose of lockdown mode.
- Users defined in the DCUI.Access advanced option for the host. This option is for emergency access to the Direct Console Interface in case the connection to vCenter Server is lost. These users do not require administrative privileges on the host.
Strict Lockdown Mode
In strict lockdown mode the DCUI service is stopped. If the connection to vCenter Server is lost and the vSphere Web Client is no longer available, the ESXi host becomes unavailable unless the ESXi Shell and SSH services are enabled and Exception Users are defined. If you cannot restore the connection to the vCenter Server system, you have to reinstall the host.
Enable/Disable Lockdown mode from the DCUI:
- Log into the host directly.
- F2, and press enter on the ‘Configure Lockdown Mode‘.
Note that the DCUI doesn’t offer the option of Normal or Strict. When you enable via the DCUI you will get Normal mode.
Enable/Disable Lockdown mode from the vSphere Web Client:
- Select the host you want to lockdown. Click manage then settings.
- Select Security Profile.
3. Scroll down until you see Lockdown Mode and click Edit.
Configure a User on the Lockdown Mode Exception Users List
Exception users are host local users or Active Directory users with privileges defined locally for the ESXi host. They are not members of an Active Directory group and are not vCenter Server users. These users are allowed to perform operations on the host based on their privileges. That means, for example, that a read-only user cannot disable lockdown mode on a host.
- Browse to a host in vCenter
- Click on Manage then Settings
- System, click Security Profile
- Scroll down until you see the Lockdown mode section, click Edit
- Click the ( + ) button to add your users to the exception list.
Add Users To The DCUI.Access Advanced Option
Users in the DCUI.Access list can change lockdown mode settings regardless of their privileges. However, caution needs to be taken because this can directly impact the security posture of the host(s). Keep in mind, exception users can only perform tasks for which they have privileges for.
- Browse to a host in vCenter
- Click on Manage then Settings
- Click Advanced System Settings and select DCUI.Acess
- Click on Edit and enter usernames.
By default the root user is included. Consider removing the root user and adding named users for better tracability.
Customize SSH Settings for Increased Security
The ESXi Shell provides access to maintenance commands and other configuration options. It can be used for tasks that can’t be done through the Web Client or other remote management tools. ESXi Shell is primary intended for use in break-fix scenarios.
We can use the vSphere Client to enable local and remote shell access.
- Select a host in vCenter
- Click on Manage, then Settings, then Security Profile
- Scroll down tot the Services section and click Edit
The 3 services we want to look at are:
- Direct Console UI
- ESXi Shell
On each one of these services you can enable or disable. And set the start up method.
Other settings we can change are:
Enabling SSH or local shell through the DCUI.
Go to the console of the host. Input F2, enter username/password. Select Troubleshooting Options and hit Enter on each service you want to enable/disable.
Configuring the Timeout For the ESXi Shell.
By default the timeout setting for the ESXi shell is set to disabled. We can change that by going to the Troubleshooting Mode options in the DCUI and selecting Modify DCUI idle timeout and enter the timeout in minutes. Having a timeout value will increase the security posture of the ESXi host(s).
This also can be done by the vSphere Client.
Enable Strong Passwords and Configure Password Policies
ESXi enforces password requirements for direct access from the 3 services we just talked about. The Direct Console User Interface (DCUI), the ESXi Shell, SSH and the vSphere Client. When passwords are created they need to include certain complexity requirements from four character classes.
- Lowercase letters
- Uppercase letters
- Special Characters
- Passwords must contain characters from at least character classes
- Passwords containing characters from three classes must be at least seven characters long.
- Passwords containing characters from all four classes must be at least seven characters long.
The default restriction on passwords or pass phrases can be changed by using the Security.PasswordQualityControl advanced option for your ESXi host.
By default, this option is set as follows:
You can change the default, for example, to require a minimum of 12 characters and a minimum number of three words, as follows:
Example: retry=3 min=disabled,disabled,12,7,7 passphrase=3
Additional settings can be set as well. Such as:
Account lockout Failures – Security.AccountLockFailures – Maximum number of failed login attempts before the account is locked.
Account Unlock Timeout – Security.AccountUnlockTime – Number of seconds that the user account is locked out.
Configure vSphere Hardening of Virtual Machines According to a Deployment Plan
Virtual machines should be patched from the OS level down to the VM layer the same as physical machines. Additionally, it is good practice to disable unneccessary functionality such as limiting the use of the VM console, hardware components and generally following VMware’s best practices guides for virtual machines.