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.
Securing ESXi Hypervisor
(check the post above). It is one of the first options for securing a vSphere environment.
Shop for vSphere licenses at VMware Store:
- vSphere Essentials Plus – vMotion, HA… 3 Hosts, vCenter
- vSphere Essentials – 3 Hosts, vCenter
- vSphere Standard – Per Physical CPU license
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
- What is Host Guardian Service?
- What is vCenter Embedded Linked Mode in vSphere 6.7?
- VCP6.7-DCV Objective 1.11 – Describe vMotion and Storage vMotion technology
- How to change virtual SCSI controler for VMware PVSCSI
- How to Patch VMware vCenter Server Appliance (VCSA) 6.7 Offline