VCP6.7-DCV Objective 2.3 - Describe the options for securing a vSphere environment

Another post today for people studying to pass the latest VMware VCP certification exam. The post's name is VCP6.7-DCV Objective 2.3 – Describe the options for securing a vSphere environment and will teach us some security hardening features that vSphere has. Newly in vSphere 6.7 U2, a password history and reuse limits can now be applied.

This chapter could be broken down into a few main sub-chapters, where each one of those treats different part of the infrastructure. There are best practices for securing ESXi, vCenter server, virtual machines or networking.

The fact that vSphere is secure by default is good to know, but further security settings are possible. The ESXi hypervisor can further be configured and enabled by using lockdown mode and other features. You can also set up a host profile with security settings and then apply this to all your hosts in order to have a homogenous security environment.

By default ESXi shell and SSH services are not running is for something. Risk increases when you'll using ESXi shell and SSH access to login in remotely. You should always set timeouts to limit the risk of unauthorized access.

Also, the root user can do everything. You should not give the root access to everyone, but instead, you should create a named administrator user from the vCenter server and assign those users the Administrator (or a custom) role.

Check this chapter: VCP6.7-DCV Objective 7.4 – Configure host security

Let's get started.

This guide is available as Free PDF!

NEW:

Download FREE Study VCP7-DCV Guide at Nakivo.

The exam duration is 130 minutes
The number of questions is 70
The passing Score is 300
Price = $250.00

Securing ESXi Hypervisor

(check the post above). It is one of the first options for securing a vSphere environment.

Securing vCenter Server Systems and Associated Services

One of the options of options for securing a vSphere environment is vCenter server itself. Let's talk about vCenter server accounts. If the local Windows administrator account currently has the Administrator role vCenter Server, remove that role and assign the role to one or more named vCenter Server administrator accounts.

Grant the Administrator role only to those administrators who are required to have it. You can create custom roles or use the No cryptography administrator role for administrators with more limited privileges. Do not apply this role any group whose membership is not strictly controlled.

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.

Minimize access to vCenter server machine.

Restrict Datastore Browser Access – 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.

By default, vCenter Server changes the vpxuser password automatically every 30 days. Ensure that this setting meets company policy, or configure the vCenter Server password policy.

Set the vCenter Server Password Policy – By default, vCenter Server changes the vpxuser password automatically every 30 days. You can change that value from the vSphere Web Client.

Log in to a vCenter Server system using the vSphere Web Client > Select the vCenter Server system in the object hierarchy > Configure > Advanced Settings and enter VimPasswordExpirationInDays in the filter box.

Then Set VirtualCenter.VimPasswordExpirationInDays to comply with your requirements.

Protect the vCenter server Windows host

Maintain a supported operating system, database, and hardware for the vCenter Server system. If vCenter Server is not running on a supported operating system, it might not run properly, making vCenter Server vulnerable to attacks.
Keep the vCenter Server system properly patched. By staying up-to-date with operating system patches, the server is less vulnerable to attack.
Provide operating system protection on the vCenter Server host. Protection includes antivirus and anti-malware software.
On each Windows computer in the infrastructure, ensure that Remote Desktop (RDP) Host Configuration settings are set to ensure the highest level of encryption according to industry-standard guidelines or internal guidelines.

Securing Virtual Machines

VMs can be secured for threads trying to sneak in through the boot process. You can enable UEFI Secure boot. UEFI Secure Boot is a security standard that helps ensure that your PC boots using only software that is trusted by the PC manufacturer.

For certain virtual machine hardware versions and operating systems, you can enable secure boot just as you can for a physical machine. In an 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 virtual machine's default configuration includes several code signing certificates.

VMware Tools version 10.1 or later is required for virtual machines that use UEFI secure boot.

For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode. Remove VMware Host-Guest Filesystem from VMware Tools before you enable secure boot.

Right-click a VM and select Edit Settings > Click the VM Options tab, and expand Boot Options > Boot Options, ensure that firmware is set to EFI >

Select the Secure Boot check box to enable secure boot.
Deselect the Secure Boot check box to disable secure boot.

When the virtual machine boots, only components with valid signatures are allowed. The boot process stops with an error if it encounters a component with a missing or invalid signature.

VM's best practices:

Use the same security measures in virtual machines that you do for physical systems.
Use Templates to Deploy Virtual Machines
Minimize Use of the Virtual Machine Console
Prevent Virtual Machines from Taking Over Resources
Disable Unnecessary Functions Inside Virtual Machines

Use Encryption in your vSphere environment

Setup a key management server (not provided by VMware)
Create an encryption storage policy
Enable host encryption mode
Create an encrypted VMs
Change the encryption policy for VMDKs

Secure your environment with virtual Trusted Platform module

Add a Virtual Trusted Platform Module (vTPM) to a VM
Enable vTPM for an existing VM
Identify vTPM enabled VMs
View vTPM module device certificates

Securing the Virtual Networking Layer

Network security in the vSphere environment shares many characteristics of securing a physical network environment, but also includes some characteristics that apply only to virtual machines.

Segmentation – Keep different virtual machine zones within a host on different network segments. If you isolate each virtual machine zone on its own network segment, you minimize the risk of data leakage from one zone to the next. Segmentation prevents various threats, including Address Resolution Protocol (ARP) spoofing.

Use VLANs – Set up virtual local area networks (VLANs) to help safeguard your network. VLANs provide almost all the security benefits inherent in implementing physically separate networks without the hardware overhead..

Secure the physical switch – ensure that spanning tree protocol is disabled or that Port Fast is configured for all physical switch ports that are connected to ESXi hosts.

Secure Standard switch ports with security policies – You can use this security policy to ensure that the host prevents the guest operating systems of its VMs from impersonating other machines on the network. The guest operating system that might attempt impersonation does not detect that the impersonation was prevented.

Reference PDF: vSphere Security

Also read: Security of the VMware vSphere Hypervisor PDF

Being secured but not too “locked”, have a good balance between security and manageability. Making any changes to the security of the vSphere environment might have perhaps large impacts on the manageability of the environment for you and your team.

You should always analyze your needs, your risks, and your requirements. Then change the security of your environment.

More from ESX Virtualization

Stay tuned through RSS, and social media channels (Twitter, FB, YouTube)

Vote !