Close

7th September 2017

Objective 1.2 – Secure ESXi and vCenter Server

Next in the series of post that will run through the objectives of the VCP6.5-DCV exam is Objective 1.2 – Secure ESXi and vCenter Server.

VCP6.5 Certification Blueprint

Objective 1.2 – Secure ESXi and vCenter Server

Configure Encrypted vMotion

Starting with vSphere 6.5, vSphere vMotion always uses encryption when migrating encrypted virtual machines. For virtual machines that are not encrypted, you can select one of the encrypted vSphere vMotion options.

Encrypted vSphere vMotion secures confidentiality integrity, and authenticity of data that is transferred with vSphere vMotion. Encrypted vSphere vMotion supports all variants of vSphere vMotion for unencrypted virtual machines, including migration across vCenter Server systems. Migration across vCenter Server systems is not supported for encrypted virtual machines.

For encrypted disks, the data is transmitted encrypted. For disks that are not encrypted, Storage vMotion encryption is not supported.

For virtual machines that are encrypted, migration with vSphere vMotion always uses encrypted vSphere vMotion. You cannot turn off encrypted vSphere vMotion for encrypted virtual machines.

For virtual machines that are not encrypted, you can set encrypted vSphere vMotion to one of the following states.

  • Right-click the virtual machine and select Edit Settings.
  • Select VM Options.
  • Click Encryption, and select an option from the Encrypted VMotion drop-down menu.

The default is Opportunistic.

Disabled – Do not use encrypted vSphere vMotion.

Opportunistic – Use encrypted vSphere vMotion if source and destination hosts support it. Only ESXi versions 6.5 and later use encrypted vSphere vMotion.

Required – Allow only encrypted vSphere vMotion. If the source or destination host does not support encrypted vSphere vMotion, migration with vSphere vMotion is not allowed.

When you encrypt a virtual machine, the virtual machine keeps a record of the current encrypted vSphere vMotion setting If you later disable encryption for the virtual machine, the encrypted vMotion setting remains at Required until you change the setting explicitly. You can change the settings using Edit Settings.

Describe Secure Boot

Secure boot is part of the UEFI firmware standard. With secure boot enabled, a machine refuses to load any UEFI driver or app unless the operating system bootloader is cryptographically signed. Starting with vSphere 6.5, ESXi supports secure boot if it is enabled in the hardware.

Harden ESXi hosts

To protect an ESXi host against unauthorised intrusion and misuse, VMware imposes constraints on several parameters, settings, and activities. You can loosen the constraints to meet your configuration needs. If you do, make sure that you are working in a trusted environment and take other security measures.

Built-In Security Features

Risks to the hosts are mitigated out of the box as follows:

  • ESXi Shell and SSH are disabled by default.
  • Only a limited number of firewall ports are open by default. You can explicitly open additional firewall ports that are associated with specific services.
  • ESXi runs only services that are essential to managing its functions. The distribution is limited to the features required to run ESXi.
  • By default, all ports that are not required for management access to the host are closed. Open ports if you need additional services.
  • By default, weak ciphers are disabled and communications from clients are secured by SSL. The exact algorithms used for securing the channel depend on the SSL handshake. Default certificates created on ESXi use PKCS#1 SHA-256 with RSA encryption as the signature algorithm.
  • A Tomcat Web service is used internally by ESXi to support access by Web clients. The service has been modified to run only functions that a Web client requires for administration and monitoring. As a result, ESXi is not vulnerable to the Tomcat security issues reported in broader use.
  • VMware monitors all security alerts that can affect ESXi security and issues a security patch if needed.
  • Insecure services such as FTP and Telnet are not installed, and the ports for these services are closed by default. Because more secure services such as SSH and SFTP are easily available, avoid using these insecure services and use their safer alternatives. For example, use Telnet with SSL to access virtual serial ports if SSH is unavailable and you must use Telnet.
  • If you must use insecure services and have implemented sufficient protection for the host, you can explicitly open ports to support them.
  • Consider using UEFI Secure Boot for your ESXi system. See UEFI Secure Boot for ESXi Hosts.

Additional Security Measures

