The official vSphere Security Guide makes a number of recommendations around best practices for virtual machine security. There are also the vSphere hardening guides, which can be found here.

Installing Antivirus Software

It is recommended that, where required, antivirus is installed within the virtual machines guest operating systems. For virtual machines that have AV installed it is recommended that scheduled scans are staggered in order to prevent performance issues that can occur when a large number of VMs on a host are scanning at the same time.

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:

Be aware that 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 By default the VM can send only 1MB of these messages, however this can be changed. If this was un-restricted then it could be possible for an attacker to write software to send data with the aim of causing DoS.

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:

Other things you can do

• Use named accounts for access.
• Avoid using the root and similarly privileged accounts. DO NOT share passwords.
• Protect user accounts with strong passwords.
• Enable SSH and access to shell only when required.
• Enable strict lockdown mode on managed ESXi. Add trusted users to the exception users list so you won’t get locked out of ESXi.

• To connect to managed ESXi, use the vSphere Web client instead of the host client or DCUI.
• Use host profiles for a standardized configuration approach.
• Enable persistent logging.
• Set timeouts on established sessions. This allows a session to expire if an administrator forgets to disconnect.
• Set the Acceptance Level to accept VMware and/or trusted sources only when upgrading ESXi and its components.
• If supported, enable Secure Boot on servers running ESXi to prevent loading of unsigned VIBs.

Securing vCenter Server

If you’re still deciding on whether to deploy vCenter Server, considering choosing the appliance version (vCSA) over the Windows one. There’s less of an attack surface to deal with not to mention that vCSA offers more features out of the box. Regardless, here are some things you could do to harden vCenter Server.

vCenter Server for Windows

• Run vCenter for Windows on a supported operating system, database and hardware. This reduces vCenter Server susceptibility to vulnerabilities and subsequent attacks.
• Patch and update the Windows OS and database software regularly.
• Install antivirus, anti-malware and IDS software.
• Use service accounts instead of user accounts when installing and configuring vCenter and its database services.
• Consider removing the local Windows administrator account from the vCenter Administrators's group. This is done by default in vSphere 6.x.

vCSA

• Properly configure the NTP service so that the clock on the appliance is in sync with an agreed upon standard such as UTC. This makes it easier to conduct auditing and forensic analysis.
• Set the inbuilt firewall to restrict network access only to those components that require it.
• Limit access or disable SSH / shell access altogether.
• Limit access to root and clients such as VAMI.

General

• Revisit the default Password and Lockout policies where applicable.
• Use named accounts and limit the user and sharing of [email protected].
• User privileges should be assigned on a role basis. This does not imply that every vSphere administrator should be assigned the administrator role.
• Revisit global permissions, roles and user assignment.

• Protect your vSphere inventory by granting users access only to resources they need to use. If vCenter is Active Directory (AD) integrated, use AD accounts and groups for better user management and control.
• Where possible, place the vCenter server in a management network to ensure that management traffic is isolated. However, make sure it can reach ESXi hosts and any other network services such as DNS, AD and the database if external.
• Examine any installed plug-ins ensuring that they are legit.
• Where applicable, use vSphere Update Manager to keep ESXi hosts up to date.

Securing the Network

When it comes to the physical networking tier – physical switches, routers, etc. – the 3 main components offering protection are Firewalls, Segmentation, and Unauthorized Access Prevention. A firewall external to both vCenter and ESXi will minimize the chances of unwanted or unauthorized access to network ports and services. Segmentation creates separate networks or virtual machine zones which allow you to group VMs using metrics such as criticality and function.

This prevents traffic eavesdropping and threats such as ARP spoofing which could lead to MITM and DOS attacks. Unauthorized access prevention is a far more reaching strategy and spans all the components mentioned so far and the steps taken to mitigate unauthorized access. Next in line are virtual switches, both standard and distributed. You can protect virtual traffic against impersonation and interception Layer 2 attacks by configuring a security policy on port groups or ports that control MAC address changes, forged transmits and promiscuous mode.

VMware ESXi Lockdown Mode

