Chapter 7. vSphere Security

This chapter covers the following subjects:

•   vSphere Certificates

•   vSphere Permissions

•   ESXi and vCenter Server Security

•   vSphere Network Security

•   Virtual Machine Security

•   Available Add-on Security

This chapter contains information related to VMware 2V0-21.20 exam objectives 1.10, 1.11, 4.10, 4.11, 4.11.1, 4.13, 7.7, 7.8

This chapter covers exam topics related to hardening a vSphere Environment.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should study this entire chapter or move quickly to the “Exam Preparation Tasks” section. Regardless, the authors recommend that you read the entire chapter at least once. Table 7-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

1. You are preparing to import certificates for your vSphere environment. Which of the following is not a requirement?

a. x509 version 3

b. PEM format: PKCS8 and PKCS1

c. Key Usage: Digital Signature, Key Encipherment.

d. Key size: 1024 bits to 16384 bits

2. You are making plans for ESXi host certificates. Which of the following is not a valid certificate mode?

a. VMware Endpoint Certificate Store

b. VMware Certificate Authority

c. Custom Certificate Authority

d. Thumbprint Mode

3. You are preparing to apply permissions in vCenter Server. Which of the following is a system role?

a. Read Only

b. Virtual Machine User

c. Datastore Consumer

d. Content Library Administrator

4. You are configuring permissions in vCenter Server. Which privilege is required for a user to use Storage vMotion to migrate a virtual machine?

a. Resource.Migrate Powered On Virtual Machine

b. Resource.Migrate Powered Off Virtual Machine

c. Resource.Assign Virtual Machine to Resource Pool on the cluster

d. Resource.Assign Virtual Machine to Resource Pool on the VM folder

5. You are hardening you ESXi hosts. Which of the following is true concerning normal lockdown mode?

a. All users with administrator privileges on the host can access the DCUI

b. All users in the Exception Users list can access the DCUI

c. No one can access the DCUI

d. Users identified in the host’s DCUI.Access advanced option can access the DCUI

6. You are creating user accounts the vCenter SSO domain. With default settings, which of the following is a valid password?

a. VMware1!

b. VMworld!

c. VMwareR0cks

d. VMwarerocks!!

7. You are configuring IPsec on your ESXi hosts. Which of the following commands can you use to list the available security associations on an ESXi host?

a. esxcli network ipsec sa list

b. esxcli network ip ipsec sa list

c. esxcli network ip ipsec list

d. esxcli network ip sa list

8. You want to migrate virtual machines across vCenter Instances. Concerning vMotion migration across vCenter Server instances, which of the following statements is true? (pick two)

a. For encrypted vMotion, you can use the vSphere Client

b. For encrypted vMotion, you must use the vSphere APIs.

c. vMotion of encrypted virtual machines is not supported

d. Encrypted vMotion of non-encrypted virtual machines is not supported.

9. You are hardening virtual machines in your vSphere 7 environment. Which of the following options can be set to TRUE because it disables an unexposed feature?

a. tools.guestlib.enableHostInfo

b. tools.setInfo.sizeLimit

c. vmx.log.keepOld

d. isolation.tools.ghi.launchmenu.change

10. You want to use micro-segmentation to protect the applications and data in your vSphere environment. What should you implement?

a. VMware AppDense

b. VMware NSX

c. VMware vRealize Automation

d. VMware vRealize Log Insight

Foundation Topics

vSphere Certificates

This section describes the use of certificates in a vSphere environment.

vSphere Certificates Overview

In vSphere 7.0, you can use the default approach to provision vCenter Server components and ESXi hosts with VMware Certificate Authority (VMCA) certificates. You can also use custom certificates which you store in the VMware Endpoint Certificate Store (VECS). vCenter Server supports custom certificates that are generated and signed from your own enterprise Public Key Infrastructure (PKI). vCenter Server also supports custom certificates that are generated and signed trusted third-party Certificate Authorities (CAs), such as VeriSign or GoDaddy. vSphere uses certificates to do the following.

•   Encrypt communications nodes, such as a vCenter Server and ESXi hosts.

•   Authenticate vSphere services.

•   Perform internal actions such as signing tokens.

Table 7-2 identifies the core identity services in vSphere.

VECS is the local (client-side) repository for certificates, private keys, and other certificate information that can be stored in a keystore. You can choose not to use VMCA as your certificate authority and certificate signer, but you must use VECS to store all vCenter certificates and keys. ESXi certificates are stored locally on each host and not in VECS. The stores included in VECS are described in the vCenter Server Components section in Chapter 8 in Table 8-9.

The VMware Certificate Authority (VMCA), which runs in every vCenter Server Appliance, is vSphere’s internal certificate authority. It provides all the required certificates for vCenter Server and ESXi. VMCA’s default configuration provides the lowest operational overhead for certificate management and immediately secures the solution without any other modification. vSphere provides mechanism to renew expired certificates and to replace specific certificates with your own certificates.

You can replace the VMCA root certificate with a certificate that is signed by an enterprise CA or third-party CA, IN this case, VMCA signs the custom root certificate each time it provisions certificates, making VMCA an intermediate CA, as illustrated in Figure 7-1.

You can replace the existing VMCA-signed certificates with custom certificates, bypassing VMCA and making you responsible for all certificate provisioning and monitoring.

VMware recommends that you replace only the SSL certificate that provides encryption between nodes. VMware does not recommend replacing either solution user certificates or STS certificates. VMware does not recommend using a subordinate CA in place of the VMCA. If you fail to follow these recommendations, you might encounter significant complexity and an increase in your operational risk. VMware recommendations for managing certificates are summarized in Table 7-3.

Certificate Requirements

The following is required for all imported certificates.

•   Key size: 2048 bits to 16384 bits

•   PEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When you add keys to VECS, they are converted to PKCS8.

•   x509 version 3

•   SubjectAltName must contain DNS Name=machine_FQDN

•   CRT format

•   Contains the following Key Usages: Digital Signature, Key Encipherment.

•   Enhanced Key Usage can be either empty or contain Server Authentication.

VMCA does not support the following certificates.

•   Certificates with wildcards.

•   The algorithms md2WithRSAEncryption 1.2.840.113549.1.1.2, md5WithRSAEncryption 1.2.840.113549.1.1.4, and sha1WithRSAEncryption 1.2.840.113549.1.1.5 are not recommended.

•   The algorithm RSASSA-PSS with OID 1.2.840.113549.1.1.10 is not supported.

If you do not generate Certificate Signing Requests (CSRs) using Certificate Manager, ensure that the CSR includes the fields listed in Table 7-4.

If you use VMCA as an intermediate CA, you can use the vSphere Certificate Manager to create the CSR or you can create the CSR manually. When creating the CSR manually, in addition to the previously stated requirements, you should consider the requirements in Table 7-5, which are based on the specific certificate types.

VMCA provisions your environment with certificates that are described in Table 7-6, including machine SSL certificates for secure connections, solution user certificates for service authentication with vCenter Single Sign-On, and ESXi host certificates.