Consider the following recommendations when evaluating host security and administration.

  • Limit access.
  • If you enable access to the Direct Console User Interface (DCUI) the ESXi Shell, or SSH, enforce strict access security policies.
  • The ESXi Shell has privileged access to certain parts of the host. Provide only trusted users with ESXi Shell login access.
  • Do not access managed hosts directly.
  • Use the vSphere Web Client to administer ESXi hosts that are managed by a vCenter Server. Do not access managed hosts directly with the VMware Host Client, and do not change managed hosts from the DCUI.
  • If you manage hosts with a scripting interface or API, do not target the host directly. Instead, target the vCenter Server system that manages the host and specify the host name.
  • Use DCUI only for troubleshooting.
  • Access the host from the DCUI or the ESXi Shell as the root user only for troubleshooting. Use one of the GUI clients, or one of the VMware CLIs or APIs to administer your ESXi hosts. If you use the ESXi Shell or SSH, limit the accounts that have access and set timeouts.
  • Use only VMware sources to upgrade ESXi components.

The host runs several third-party packages to support management interfaces or tasks that you must perform. VMware only supports upgrades to these packages that come from a VMware source. If you use a download or patch from another source, you might compromise management interface security or functions. Check third-party vendor sites and the VMware knowledge base for security alerts.

For more details look to https://www.vmware.com/security/hardening-guides.html

Enable/Configure/Disable services in the ESXi firewall

You can configure incoming and outgoing firewall connections for a service or a management agent from the vSphere Web Client or at the command line.

Note: If different services have overlapping port rules, enabling one service might implicitly enable other services. You can specify which IP addresses can access each service on the host to avoid this problem.

  • Browse to the host in the vSphere Web Client inventory.
  • Click Configure.
  • Under System, click Security Profile.
  • The vSphere Web Client displays a list of active incoming and outgoing connections with the corresponding firewall ports.
  • In the Firewall section, click Edit.
  • The display shows firewall rule sets, which include the name of the rule and the associated information.
  • Select the rule sets to enable, or deselect the rule sets to disable.
  • For some services, you can manage service details.
  • Use the Start, Stop, or Restart buttons to change the status of a service temporarily.
  • Change the Startup Policy to have the service start with the host or with port usage.
  • For some services, you can explicitly specify IP addresses from which connections are allowed.
  • Click OK

Change default account access

The following roles are predefined

Read Only  – Allows a user to view objects associated with the ESXi host but not to make any changes to objects.

Administrator – Administrator role.

No Access – No access. This role is the default role. You can override the default role.

You can manage local users and groups and add local custom roles to an ESXi host using a VMware Host Client connected directly to the ESXi host. Starting with vSphere 6.0, you can use ESXCLI account management commands for managing ESXi local user accounts. You can use ESXCLI permission management commands for setting or removing permissions on both Active Directory accounts (users and groups) and on ESXi local accounts (users only).

Note If you define a user for the ESXi host by connecting to the host directly, and a user with the same name also exists in vCenter Server, those users are different If you assign a role to the ESXi user, the vCenter Server user is not assigned the same role.

root User Privileges

By default each ESXi host has a single root user account with the Administrator role. That root user account can be used for local administration and to connect the host to vCenter Server.

This common root account can make it easier to break into an ESXi host because the name is already known. Having a common root account also makes it harder to match actions to users.

For better auditing, create individual accounts with Administrator privileges. Set a highly complex password for the root account and limit the use of the root account, for example, for use when adding a host to vCenter Server. Do not remove the root account.

Best practice is to ensure that any account with the Administrator role on an ESXi host is assigned to a specific user with a named account. Use ESXi Active Directory capabilities, which allow you to manage Active Directory credentials.

You can remove the access privileges for the root user. However, you must first create another permission at the root level that has a different user assigned to the Administrator role.

vpxuser Privileges

vCenter Server uses vpxuser privileges when managing activities for the host. vCenter Server has Administrator privileges on the host that it manages. For example, vCenter Server can move virtual machines to and from hosts and perform configuration changes needed to support virtual machines.