In order to make your ESXi hosts more secure, you can put them what’s called Lockdown mode. This post will explain What is VMware ESXi Lockdown Mode, what’s the main benefits and the configuration steps. The configuration is a simple radio button via vSphere web client, but there is also a possibility to activate it through the Direct Console User Interface (DCUI).

ESXi lockdown mode has been introduced in ESXi 5.0 in its simpler version, which has been expanded with ESXi 6.0 and ESXi 6.5. If you put the host into a lockdown mode, you can only connect and manage your hosts and your VMs through vCenter Server. Your connection is denied if you want to connect directly to the host via host client.

In lockdown mode, operations must be performed through vCenter Server by default. It was in vSphere 6.0 first where you can choose either between a normal lockdown mode or strict lockdown mode.

ESXi user accounts which are on a special list called Exception Users, which has administrator’s privileges and those users can also log in to the ESXi shell through DCUI, or Host client (vSphere Client).

Where to Activate VMware ESXi Lockdown Mode?

In order to activate lockdown mode, you can use vSphere Web client or vSphere HTML5 Client: then select your host > Configure > System > Security Profile > Edit.

VMware ESXi Lockdown Mode – two different modes

Let’s have a look what’s the difference between Normal and Strick Lockdown Mode:

• Normal Lockdown Mode – The host can be accessed through vCenter Server. Only users who are on the Exception Users list and have administrator privileges can log in to the Direct Console User Interface. If SSH or the ESXi Shell is enabled, access might be possible.
• Strict Lockdown Mode – The host can only be accessed through vCenter Server. If SSH or the ESXi Shell is enabled, running sessions for accounts in the DCUI.Access advanced option and for Exception User accounts that have administrator privileges remain enabled. All other sessions are terminated.

In addition, when selecting the Strict Lockdown mode, the DCUI service is completely stopped.

What are the Exception Users?

VMware says that those are users that: "A list of user accounts that keep their permissions when the host enters lockdown mode. The accounts are used by third-party solutions and external applications that must continue their function in lockdown mode. To keep lockdown mode uncompromised, you should add only user accounts that are associated with applications."

Where to add an account to the Exception Users list?

You’d have to first create a local ESXi user and then specify this advanced settings on per-host base. So in my case, we created a sample local ESXi user called “disaster” through ESXi host client which is a local ESXi user.

So in order to modify the Exception users list, you’ll have to use the vSphere HTML5 client of vSphere Web Client. To access this setting you select your host > System > Advanced System Settings > within the list find the DCUI.Access > click to add another local ESXi user there. The root user is already present there by default.

The exception users can only perform tasks for which they have privileges for. So even if you create your local user and put him on the Exceptions list, the user won’t be able to connect unless you give him a privilege.

Connect to the ESXi host via ESXi Host Client > Actions > Permissions.

Then click Add User:

The UI will change and here you have the possibility to pick the user you have previously created and then assign a privilege to this user.

VMware has a nice table showing exactly which services or which behaviors are different for Normal and for a Strict Locked mode. This behavior has an influence on the vSphere Web services API, CIM providers, DCUI, ESXi Shell and SSH...

So In which mode I will be able to log in through the DCUI?

Only if the Standard lockdown mode is activated. Not in the Strict mode.

What if vCenter server is unavailable?

Configure Lockdown Mode will be grayed out if vCenter is down or the host is disconnected from vCenter.

Enable/Disable ESXi lockdown mode from DCUI

Note: This applies if a host is in Normal lockdown mode only. Otherwise you would be able to lock yourself out from within the DCUI.

In the server room:

Open server console > Press F2 to Customize System/View Logs > Open Configure Lockdown Mode > Press SPACE to enable or disable lockdown mode.

Press ENTER to save the changes. This is it.

Wrap Up

The host will only be accessible through a local console or vCenter Server. If there are local ESXi users configured, if they have enough privileges to log in locally AND if they are on the Exceptions list of the lockdown more, then they CAN login locally via Host client.

A very powerful mode indeed, which does not influence on the default root user (unless you remove the root user from the Exceptions list).