A solution user presents the certificate to vCenter Single Sign-On when it first authenticates, after a reboot, and after a timeout has elapsed. The timeout (Holder-of-Key Timeout) can be set from the vSphere Client and defaults to 2592000 seconds (30 days).

The following solution user certificate stores are included in VECS:

•   Machine: Used by the license server and the logging service.

•   vpxd: Used by the vCenter service (vpxd) to authenticate to vCenter Single Sign-On.

•   vpxd-extension: Used by the Auto Deploy service, inventory service, and other services that are not part of other solution users.

•   vsphere-webclient: Use by the vSphere Client and some additional services such as the performance chart service.

•   wcp: Used by vSphere with Kubernetes.

ESXi Host Certificates

In vSphere 6.0 and later, vCenter Server supports the certificate modes for ESXi hosts that are described in Table 7-7.

You can use the vSphere Client to view expiration data for certificates, whether it is signed by VMCA or a third party. The vCenter Server raises yellow alarms for hosts where certificates expire shortly (less than 8 months) and red alarms where certificates in the Expiration Imminent state (expire in less than 2 months).

ESXi hosts that boot from installation media, have an autogenerated certificate. When a host is added to the vCenter Server system, it is provisioned with a certificate that is signed by VMCA as the root CA.

vSphere Permissions

This section describes the permission model in vSphere.

Authentication and Authorization

vCenter Single Sign-On (SSO) is responsible for authenticating vCenter Server users. The user accounts may be defined directly in the SSO domain or in a supported identity source. vCenter Server uses permissions and roles to provide authorization, which controls what an authenticated user can do. It allows you to assign a permission to an object in the vCenter Server inventory, by specifying which privileges a specific user or group has on that object.

The default SSO domain name is vsphere.local, but you can change it during the domain creation. Initially, only the SSO domain administrator is authorized to log into vCenter Server. By default, the SSO domain administrator is administrator@vsphere.local. You can create additional users in the SSO domain. You can add supported identity sources to SSO, including Active Directory over LDAP, a native Active Directory (Integrated Windows Authentication) domain, or an OpenLDAP directory service.

Starting in vSphere 7.0, vCenter Server supports federated authentication, where you configure a connection to an external identity provider to replace vCenter Server as the identity provider. Currently, vCenter Server supports only Active Directory Federation Services (AD FS) as an external identity provider.

The permission model for vCenter Server systems relies on assigning permissions to objects in the object hierarchy. A permission is the assignment of a user (or group) and a role to an inventory object.

When you add a new identity source to SSO, all users can be authenticated, but will effectively have the No Access role to the vCenter Server inventory.

Inventory Hierarchy and Objects

You can assign permissions to objects at different levels of the inventory hierarchy, such as ESXi hosts, clusters, virtual machines, folders, resource pools, datastores and networks. You can also assign permissions to a global root object to apply the permissions to all object in all solutions. You can apply permissions to container objects and optionally allow the permissions to propagate to its descendent objects. Most objects inherit permissions from its parents via a single path, but virtual machines inherit permissions from virtual machine folders, hosts, resource pools, etc., as you can see in Figure 7-2. If an object inherits permissions from two parent objects, then its inherited permissions are determined by the union of the permissions. Figure 7-2 is a diagram from the VMware vSphere 7.0 Security Guide that shows the vSphere Inventory Hierarchy.

Objects might have multiple permissions, but only one permission for each user or group. In other words, you cannot assign two permissions on a specific object that specify the same group. If multiple permissions are applied to a specific object using multiple groups and if a specific user belongs to more than one of these groups, then the effective permissions for that user on that object is the union of the privileges in applicable roles.

Privileged users can define permissions on managed objects.

•   Clusters

•   Data centers

•   Datastores

•   Datastore clusters

•   Folders

•   Hosts

•   Networks (except vSphere Distributed Switches)

•   Distributed port groups

•   Resource pools

•   Templates

•   Virtual machines

•   vSphere vApps

Privileges and Roles

Privileges are the lowest-level access controls, which can be used to define the actions that a user can take on an object in the vSphere inventory. Table 7-8 describes a few of the available privilege categories and a few sample privileges in each category.

A role is a set of privileges. The vCenter Server provides many roles out of the box. You cannot modify the vCenter Server System Roles, which are described in Table 7-9. You can modify the Sample Roles, but VMware recommends that you do not modify these roles directly, but instead clone the roles and modify the clones to suit your case.

The sample roles in vCenter Server 7.0 are:

•   Resource Pool Administrator (sample)

•   Virtual Machine User (sample)

•   VMware Consolidated Backup User (sample)

•   Datastore Consumer (sample)

•   Network Administrator (sample)

•   Virtual Machine Power User (sample)

•   Content Library Administrator (sample)

•   Content Library Registry administrator (sample)

To get familiar with the privileges in a sample role, you can edit the role and explore the privileges that are included in the role. For example, if you edit the Virtual Machine Console User role, you will see that it only includes some privileges in the Virtual Machine > Interaction category and no other privileges. Specifically, it includes only these privileges:

•   Answer Question

•   Configure CD media

•   Configure floppy media

•   Connect devices

•   Console interaction

•   Install VMware Tools

•   Power off

•   Power on

•   Reset

•   Suspend

Permissions

The permission model for vCenter Server systems relies on assigning permissions to objects in the object hierarchy. A permission is the assignment of a user (or group) and a role to an inventory object. A permission is set on an object in the vCenter object inventory. Each permission associates the object with a group (or user) and a role, as illustrated in Figure 7-3. For example, you can select a virtual machine object, add one permission that gives the ReadOnly role to Group 1, and add a second permission that gives the Administrator role to User 2.

Global Permissions

Most entities that appear in the vCenter Server inventory are managed objects, whose access can be controlled using permissions. You cannot modify permissions on entities that derive permissions from the root vCenter Server system, such as the following.

•   Custom fields

•   Licenses

•   Roles

•   Statistics intervals

•   Sessions

The global root object is used to assign permissions across solutions. The vCenter Server is an example of a solution and it is attached as a child to the global root object in the hierarchy. The Content Library and Tag Category objects are also attached as children to the global root object. Global permissions are permissions that are applied to the global root object and span solutions. For example, a global permission can be applied to both vCenter Server and vRealize Orchestrator. Each solution has its own root object in the hierarchy, whose parent is the global root object. You can give a group of users Read permissions to all objects in both object hierarchies.

Best Practices for Roles and Permissions

VMware recommends the following best practices when configuring roles and permissions in your vCenter Server environment:

•   Where possible, assign roles to groups rather than to individual users.

•   Grant permissions to users (groups) only on the objects where they are required. Use the minimum number of permissions to meet the required functionality.

•   If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users who require administrative privileges.

•   Use folders to group objects. For example, to grant modify permission on one set of hosts and view permission on another set of hosts, place each set of hosts in a folder.

•   Use caution when adding a permission to the root vCenter Server objects. Users with privileges at the root level have access to global data on vCenter Server, such as roles, custom attributes, and vCenter Server settings.

•   Consider enabling propagation when you assign permissions to an object. Propagation ensures that new objects in the object hierarchy inherit permissions. For example, you can assign a permission to a virtual machine folder and enable propagation to ensure the permission applies to all VMs in the folder.

