An Introduction to vSphere Security Hardening

Save to My DOJO

vSphere Security Hardening. Defining what to Protect
Securing ESXi
Securing vCenter Server
Securing Virtual Machines
Securing the Network
Securing Storage
Conclusion

Anyone in the business knows that security is vital, something that cannot be overlooked. With that in mind, I’m skipping straight to what you can do to facilitate vSphere security hardening. Having said that, today’s post is not exactly a how-to kind of post. Instead, I’ll be providing references to some sound source material along with a few tips and pointers. Have a look at Securing vCenter Server using roles, privileges, and permissions if you want to learn more about how to secure vCenter Server.

vSphere Security Hardening. Defining what to Protect

First we need to define what is that constitutes a vSphere environment. Excluding integrated products such as NSX, the major components are as follows. Click on each for more details.

ESXi Hosts – vCenter Server – VMs and Guest OS – The Network Layer – The Storage Layer

Next, we need to determine what we need to protect and how. Have a look at the following links:

VMware Security Hardening Guides
vSphere 6.5 Documentation
vSphere Security 6.0
vSphere Security 6.5
Compliance and Cyber Risk Solutions
The latest vSphere Security Configuration Guide including a blog post by its author

Securing ESXi

The folks at VMware have slowly but surely adopted an out-of-the-box hardened product approach. If we look at ESXi 6.5, we can see a number of inbuilt security features that are enabled by default. Some of these include:

Disabled SSH and Shell access.
A limited set of open ports and firewall rules.
Running services are limited to an absolute minimum.
Weak ciphers are disabled, client-server connections SSL secured. Certificates are SHA-256 RSA signed.
Services like MOB, FTP and telnet are disabled by default.

Other things you can do:

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

Enabling strict lockdown mode on ESXi

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

Running a script to verify if ESXi supports Secure Boot

References

Securing vCenter Server

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

vCenter Server for Windows:

Run vCenter for Windows on a supported operating system, database and hardware. This reduces vCenter Server susceptibility to vulnerabilities and subsequent attacks.
Patch and update the Windows OS and database software regularly.
Install antivirus, anti-malware and IDS software.
Abide by the Windows Server security best practices. An example would be configuring Remote Desktop (RDP) to accept encrypted sessions only.
Use service accounts instead of user accounts when installing and configuring vCenter and its database services.
Consider removing the local Windows administrator account from the vCenter administrators’ group. This is done by default in vSphere 6.x.

vCSA

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

General

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

Managing vCenter users, groups, and roles from vSphere Web client

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

References

Securing Virtual Machines

Whether you’re running mission critical services or simply deploying virtualized desktops to users, the guest OS on your VMs is susceptible to attack as any other component within your infrastructure. These are some of the steps you can take to better protect VMs.

Keep the guest OS up to date by installing any missing patches updates.
Disable unnecessary services and remove unused software to reduce the attack surface.
Install anti-virus and anti-malware software and keep it updated.
Install and maintain VMware Tools.
Enforce password and lockout policies.
For added security, protect mission critical virtual machines by limiting network access via an OS inbuilt firewall or ACLs set on physical networking equipment.
Restrict access to the VM’s console.
Consider using UEFI secure boot if using vSphere 6.5.
Deploy VMs from readily configured and updated templates for a standardized VM infrastructure.
Starting with vSphere 6.5, you can encrypt both the VM files and its disks.

Securing the Network

When it comes to the physical networking tier – physical switches, routers, etc. – the 3 main components offering protection are Firewalls, Segmentation, and Unauthorized Access Prevention. A firewall external to both vCenter and ESXi will minimize the chances of unwanted or unauthorized access to network ports and services. Segmentation creates separate networks or virtual machine zones which allow you to group VMs using metrics such as criticality and function. This prevents traffic eavesdropping and threats such as ARP spoofing which could lead to MITM and DOS attacks. Unauthorized access prevention is a far more reaching strategy and spans all the components mentioned so far and the steps taken to mitigate unauthorized access. Next in line are virtual switches, both standard and distributed. You can protect virtual traffic against impersonation and interception Layer 2 attacks by configuring a security policy on port groups or ports that control MAC address changes, forged transmits and promiscuous mode.

Configuring a security policy on a virtual switch

The reference links expand more on the subject since it’s quite an exhaustive one. Moreover, if network management is entrusted to other teams or admins within your organization, you will need to work as a team to harden the networking aspects of vSphere.

References

Securing Storage

Most likely, you’re probably using iSCSI and NFS based datastores. If that’s the case, here are a few things you can do to protect your storage. From a VM standpoint, I mentioned already that VM disks (vmdks) can be encrypted although this does not protect the storage medium where they reside per se.

With iSCSI, there are a few things you could do such as enabling CHAP for authentication and ensuring that initiator lists include only those ESXi hosts – IP addresses or IQNs – where datastores are mounted. You should also, where possible, limit iSCSI traffic to a dedicated network. This improves both performance and security. Finally, use zoning and LUN masking if your storage supports them. This will help you restrict access to and hide specific LUNS as applicable.

For NFS datastores, use NFS 4.1 which supports Kerberos thus ensuring secure communication with the NFS server hosting the datastore.

References

Conclusion

As we have seen, security is all encompassing. It takes a lot of work to make vSphere less susceptible to security threats more so when complying with standards such as PCI-DSS. For large environments, a vSphere security hardening exercise will see people from various teams such as Security, Networking and Databases work together towards this one common goal.

However, keep in mind that security hardening is an ongoing task. Security holes and the resulting exploits are a daily occurrence. This reminds me to tell you that now would be a good idea to subscribe to VMware’s security advisories.

You might also be interested in vSphere 6.5: What’s new with security.

[the_ad id=”4738″][the_ad id=”4796″]

Was this helpful?
Yes