The vCenter Server administrator can perform most of the same tasks on the host as the root user and also schedule tasks, work with templates, and so forth. However, the vCenter Server administrator cannot directly create, delete, or edit local users and groups for hosts. These tasks can only be performed by a user with Administrator permissions directly on each host.

You cannot manage the vpxuser using Active Directory.

Do not change vpxuser in any way. Do not change its password. Do not change its permissions. If you do so, you might experience problems when working with hosts through vCenter Server.

dcui User Privileges

The dcui user runs on hosts and acts with Administrator rights. This user’s primary purpose is to configure hosts for lockdown mode from the Direct Console User Interface (DCUI).

This user acts as an agent for the direct console and cannot be modified or used by interactive users

Add an ESXi Host to a directory service

You can configure a host to use a directory service such as Active Directory to manage users and groups. When you add an ESXi host to Active Directory, the DOMAIN group ESX Admins is assigned full administrative access to the host if it exists.

If a host is provisioned with Auto Deploy, Active Directory credentials cannot be stored on the hosts. You can use the vSphere Authentication Proxy to join the host to an Active Directory domain. Because a trust chain exists between the vSphere Authentication Proxy and the host, the Authentication Proxy can join the host to the Active Directory domain.

  • Synchronize the time between ESXi and the directory service system using NTP.
    • Start the VMware Host Client, and connect to the ESXi host.
    • Click Configure.
    • Under System, click Time Configuration, and click Edit.
    • Select Use Network Time Protocol (Enable NTP client).
    • In the Add NTP Server text box, enter the IP address or fully qualified domain name of one or more NTP server to synchronize with.
    • Set the startup policy and service status.
    • Click OK.
  • Ensure that the DNS servers that you configured for the host can resolve the host names for the Active Directory controllers.
    • Browse to the host in the vSphere Web Client object navigator.
    • Click Configure..
    • Under Networking, click TCP/IP configuration.
    • Under TCP/IP Stack: Default, click DNS and verify that the host name and DNS server information for the host are correct.
  • Browse to the host in the vSphere Web Client inventory.
  • Click Configure.
  • Under System, select Authentication Services.
  • Click Join Domain.
  • Enter a domain.
  • Use the form name.tld or name.tld/container/path.
  • Enter the user name and password of a directory service user who has permissions to join the host to
  • the domain, and click OK.
  • If you intend to use an authentication proxy, enter the proxy server IP address.
  • Click OK to close the Directory Services Configuration dialog box.

Apply permissions to ESXi Hosts using Host Profiles

Host profiles allow you to set up standard configurations for your ESXi hosts and automate compliance to these configuration settings Host profiles allow you to control many aspects of host configuration including memory, storage, networking, and so on.

You can configure host profiles for a reference host from the vSphere Web Client and apply the host profile to all hosts that share the characteristics of the reference host. You can also use host profiles to monitor hosts for host configuration changes. You can attach the host profile to a cluster to apply it to all hosts in the cluster.

  • Set up the reference host to specification and create a host profile
  • attach the profile to a host or cluster.
  • Apply the host profile of the reference host to other hosts or clusters.

Enable Lockdown Mode

To increase the security of your ESXi hosts, you can put them in lockdown mode. In lockdown mode, operations must be performed through vCenter Server by default.

Starting with vSphere 6.0, you can select normal lockdown mode or strict lockdown mode, which offer different degrees of lockdown. vSphere 6.0 also introduces the Exception User list. Exception users do not lose their privileges when the host enters lockdown mode. Use the Exception User list to add the accounts of third-party solutions and external applications that need to access the host directly when the host is in lockdown mode

Normal Lockdown Mode

In normal lockdown mode the DCUI service is not stopped. If the connection to the vCenter Server system 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 the following 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.

Enable Lockdown Mode Using the vSphere Web Client

Enable lockdown mode to require that all configuration changes go through vCenter Server. vSphere 6.0 and later supports normal lockdown mode and strict lockdown mode.

To completely disallow all direct access to a host, you can select strict lockdown mode. Strict lockdown mode makes it impossible to access a host if the vCenter Server is unavailable and SSH and the ESXi Shell are disabled.

  • Browse to the host in the vSphere Web Client inventory.
  • Click Configure.
  • Under System, select Security Profile.
  • In the Lockdown Mode panel, click Edit.
  • Click Lockdown Mode and select one of the lockdown mode options.