•   Use the No Access role to mask specific areas of the hierarchy. The No Access role restricts access for the users or groups with that role.

Required Privileges for Common Tasks

Many tasks require permissions on multiple objects in the inventory. Consider the following:

•   To perform any operation that consumes storage space, such taking a snapshot, you must have the Datastore.Allocate Space privilege on the target datastore in addition to having the directly required privileges on the major object.

•   Moving an object in the inventory hierarchy requires appropriate privileges on the object itself, the source parent object (such as a folder or cluster), and the destination parent object.

•   Deploying a virtual machine directly to a host or cluster requires the Resource.Assign Virtual Machine to Resource Pool privilege, because each host or cluster has its own implicit resource pool.

Table 7-10 shows the required privileges for a few common tasks.

How Permissions are Applied by vCenter Server.

As you assign each permission, you can choose whether to allow the permission to propagate to child objects. This setting is made per permission and cannot be universally applied. The default setting is to allow propagation to child objects. The propagation is applied to the vSphere Inventory Hierarchy as shown in Figure 7-2.

In the case where conflicting permissions are applied to an object and to its ancestors, the permissions that are assigned at a lower level object in the inventory hierarchy override permissions assigned at a higher level object. In the case where multiple permissions are assigned to the same object to different groups that contain a specific user, then that user’s effective permissions are the union of the associated privileges. Permissions assigned to a user override permissions assigned to groups containing the user, when the permissions are applied to the same object. The No Access permission is given precedence over all other roles. For example, consider the following scenario, which is illustrated in Figure 7-4.

•   One cluster exists in the inventory, which contains host-01 and host-02.

•   The user account User-A is a member of groups Group-01 and Group-02

•   The user account User-B is a member of group Group-01

•   The user account User-C is a member of group Group-02

•   The user account User-D is a member of groups Group-01 and Group-03

•   The user account User-E is a member of groups Group-02 and Group-04

Propagate to Child Objects is enabled for each of the following permissions

•   A permission assigns Group-01 the Administrator role on the Cluster

•   A permission assigns Group-02 the Administrator role on host-01

•   A permission assigns Group-02 the Read Only role on host-02

•   A permission assigns User-D the Read Only role on the cluster

•   A permission assigns Group-03 the No Access role on host-02

•   A permission assigns Group-04 the Read Only role on host-01

•   A permission assigns Group-04 the No Access role on host-02

In this scenario, the following effective permissions apply

•   User-A:

•   Can perform all tasks on the cluster object

•   Can perform all tasks on the host-01 object

•   Can only view the host-02 object

•   User-B:

•   Can perform all tasks on the cluster object

•   Can perform all tasks on the host-01 object

•   Can perform all tasks on the host-02 object

•   User-C:

•   Cannot view or perform any task on the cluster object

•   Can perform all tasks on the host-01 object

•   Can only view the host-02 object

•   User-D

•   Can only view the cluster object

•   Can only view the host-01 object

•   Cannot view or perform any task on the host-02 object

•   User-E

•   Cannot view or perform any task on the cluster object

•   Can perform all tasks on the host-01 object

•   Cannot view or perform any task on the host-02 object

ESXi and vCenter Server Security

ESXi has many built-in security features such as CPU isolation, memory isolation, and device isolation. An ESXi host is protected with a firewall that is intended to only permit required network traffic. Starting with vSphere 6.0, ESXi hosts participate in the certificate infrastructure and, by default, are provisioned with certificates that are signed by the VMware Certificate Authority (VMCA).

Optionally, you can further harden ESXI by configuring features such as lockdown mode, certificate replacement, and smart card authentication for enhanced security. You should consider limiting direct access to ESXi hosts, using security profiles, using host profiles, and managing certificates. Additionally, you can take other security measures, such as using multiple networks to segregate ESXi network functions, configuring Smart Card Authentication, and implementing UEFI Secure Boot for ESXi hosts

Built-in Security Features

•   ESXi Shell and SSH are disabled by default.

•   By default, ESXi runs only services that are essential to managing its functions.

•   By default, all ports that are not required for management access to the host are closed.

•   By default, weak ciphers are disabled and communications from clients are secured by SSL. 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. ESXi is not vulnerable to the Tomcat security issues reported in other use cases, because the service has been modified to run only functions that a Web client requires for administration and monitoring

•   VMware monitors all security alerts that can affect ESXi security and issues security patches when needed.

•   Secure services such as SSH and SFTP are available and should be used instead of insecure counterparts, like Telnet and FTP.

•   ESXi provides the option of using UEFI Secure Boot

•   When a TPM 2.0 chip is available in the hardware and configured in the system BIOS, ESXi works with Secure Boot to enhance security and trust assurance rooted in hardware

Security Profiles

You can customize many of the essential security settings for your host through the Security Profile panel available in the vSphere Client. You can use Security Profiles to customize services and configure the ESXi firewall. Table 7-11 identifies the services and that are available to you to view and manage using the vSphere Client for a default vSphere installation. For each service, the default state and description are provided. You can use the vSphere client to start, stop, and restart induvial services.

Table 7-12 lists the firewall ports that are installed by default in ESXi 7.0. On a specific host, the list of actual services and firewall ports can be impacted by the currently installed VMware Installation Bundles (VIBs).

The RFB Protocol (TCP 5900-5964) and OpenWSMAN Daemon (TCP 8889) are firewall ports for services that are not visible in the vSphere Client by default.

ESXi Password Hardening

One step for hardening an ESXi host is to harden the password required to use its predefined, local administrator account, which is called root. By default, the ESXi host enforces passwords for its local user accounts, which may be used to access the host via the Direct Console User Interface (DCUI), the ESXi Shell, Secure Shell (SSH) or the vSphere Client. You can modify the ESXi password requirements by setting the Security.PasswordQualityControl advanced option for the host. For example, you can set Security.PasswordQualityControl configure the ESXi host to accept pass phrases, which it does not accept by default.

Join an ESXi Host to a Directory Service

You can join an ESXi host to a directory service, such as an Active Directory, and configure permissions to allow the associated users to connect directly to the ESX host using DCUI, ESXi Shell, SSH, or the vSphere Host Client. The main reason for this is to reduce the number of local ESXi user accounts that you must create and manage. Another reason is to provide users with the means to access ESXi directly with an existing user account whose password is already hardened.

vSphere Authentication Proxy

You can add ESXi hosts to an Active Directory domain by using vSphere Authentication Proxy instead of adding the hosts explicitly to the Active Directory domain. To do this, you can add the host's IP address to the vSphere Authentication Proxy access control list. By default, the vSphere Authentication Proxy will authorize the host based on its IP address. You can enable client authentication to have vSphere Authentication Proxy check the host's certificate. If you are using Auto Deploy, you can configure a reference host to point to the Authentication Proxy, setup a rule that applies the reference host’s profile to others hosts provisioned by Auto Deploy, let Auto Deploy store the host’s IP address in the access control list, and join the host to the AD domain.

ESXi Host Access

