#CyberAwarenessMonth: Enable Lockdown Mode

October 06, 2021

(It’s October so that means it’s #CyberAwarenessMonth! We should all be working to improve our security posture throughout the rest of the year, but October is a good time to talk about it collectively. We’ll be publishing a post every weekday with something actionable you can do RIGHT NOW to help make your security better.)

What is “Lockdown Mode” and why should we care?

We learned yesterday that SSH on ESXi is meant as a troubleshooting and support interface and is best left disabled and stopped. Now that we’ve done that, we can easily go a step further to ensuring that the only access to ESXi is through vCenter Server. When ESXi is attached to vCenter Server, most organizations intend to do management of the hosts through the vSphere Client. To help enforce this, there is a feature called “Lockdown Mode” which prevents logins to the host itself. Lockdown mode has three settings: disabled, normal, and strict.

Disabled: Anything goes. vSphere Admins can manage ESXi through the host client (the web interface on port 443/tcp), SSH if it is enabled, ESXi Shell if it is enabled, the DCUI (Direct Console User Interface – the yellow screen on the console of the host), or vCenter Server. This is the default.

Normal: vSphere Admins can manage ESXi using the DCUI or through vCenter Server. Attempts to log into the host client (the ESXi web interface), SSH, or the ESXi Shell are denied. This is our recommended setting for most environments.

2021-10-05 22 09 36-Log in - VMware ESXi — Mozilla Firefox

Strict: vSphere Admins can manage ESXi using vCenter Server, and only vCenter Server. Attempts to log into ESXi in any other way are denied:

2021-10-05 22 10 34-ESX-1.7 - VMware Remote Console 0

Is there a way to allow certain users in, despite Lockdown Mode?

Yes – there is an “Exception Users” list that allows vSphere Admins to specify accounts that can still log in (the old DCUI.Access advanced parameter is deprecated). By default this list is empty, so enabling Lockdown Mode will block all user access.

Be careful here – adding users to the Exception list may defeat the purpose of using Lockdown Mode and give attackers a way in.

What happens if vCenter Server is down and I need to log into ESXi to restart it?

There is a common system design where vCenter Server runs inside the vSphere cluster that it manages. If something has happened to the cluster (power outage, etc.) you may need to log into the ESXi host client to start vCenter Server again.

In Normal mode that isn’t a problem, you can log into the DCUI/console, disable lockdown mode, then do whatever you need to do.

Strict mode is more… strict. All access to the host, from the network or the console, is denied, unless you’ve added an Exception User.

If you’ve added the ‘root’ account (or another) to the Exception Users list you will be able to use that account to log into the host client, disable Lockdown Mode, and then do what you need to do. If you have not added an Exception User then you will have to restore connectivity to the original vCenter Server.

This sounds complicated. What do you recommend?

It is complicated! Here’s where you have to start thinking like both your attackers and yourself during an emergency. Tricky!

It comes down to what you are protecting against – network- or console-based attacks – and where your vCenter Server is running.

A great starting point is normal Lockdown Mode with no Exception Users. This offers additional protection but still has flexibility in case of problems. In this configuration, network access is blocked but the DCUI is available. If something happens you can log into the console/DCUI to make changes and restore service.

If your vCenter Server is hosted inside the cluster it manages then we recommend normal Lockdown Mode with no Exception Users for the hosts that might have vCenter Server running on them. This way you can get into the hosts to diagnose vCenter Server if there’s a problem, or repair networking on the hosts via the DCUI if something is amiss.

If you are primarily concerned about unauthorized network access, we don’t suggest adding Exception Users. If you do, ensure their password is well-protected and rotated periodically. You can avoid this complexity by not having Exception Users, though.

Edge deployments are an interesting case, where the hosts might be located in places where there may not be physical security on either the console or the network connections. An attacker could walk up with a keyboard & monitor, or attach themselves to the network, in order to attempt access. In these cases strict Lockdown Mode with no Exception Users may be appealing if vCenter Server is running somewhere else. If vCenter Server is down or unreachable then it will need to be reconnected in order to gain access to the hosts again.

There may also be other ways to disable console access, such as in the system firmware, or through a hardware management controller like an iLO or iDRAC, that can help here, too.

Last, if there is the possibility that you will need to change the network settings in order to gain access to ESXi again during an incident then you will need the DCUI to do that, and should not disable it.

How do I set this using PowerCLI?

To set normal Lockdown Mode with no Exception Users on a lot of hosts at once (BE CAREFUL!) you can use:

$Hosts = Get-VMHost
foreach ($ESXi in $Hosts) {
  $view = (Get-VMHost $ESXi | Get-View)
  $accessmanager = (Get-View $view.ConfigManager.HostAccessManager)
  $accessmanager.ChangeLockdownMode("lockdownNormal")
  $accessmanager.UpdateLockdownExceptions($NULL)
}

To add an Exception User you can change “$NULL” to “root” or a list of users.

To enter strict Lockdown Mode you can use “lockdownStrict” instead.

Come Back Tomorrow For More

This is the third installment of our posts for Cybersecurity Awareness Month. Other posts are at:

As always, you can find good security guidance from VMware itself in the form of the vSphere Security Configuration Guide. It gets updated following vSphere releases so check back to make sure you’re using the latest version.

 

Filter Tags

Security Cloud Foundation Cloud Foundation 3.9 Cloud Foundation 4 Cloud Foundation 4.2 Cloud Foundation 4.2.1 Cloud Foundation 4.3 Cloud Foundation 4.3.1 ESXi ESXi 6.5 ESXi 6.7 ESXi 7 vCenter Server vCenter Server 6.5 vCenter Server 6.7 vCenter Server 7 vSphere vSphere 6.5 vSphere 6.7 vSphere 7 Blog