Normal – 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 are enabled, access might be possible.

Strict  -The host can only be accessed through vCenter Server. If SSH or the ESXi Shell are 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.

  • Click OK.

Control access to hosts (DCUI/Shell/SSH/MOB)

Access to the DCUI/Shell and SSH can be controlled via lockdown mode. The MOB is the managed object browser (MOB) and provides a way to explore the VMkernel object model. However, Hackers can use this interface to perform malicious configuration changes or actions because it is possible to change the host configuration by using the MOB. Use the MOB only for debugging, and ensure that it is disabled in production systems.

Starting with vSphere 6.0, the MOB is disabled by default. However, for certain tasks, for example when extracting the old certificate from a system, you have to use the MOB. You can enable and disable the MOB as follows.

  • Select the host in the vSphere Web Client and go to Advanced System Settings.
  • Check the value of Config.HostAgent.plugins.solo.enableMob, and change it as appropriate.

Do not use vim-cmd from the ESXi Shell.

Harden vCenter Server

Page 97 through 110 of the Security Guide covers this information.

https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-security-guide.pdf

Control datastore browser access

Datastore access is granted via the Datastore.Browse datastore privilege.

Assign the Datastore.Browse datastore privilege only to users or groups who really need those privileges.Users with the privilege can view, upload, or download files on datastores associated with the vSphere deployment through the Web browser or the vSphere Web Client.

Create/Manage vCenter Server Security Certificates

When ESXi and vCenter Server communicate, they use TLS/SSL for almost all management traffic In vSphere 5.5 and earlier, the TLS/SSL endpoints are secured only by a combination of user name, password, and thumbprint.

In vSphere 6.0 and later, vCenter Server supports the following certificate modes for ESXi hosts.

VMware Certificate Authority (default)

Use this mode if VMCA provisions all ESXi hosts, either as the top-level CA or as an intermediate CA. By default, VMCA provisions ESXi hosts with certificates. In this mode, you can refresh and renew certificates from the vSphere Web Client.

Custom Certificate Authority

Use this mode if you want to use only custom certificates that are signed by a third-party or enterprise CA. In this mode, you are responsible for managing the certificates You cannot refresh and renew certificates from the vSphere Web Client.

Unless you change the certificate mode to Custom Certificate Authority, VMCA might replace custom certificates for example, when you select Renew in the vSphere Web Client.

Thumbprint Mode

vSphere 5.5 used thumbprint mode, and this mode is still available as a fallback option for vSphere 6.x. In this mode, vCenter Server checks that the certificate is formatted correctly, but does not check the validity of the certificate even expired certificates are accepted.

Do not use this mode unless you encounter problems that you cannot resolve with one of the other two modes. Some vCenter 6.x and later services might not work correctly in thumbprint mode.

Control MOB access

Starting with vSphere 6.0, the MOB is disabled by default. However, for certain tasks, for example when extracting the old certificate from a system, you have to use the MOB. You can enable and disable the MOB as follows.

  • Select the host in the vSphere Web Client and go to Advanced System Settings.
  • Check the value of Config.HostAgent.plugins.solo.enableMob, and change it as appropriate.

Do not use vim-cmd from the ESXi Shell.

Change default account access

Refer to earlier section

Restrict administrative privileges

Not all administrator users must have the Administrator role. Instead, create a custom role with the appropriate set of privileges and assign it to other administrators.

Users with the vCenter Server Administrator role have privileges on all objects in the hierarchy. For example, by default the Administrator role allows users to interact with files and programs inside a virtual machine’s guest operating system. Assigning that role to too many users can lessen virtual machine data confidentiality availability, or integrity. Create a role that gives the administrators the privileges they need, but remove some of the virtual machine management privileges.

Follow the principle of least privilege

Understand the implications of securing a vSphere environment

The process of securing any system is finding the balance between security and manageability.  Making any changes to the security of the vSphere environment might have knock on impacts to the manageability of the environment.  So there for map out any changes prior to implementation, identify the risk and the mitigation keeping manageability in mind also.