You can implement lockdown mode to force operations to be performed through vCenter Server. You can choose to use strict lockdown mode, which disables the Direct Console User Interface (DCUI) service or normal lockdown mode, which allows DCUI access for some users. In normal lockdown mode, user accounts that are in the Exception Users list and have administrator privileges on the host can access the DCUI. A common use case is to provide access to service accounts, such as backup agents. Also, in normal lockdown mode, users identified in the host’s DCUI.Access advanced option can access the DCUI. If the ESXi Shell or SSH is enabled and the host is placed in lockdown mode, accounts in the Exception Users list who have administrator privileges can use these services. For all other users, ESXi Shell or SSH access is disabled. The main use case is to provide user access in the event of catastrophic failure. Starting with vSphere 6.0, ESXi or SSH sessions for users who do not have administrator privileges are terminated.

Control MOB Access

The vCenter Server Managed Object Browser (MOB) provides a means to explore the vCenter Server object model. Its primary use is for debugging. It provides the ability to make some configuration changes, so it may be considered a vulnerability for malicious attacks. The MOB is disabled by default. You should only enable it for debugging or for tasks that require it, like extracting the old certificate from a system. To enable MOB, you can use the vSphere Client to set the host’s advanced system setting Config.HostAgent.plugins.solo.enableMob. You should not use the vim-cmd in the ESXi Shell for this purpose.

ESXi Secure Boot and TPM

UEFI Secure Boot is a mechanism that ensures that only trusted code is loaded by the EFI firmware prior to OS handoff. When Secure Boot is enabled, the UEFI firmware validates the digitally signed kernel of an OS against a digital certificate stored in the UEFI firmware. Starting with vSphere 6.5, ESXi supports secure boot if it is enabled in the hardware. ESXi version 6.5 and later supports UEFI secure boot at each level of the boot stack.

ESXi is composed of digitally signed packages called vSphere installation bundles (VIBs). These packages are never broken open. At boot time, the ESXi file system maps to the content of those packages. By leveraging the same digital certificate in the host UEFI firmware used to validate the signed ESXi kernel, the kernel then validates each VIB using the Secure Boot verifier against the firmware-based certificate, ensuring a cryptographically “clean” boot.

When Secure Boot is enabled, ESXi will prevent the installation of unsigned code on ESXi. To install unsigned code such as beta drivers, you must disable Secure Boot. When Secure Boot is enabled, the Secure Boot verifier will run, detect the unsigned VIB, and crash the system, which produces the Purple Screen of Death (PSOD) event that identifies the VIB that must be removed. To remediate, boot the ESXi host with Secure Boot disabled, remove the VIB, and reboot with Secure Boot enabled.

ESXi can use Trusted Platform Modules (TPM) chips, which are secure cryptoprocessors that enhance host security by providing a trust assurance rooted in hardware as opposed to software. TPM is an industry-wide standard for secure cryptoprocessors. TPM chips are found in most of today's computers, from laptops, to desktops, to servers. vSphere 7.0 supports TPM version 2.0. A TPM 2.0 chip attests to an ESXi host's identity. Host attestation is the process of authenticating and attesting to the state of the host's software at a given point in time. UEFI secure boot, which ensures that only signed software is loaded at boot time, is a requirement for successful attestation.

vSphere Trust Authority (vTA)

In an environment where TPM attestation is used, you can implement Configure vSphere Trust Authority (vTA), which uses its own management cluster to serve as a hardware root of trust. Ideally the vTA trusted hosts cluster is small, separate from all other clusters, and has very few administrators. In vSphere 6.7, you could leverage TPM and vCenter Server to identify hosts that failed attestation, but you could not automatically prevent secured workloads from migrating to those hosts. Also, you could not encrypt vCenter Server. In vSphere 7.0 with vTA, you can enable the trusted hosts cluster to handle the attestation of other hosts and to take over the distribution of the encryption keys from the Key Management Servers (KMS). This removes vCenter Server from the critical path for key distribution and enables you to encrypt vCenter Server. A Trusted Infrastructure consists of at least one vSphere Trust Authority Cluster, at least one Trusted Cluster, and at least one external KMIP-compliant key management server, as illustrated in Figure 7-5, which is a diagram from the VMware vSphere 7.0 Security Guide.

vCenter Server Security

You should follow VMware guidelines to ensure security of the vCenter Server environment.

User Access

The user accounts defined in the local operating system (localos) of the Linux based vCenter Server Appliance have no permissions defined in the vCenter Server environment. The localos user accounts, like root, sshd, and vdtc are not members of any SSO domain (vsphere.local) group to which permissions are applied. No one should attempt to use these accounts to login to the vSphere Client. You should not use these accounts when configuring permissions or group memberships. Do not allow users to login directly to the localos of the vCenter Server appliance. Only login locally when required.

By default, the only accessible user account in the SSO domain is Administrator, which has full control of the environment. If you use the default SSO domain name, then the user account is Admnistrator@vsphere.local. Ideally, you should integrate vSphere with a supported enterprise directory service, like Active Directory, to allow users seamless access without requiring additional user accounts. Alternatively, you can create other user accounts in the SSO domain for your users. You should ensure each user access the environment with a unique account that is assigned the minimally required privileges.

For users who require the Administrator role, you should assign the role to the appropriate user accounts or group accounts to avoid using the SSO administrator account.

The vCenter Server connects to each ESXi host with the vpxuser account defined on the host. By default, vCenter Server changes the vpxuser password automatically every 30 days on each connected ESXi host. To change this behavior, you can change the value of the vCenter Server advanced setting VimPasswordExpirationInDays.

vCenter SSO Password Policy

The password for the SSO administrator account and other SSO domain user accounts is controlled by the SSO password policy. By default, this password must meet the following requirements:

•   At least eight characters

•   At least one lowercase character

•   At least one numeric character

•   At least one special character

Additionally, the password cannot use more than 20 characters and cannot contain non-ASCII characters. SSO administrators can change the default password policy.

Restrict Administrative Privileges

You should use permissions to assign the Administrator role to just the specific users and group, who truly require it. You should create and use custom roles with only the required privileges when creating permissions. In other words, you should apply the principle of least privileges when configuring permissions in vCenter Server.

By default, a user with the Administrator role can interact with files and applications within a virtual machine's guest operating system. If your administrators do not require this interaction, consider applying a role without the Gust Operations privilege.

Restrict vCenter Server Access

You should minimize users who can log directly in to the vCenter Server localos, as they could intentionally or unintentionally cause harm by altering settings and modifying processes. Allow only users with legitimate purposes to log in to the system and ensure the login events are audited.

You should secure the network where vCenter Server is connected by applying the information in the vSphere Network Security section in this chapter.

Control Datastore Browser Access

Assign the Datastore.Browser datastore privilege only to users and user groups who truly require the privilege.

vCenter Server and Client Certificates

You should ensure that vSphere Client users and other client applications heed certificate verification warnings to avoid Man in the Middle (MiTM) attacks.

You should remove any expired or revoked certificates from the vCenter Server to avoid MiTM attacks.

Time Synchronization

You should ensure that all systems, such as vCenter Server, ESXi, and supporting services, use the same relative time source. The time source must be in sync with an acceptable time standard, such as Coordinated Universal Time (UTC). Time synchronization is critical for many vSphere features, such as vSphere HA. It is also critical for securing vSphere.

Time synchronization is essential for certificate validation. Time synchronization simplifies troubleshooting and auditing. Incorrect time settings make it difficult to analyze and correlate log files related to detecting attacks and conducting security audits.

vSphere Network Security

You can use firewalls, segmentation, VLANs, and other measures to secure the networks used by your virtual machines and the vSphere environment. Put vCenter Server on the management network only. Avoid putting the vCenter Server system on other networks such as your production network or storage network, or on any network with access to the Internet. vCenter Server does not need access to the network where vMotion operates.

Firewalls

You can use traditional (physical) firewalls, virtual machine-based firewalls, and hypervisor based firewalls (like NSX distributed firewall) to protect inbound and outbound traffic to the vCenter Server, ESXi hosts, virtual machines, and other vSphere components. Ideally, you could use firewalls to allow only the required traffic between specific vSphere components, virtual machines, and network segments.

Segmentation and Isolation

You should keep different virtual machine zones within a host on different network segments to reduce the risk of data leakage and threats. Such threats include Address Resolution Protocol (ARP) spoofing, where an attacker manipulates the ARP table to remap MAC and IP addresses, and gains access to network traffic to and from a host. Attackers use ARP spoofing to generate man in the middle (MITM) attacks, perform denial of service (DoS) attacks, and hijack the systems. You can implement segmentation by using one of two approaches.

•   Use separate physical network adapters for virtual machine zones, which may be the most secure method.

•   Set up virtual local area networks (VLANs) for virtual machine zones, which may be the most cost-effective method.

You should isolate the vSphere management network, which provides access to the management interface on each component. In most cases, you should place the vSphere management port group in a dedicated VLAN and ensure that the network segment is not routed, except to other management-related networks. Likewise, you should isolate IP-based storage traffic and vMotion traffic.

Internet Protocol Security

You can configure Internet Protocol Security (IPsec) on ESXi hosts to enable authentication and encryption of incoming and outgoing packets. You can configure security associations to control how the system encrypts the traffic. For each association, you configure a name, source, destination, and encryption parameters. You can configure security policies to determine when the system should encrypt traffic. Security policies include information such as source, destination, protocol, direction, mode, and a security association.

To list the available security associations, you can use this command in ESXi.

esxcli network ip ipsec sa list

To add a security association, you can use the esxcli network ip ipsec sa add with one or more options from Table 7-13.

General Networking Security Recommendations

Here are other general networking security recommendations.

•   If spanning tree is enabled, ensure that physical switch ports are configured with Portfast.

•   Ensure that Netflow traffic for a Distributed Virtual Switch is only sent to authorized collector IP addresses.

•   Ensure that only authorized administrators have access to virtual networking components by using the role-based access controls.

•   Ensure that port groups are not configured to the value of the native VLAN.

•   Ensure that port groups are not configured to VLAN values reserved by upstream physical switches.

•   Ensure that port groups are not configured to VLAN 4095 except for Virtual Guest Tagging (VGT).

•   On distributed virtual switches, restrict port-level configuration overrides. The port-level override option is disabled by default.

•   Ensure that distributed virtual switch port mirror traffic is sent only to authorized collector ports or VLANs.

Network Security Policies

You should connect virtual machines to standard virtual switch port group or distributed virtual switch port group that are configured with an appropriate security policy. The network security policy provides three options, which may be set to Reject or Accept, as described in Table 7-14.

On a distributed virtual switch, you can override the security policy per virtual port.

Virtual Machine Security

To harden a virtual machine, you could follow best practices, configure UEFI, implement security policies, protect against denial of service attacks, and implement encryption.

Virtual Machine Hardening Best Practices

•   General Protection – In most respects, treat the virtual machine as you would a physical server when it comes to applying security measures. For example, be sure to install guest operating systems patches, protect with anti-virus software and disable unused serial ports.

•   Templates – Carefully harden the first virtual machine deployment of each guest O/S and verify hardening completeness. Convert the virtual machine into a template and use the template to deploy virtual machines as needed.

•   Virtual machine console – Minimize the use of this console. Only use it when required. Use remote tools, such as SSH and Remote Desktop to access virtual machines. Consider limiting the number of console connections to just one.

•   Virtual machine resource usage – Prevent virtual machines from taking over resources on the ESXi host to minimize the risk of Denial of Service to other virtual machines. Configure each virtual machine with enough virtual hardware, but not more virtual hardware resources than needed. For example, configure each virtual machine with enough virtual memory to handle its workload and meet application vendor recommendations, but do not provide much more memory than you expect it will need. Consider setting reservations or shares to ensure that critical virtual machines have access to enough CPU and memory.

•   Disable unnecessary services – Disable or uninstall any function for the guest O/S that is not required to reduce the number of components that can be attacked and to reduce its resource demand. For example, turn off screen savers, disable unneeded guest operating system services, and disconnect the CD/DVD drive.

•   Disable Unnecessary Hardware Devices – To minimize potential attack channels, disable any hardware devices that are not required, such as floppy drives, serial ports, parallel ports, USB controllers, and CD-ROM drives.

Configure UEFI Boot

Starting with vSphere 6.5, If the operating system supports secure UEFI boot, you can configure your VM to use UEFI boot. Prerequisites are UEFI firmware, Virtual hardware version 13 or later, VMware Tools version 10.1 or later, an operating system that supports UEFI secure boot. For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode and should be removed from VMware Tools before you enable secure boot. If you turn on secure boot for a virtual machine, you can load only signed drivers into that virtual machine.

In guest operating system that supports UEFI secure boot, each piece of boot software is signed, including the bootloader, the operating system kernel, and operating system drivers. The default configuration includes several code-signing certificates, including a Microsoft certificate for booting Windows, a Microsoft certificate for third party code, and a VMware certificate for booting ESXi inside a virtual machine. The virtual machine default configuration includes one certificate, which is the Microsoft Key Exchange Key (KEK) certificate.

If you turn on secure boot for a virtual machine, you can only load signed drivers in the guest OS.

Disable Unexposed Features

Some virtual machine settings, which are useful for other platforms (such as VMware Workstation and VMware Fusion) can be disabled in a vSphere environment. To reduce potential risk, consider setting the following advanced virtual machine options to TRUE.

•   isolation.tools.unity.push.update.disable

•   isolation.tools.ghi.launchmenu.change

•   isolation.tools.memSchedFakeSampleStats.disable

•   isolation.tools.getCreds.disable

•   isolation.tools.ghi.autologon.disable

•   isolation.bios.bbs.disable

•   isolation.tools.hgfsServerSet.disable

Other Common Settings

You should consider the following setting, which are commonly set to address specific, potential security threats.

•   Disk shrinking: Because disk shrinking, which reclaims unused disk space from a virtual machine, can take considerable time to complete and its invocation can result in a temporary denial of service, disable disk shrinking using the following lines in the VMX file

isolation.tools.diskWiper.disable = “TRUE”
isolation.tools.diskShrink.disable = “TRUE”

•   Copy and paste: This ability is disabled by default in new virtual machines. In most cases, retain this default setting to ensure that one user of the virtual machine console cannot paste data that was originally copied from a previous user. Ensure that the following lines remain in the VMX files

isolation.tools.copy.disable = “TRUE”
isolation.tools.paste.disable = “TRUE”

•   Connecting devices: By default, the ability to connect and disconnect devices is disabled. One reason is to prevent one user from accessing a sensitive CD-ROM device that was left in the drive. Another reason is to prevent users from disconnecting the network adapter, which could produce a denial of service. Ensure that the following lines remain in the VMX file.

isolation.device.connectable.disable = “TRUE”
isolation.device.edit.disable = “TRUE”

•   Logging: Uncontrolled virtual machine logging could lead to denial of service if the associated datastore runs out of disk space. VMware recommends keeping 10 log files. To set this on a virtual machine, set the following in the VMX file

vmx.log.keepOld = “10”

Alternatively, to limit the number of log files for virtual machines on an ESXi host, add the previous line to the host’s /etc/vmware/config file. A more aggressive measure is to disable virtual machine logging with the following statement in the VMX file

logging = “FALSE”

•   VMX file size: By default, the size of each VMX file is 1 MB, because uncontrolled file sizes can lead to a denial of service if the datastore runs out of disk space. Occasionally, setinfo messages that define virtual machine characteristics or identifiers are sent as name-value pairs from the virtual machine to the VMX file. If needed, you can increase the size of the VMX file limit by using the following statement in the VMX file but replacing the numeric value with a larger value. In most cases, keep the default setting as a security measure.

tools.setInfo.sizeLimit = “1048576”. If tools.setInfo.sizeLimit is not set in the virtual machine's advanced options, then the default size applies.

•   Performance counters: VMware Tools provides performance counters on CPU and memory from the ESXi host into the virtual machine for use by PerfMon. This feature is disabled by default, because an adversary could potentially make use of this information to attack the host. Ensure the following line remains in the VMX files, which blocks some, but not all performance metrics.

tools.guestlib.enableHostInfo = “FALSE”

Virtual Machine Risk Profiles

VMware provides the vSphere 6.0 Hardening Guide that provides guidelines for address vulnerabilities based on risk profiles. When you can apply the hardening guide to your environment, the first step is to apply the appropriate risk profile based on the sensitivity of your environment and data. The hardening guide offers three risk profiles:

•   Risk Profile 1: Intended to be implemented in just the most secure environments, such as top-secret government environments.

•   Risk Profile 2: Intended to be implemented in sensitive environments to protect sensitive data such as those that must adhere to strict compliance rules.

•   Risk Profile 3: Intended to be implemented in all production environments.

For vSphere 6.7, the vSphere Hardening Guide is replaced with the vSphere 6.7 Update 1 Security Configuration Guide. The risk profiles are removed, primarily because only the only remaining Risk Profile 1 setting is ESXi.enable-strict-lockdown-mode. Instead of identifying risk profiles, the new guide simply lists the current 50 Guideline IDs alphabetically and includes a Vulnerability Discussion for each guideline. As of July 2020, no vSphere 7.0 Security Configuration Guide is available.

Protect Virtual Machine Against Denial-of-Service Attacks

As previously stated, the virtual machine configuration file (VMX file) size limit is 1 MB by default, but you can change it using the tools.setInfo.sizeLimit parameter to avoid filling the datastore and causing a Denial of Service (DoS).

Virtual Machine Communication Interface (VMCI) is a high-speed communication mechanism for virtual machine to ESXi host communication. In some VMware products, including ESXi 4.x, VMCI also provides high-speed communication between virtual machines on the same ESXi host. In ESXi 5.1, the guest to guest VMCI is removed. In a VMX file, the vmci0.unrestricted parameter is used to control VMCI isolation for virtual machines running on ESX/ESXi 4.x and ESXi 5.0, but has no effect on virtual machines running on ESXi 5.1 and later. Any DoS concerns related to VMCI in previous vSphere versions do not apply to vSphere 7.0.

Non-administrative users in the guest operating system can shrink virtual disks to reclaim the disk's unused space. However, if you shrink a virtual disk repeatedly, the disk can become unavailable and cause a denial of service. To prevent this, you could disable the ability to shrink virtual disks using the following steps.

1. Shutdown the virtual machine

2. Modify the advanced settings in the virtual machine options.

3. Set isolation.tools.diskWiper.disable and isolation.tools.diskShrink.disable to TRUE

Control VM Device Connections

As previously stated, the ability to connect and disconnect devices is disabled by default for new virtual machines. In most cases, you should not change this behavior. You should verify that the following setting exist in your VMX files, especially if the virtual machines were deployed from a non-hardened template or were originally built on older ESXi hosts.

isolation.device.connectable.disable = “TRUE”
isolation.device.edit.disable = “TRUE”

If these parameters are set to FALSE, then in a guest operating system, any user or process, with or without root or administrator privileges, could use VMware Tools to change device connectivity and settings. They could connect or disconnect devices, such as network adaptors and CD-ROM drives. They could modify device settings. This functionality could allow them to connect a CD-ROM with sensitive data. It could allow them to disconnect a network adapter, which could cause a denial of service to other users.

Virtual Machine Encryption

Starting with vSphere 6.5, you can protect your virtual machines, virtual disks, and other virtual machines files using virtual machine encryption. In vSphere 6.5 and 6.7, you must set up a trusted connection between vCenter Server and a key management server (KMS). The KMS generates and stores keys. It passes the keys to vCenter Server for distribution. Starting in vSphere 7.0, you can remove the need for vCenter to request keys from the KMS by configuring vSphere Trust Authority (vTA) and making encryption keys conditional to cluster attestation.

You can use the vSphere Client or the vSphere API to add key provider instances to the vCenter Server system. vCenter Server uses the Key Management Interoperability Protocol (KMIP) to allow flexibility in choosing a KMS. If you use multiple key provider instances, all instances must be from the same vendor and must replicate keys. If you use different KMS vendors in different environments, you can add a key provider for each KMS and specify a default key provider. The first key provider that you add becomes the default key provider, but you can change it.

Only vCenter Servers (not the ESXi hosts) have the credentials for logging in to the KMS. vCenter Server obtains keys from the KMS and pushes them to the hosts. Two types of keys are used for virtual machine encryption.

•   Data encryption keys (DEKs) are internal keys generated by the ESXi host and used to encrypt virtual machines and disks. DEKs are XTS-AES-256 keys.

•   Key encryption key (KEKs) are the keys that vCenter Server requests from the KMS. KEKs are AES-256 keys. vCenter Server stores only the ID of each KEK, but not the key itself.

You can encrypt an existing virtual machine or virtual disk by changing its storage policy. Encryption works with any guest OS because encryption occurs at the hypervisor level. Encryption keys and configuration are not contained in the VM guest OS. Encryption works with any supported storage type, including VMware vSAN

You can encrypt virtual disks only for encrypted virtual machines. You cannot encrypt the virtual disk of an unencrypted VM. You can encrypt virtual machine files (NVRAM, VSWP, and VMSN files), virtual disk files, and core dump files. Log files, virtual machine configuration files, and virtual disk descriptor files are not encrypted. Per virtual machine, you can use the vSphere Client to encrypt and decrypt the virtual disks independently.

Core dumps are always encrypted on ESXi hosts where encryption mode is enabled. Core dumps on the vCenter Server system are not encrypted. To perform cryptographic operations, you must be assigned the Cryptographic Operations privileges.

ESXi uses KEKs to encrypt the internal keys and stores the encrypted internal keys on disk. ESXi does not store the KEK on disk. If a host reboots, vCenter Server requests the KEK with the corresponding ID from the KMS and makes it available to ESXi, who decrypts the internal keys as needed. In addition to VMDK files, most virtual machine files that contain guest data are encrypted, such as the NVRAM, VSWP, and VMSN files. The key that vCenter Server retrieves from the KMS unlocks an encrypted bundle in the VMX file that contains internal keys and other secrets.

VM encryption uses vSphere APIs for I/O filtering (VAIO), which is typically called the IOFilter. The IOFilter is an ESXi framework that allows for the interception of virtual machine I/O in the virtual SCSI emulation (vSCSI) layer, which is just below the virtual machine and above the file system. It enables VMware and third-party developers to develop services using virtual machine I/O, such as encryption, caching, and replication. It is implemented entirely in user space, which cleanly isolates it from the core architecture and core functionality of the hypervisor. In case of any failure, only the virtual machine in question would be impacted. Multiple filters can be enabled for a particular virtual machine or a virtual disk, which are typically chained in a manner so that I/O is processed serially by each of these filters before the I/O is passed down to VMFS or completed within one of the filters.

The default Administrator system role includes all Cryptographic Operations privileges. A new default role, the No Cryptography Administrator, supports all Administrator privileges except for the Cryptographic Operations privileges. You can create a custom role that contains granular Cryptographic Operations privileges such as Cryptographic operations > Encrypt (allows a user to encrypt a virtual machine or virtual disk) and Cryptographic operations > Add disk (allows a user to add a disk to an encrypted virtual machine).

The vSphere Client can be used to encrypt and decrypt virtual machines. To recrypt a virtual machine, you must use the API. You can use the API to perform a deep recrypt (replacing the DEK and KEK) or a shallow recrypt (replacing just the KEK) of a virtual machine. The deep recrypt requires that the virtual machine be powered off and be free from snapshots. The shallow recrypt is permitted on a virtual machine with one (not multiple) snapshots. The crypto-util command line utility can be used to decrypt core dumps, check for file encryption, and perform management tasks on the ESXi host.

When a user performs an encryption task, such as creating an encrypted virtual machine, the following events occur.

•   The vCenter Server requests a new key from the default KMS to use is use as the KEK.

•   The vCenter Server stores the key ID and passes the key to the ESXi host. If the host is part of a cluster, vCenter Server sends the KEK to each host in the cluster.

•   The key itself is not stored on the vCenter Server system. Only the key ID is known.

•   The ESXi host generates internal keys (DEKs) for the virtual machine and its disks. It uses the KEKs to encrypt internal keys and keeps the internal keys in memory only (never on disk). Only encrypted data is store on disk.

•   The ESXi host uses the encrypted internal keys to encrypt the virtual machine.

•   Any hosts that can access the encrypted key file and the KEK can perform operations on the encrypted virtual machine or disk.

Encrypted vSphere vMotion

Encrypted vSphere vMotion provides confidentiality, integrity, and authenticity of the data that is transferred with vSphere vMotion. Starting with vSphere 6.5, vSphere vMotion always uses encryption when migrating encrypted virtual machines. You cannot turn off encrypted vSphere vMotion for encrypted virtual machines. For virtual machines that are not encrypted, you can set Encrypted vMotion to one of the following states. The default is Opportunistic.

•   Disabled: Do not use encrypted vSphere vMotion.

•   Opportunistic: use encrypted vSphere vMotion if source and target hosts support it.

•   Required: If the source or destination host does not support encrypted vSphere vMotion, migration with vSphere vMotion is not allowed.

The following rules apply concerning encrypted vMotion across vCenter Server instances.

•   You must use the vSphere APIs.

•   Encrypted vMotion of unencrypted virtual machines is supported.

•   vMotion of encrypted virtual machines is not supported

•   The source and destination vCenter Server instances must share the KMS cluster that was used to encrypt the virtual machine.

•   The name of the shared KMS cluster must be the same on each vCenter Server instance.

•   You must have the Cryptographic operations.Migrate privilege on the virtual machine.

•   You must have the must have the Cryptographic operations.EncryptNew privilege on the destination vCenter Server.

•   If the destination ESXi host is not in “safe” mode, then you also need the Cryptographic operations.RegisterHost privilege on the destination vCenter Server

•   You cannot change the virtual machine storage policy or perform a key change

When using vSphere Trust Authority (vTA), the following requirements apply.

•   The destination host must be configured with vTA and must be attested.

•   Encryption cannot change on migration.

•   You can migrate a standard encrypted virtual machine onto a Trusted Host.

•   You cannot migrate a vTA encrypted virtual machine onto a non-Trusted Host.

Virtual Trusted Platform Module (vTPM)

A virtual Trusted Platform Module (vTPM) is a software-based representation of a physical Trusted Platform Module (TPM) 2.0 chip. A vTPM uses software to perform the same functions that a TPM performs in hardware. A vTPM uses the .nvram file, which is encrypted using virtual machine encryption, as its secure storage. A hardware TPM includes a preloaded key called the Endorsement Key (EK), which has a private and public key. For vTPM, the EK is provided either by the VMware Certificate Authority (VMCA) or by a third-party Certificate Authority (CA).

You can add a vTPM to either a new virtual machine or an existing virtual machine, which enables the guest operating system to create and store keys that are private. The keys are not exposed to the guest operating system itself, even if the guest operating system is compromised. The keys can be used only by the guest operating system for encryption or signing. With an attached vTPM, a third party can remotely attest to (validate) the identity of the firmware and the guest operating system.

When you configure a vTPM, VM encryption automatically encrypts the virtual machine files but not the disks. The backup of a VM with a vTPM must include all virtual machine data, including the *.nvram file. In order to successfully restore the VM, the backup must include the *.nvram file and you must ensure that the encryption keys are available.

To use a vTPM, you must meet the following requirements.

•   Virtual machine hardware version 14 using EFI firmware

•   vCenter Server 6.7 or greater

•   Virtual machine encryption (for home files) and Key Management Server (KMS)

•   Windows Server 2016 (64 bit) or Windows 10 (64 bit)

You can add a vTPM as you create a virtual machine, by selecting Customize Hardware > Add New Device > Trusted Platform Module. Likewise, you can add a vTPM to an existing, powered down virtual machine. In the vSphere Client, you can identify which virtual machines are enabled with vTPM by using Show / Hide Column in the VMs tab for a selected object, such as a host or cluster.

Virtual Intel Software Guard Extension (vSGX)

Intel Software Guard Extension (SGX) is a processor-specific technology for application developers to protect code and data from disclosure or modification. It allows user-level code to define enclaves, which are private regions of memory. It prevents code running outside the enclave from accessing content in the enclave.

If Intel SGX technology is available on your hardware, then your virtual machines can use Virtual Intel SGX (vSGX). To enable vSGX for a virtual machine, you must meet the following requirements.

•   Virtual machine hardware version 17 and EFI firmware

•   vCenter Server 7.0 and ESXi 7.0

•   Linux, Windows Server 2016 (64 bit) or later, or Windows 10 (64 bit) guest OS

•   Intel Coffee Lake CPU or later

When vSGX is enable on a virtual machine, the following features are not supported for that machine.

•   vMotion / DRS Migration

•   Virtual machine suspend and resume

•   Memory snapshots (Virtual machine snapshots are supported without snapshotting the memory.)

•   Fault Tolerance

•   Guest Integrity (GI) (The platform foundation for VMware AppDefense 10)

Available Add-on Security

You can further secure your environment by procuring and implementing additional measures that are not provided natively in vSphere. Such measures include additional VMware products, such as vRealize Operations Manager, NSX, and AppDefense.

Compliance using vRealize Operations Manager

You can implement vRealize Operations Manager (vROps) to provide a single pane of glass monitoring solution for your virtual infrastructure, applications, storage, and network devices. vROps provides an open and extensible platform supported by third-party management packs. It monitors performance and availability metrics, performs predictive analysis of the data, and enables pro-active remediation of emerging issues. Additionally, you can use vROps to monitor objects in your vSphere environment, such as vCenter Servers, hosts, virtual machines, distributed port groups, and datastores to ensure compliance with the appropriate standards. You can use vROps to define and analyze compliance standards.

You can customize vROps policies to enable vSphere Security Configuration Guide which enables vSphere alerts for ESXi hosts, vCenter Server, and virtual machines that are in violation with the guide. Additionally, hardening guides for regulatory standards are delivered as management packs (PAK files) that you can upload, license, and install. For example, you can install management packs for the following regulatory standards:

•   Health Insurance Portability and Accountability Act (HIPAA)

•   Payment Card Industry Data Security Standard (PCI DSS) compliance standards

•   CIS Security Standards

•   Defense Information Systems Agency (DISA) Security Standards

•   The Federal Information Security Management Act (FISMA) Security Standards

•   International Organization for Standardization Security Standards

vROps collects compliance data from your vSphere objects, generates compliance alerts, and creates reports of the compliance results.

VMware NSX

You can implement VMware NSX Data Center for vSphere (NSX) to add a distributed logical firewall, micro segmentation, and additional security measures to your vSphere environment.

NSX provides a Distributed Firewall (DFW) that runs in the VMkernel as a VIB package on all NSX-prepared ESXi hosts. The DFW offers near line rate performance, virtualization, identity awareness, automated policy creation, advanced service insertion, and other network security features. The DFW enhances your physical security by removing unnecessary hair-pinning from the physical firewalls and reduces the amount of traffic on the network. It enables micro-segmentation, where effectively, you can place a firewall on each VM network connection.

Micro-segmentation decreases the level of risk and increases the security posture of your vSphere environment. Micro-segmentation utilizes the following capabilities.

•   Distributed stateful firewalling

•   Topology agnostic segmentation

•   Centralized policy control

•   Granular controls

•   Network based isolation

With NSX, isolation can be achieved by leveraging VXLAN technology and virtual networks (i.e., Logical Switches). Isolation can also be achieved with traditional networking methods, such as ACLs, firewall rules, and routing policies. For example, in a brownfield environment, you could choose to keep existing VLAN segmentation to isolate VMkernel traffic and VM zones while using the NSX DFW to implement application segmentation.

With NSX, you can implement virtual machine to virtual machine protection, which is commonly referred to as east-west protection, in more than one manner. For example, you could implement multiple L2 segments with L3 isolation (see Figure 7-6) or implement a single L2 segment and use DFW rules for isolation (see Figure 7-7).

NSX provides other security features, such as Service Composer, which you can use to configure security groups and security policies. Security policies are a collection of firewall rules, endpoint services, and network introspection services. Security groups may be populated statically or dynamically based on containers (such as folders and clusters), security tags, Active Directory groups, and regular expressions. You map a security policy to a security groups.

NSX includes other security features, such as SpoofGuard, Edge Firewall, and Virtual Private Network (VPN).

AppDefense

You can secure your vSphere environment further by using VMware AppDense. AppDefense is a data center endpoint security product that protects applications running in vSphere. AppDefense understands an application's intended state and behavior, then monitors for changes to that intended state that indicate a threat. When a threat is detected, AppDefense automatically responds based on your policies. You can use AppDefense to define “good behavior” and to trigger automated, custom actions when other behavior is detected. For vSphere 7.0, AppDefense is available only as a separate product. For vSphere 6.7, AppDefense is included in the vSphere Platinum edition.

Key features of AppDense are:

•   It understands the intended state of each application and runs inside the hypervisor where it has an authoritative understanding of how data center endpoints are meant to behave. This means it is the first to know when changes are made.

•   Being hypervisor based, it runs in an isolated, protected environment, reducing the change that AppDefense itself will be compromised.

•   When a threat is detected, it takes the action that you pre-configure, leveraging vSphere and NSX, such as:

•   Block VM network communication

•   Snapshot a VM

•   Suspend or shutdown a VM

Summary

You completed reading this chapter on vSphere Security. You can use the remain sections in the chapter to prepare for associated exam questions

Exam Preparation Tasks

Review All the Key Topics

Table 7-15 provides a reference to each of the key topics identified in this chapter. Take a few moments to review each of these specific items.

Complete the Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables,” (found on the CD), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the CD, includes completed tables and lists to check your work.

Definitions of Key Terms

Define the following key terms from this chapter and check your answers in the glossary.

Trusted Platform Modules (TPM)

vmdir

VMware Certificate Authority (VMCA)

VMware Endpoint Certificate Store (VECS)

Virtual Trusted Platform Module (vTPM)

Intel Software Guard Extension (SGX)

Micro-segmentation

AppDefense

Answer Review Questions

1. You are preparing to implement certificates in your vSphere environment. Which of the following is supported in custom certificates by VMCA when it is used as a subordinate CA?

a. CRL Distribution Points

b. Authority Information Access

c. CRT format

d. Certificate Template Information

2. On which of the following items can you set permissions in vCenter Server.

a. Licenses

b. Datastores

c. Roles

d. Sessions

3. You are examining the default security profile in your vSphere environment. Which of the following services are stopped by default?

a. DCUI

b. Load-based Teaming Daemon

c. CIM Server

d. SNMP Server

4. You are hardening a vCenter Server and see that it contains some expired certificates. What is the main purpose for removing expired and revoked certificates from vCenter Server.

a. Avoid DoS attacks

b. Avoid MiTM attacks

c. Avoid automatic virtual machine shutdown due to expired certificates

d. Avoid ARP spoofing

5. You want to enable UEFI boot for your virtual machines. Which of the following is a requirement?

a. Virtual hardware version 11 or later

b. VMware Tools 11 or later

c. Virtual hardware version 12 or later

d. VMware Tools 10.1 or later