The process of hardening workstations, clients, or servers–including ESXi host servers–refers to configuring settings, software, and services to secure the device against unauthorized access. This is generally a very involved process that spans a number of tasks to ensure that only those who are required to interact with the devices are allowed.
SEE: Server virtualization: Best (and worst) practices (free PDF) (TechRepublic)
While hardening devices can take many forms, the number of tasks to be performed is tied to the type of device being secured and the level of security you’re trying to achieve. For example, a user’s desktop will usually be joined to some form of directory service so each user will have their own account to access the system. On a web server, you typically don’t want users logging in to the server, so that may be something to restrict.
When hardening virtual infrastructures, however, the areas can get a little gray; hardening the host requires one set of procedures that may be similar or largely different from the guest virtual machines (VMs) they’re hosting. For this article, we’ll look squarely at hardening techniques on the host side. The aim is to secure access to the physical host against unauthorized access, compromise, and data loss with several basic, yet often overlooked, security implementations.
SEE: How to virtualize Windows on VMware ESXi (TechRepublic)
1. Use trusted package sources
This one may seem like a no-brainer but it never ceases to amaze me when I see someone download the ISO from an untrusted source, such as a website other than VMware‘s, to create installation media to deploy new servers or upgrade existing ones. If downloading from untrusted sources wasn’t bad enough, failing to check the integrity of the package using a hashing algorithm is careless and asking for trouble, as this software could be compromised by malware that could be used to exfiltrate data among other attack vectors.
2. Change the default account
With the availability of vendor documentation and websites created for the sole purpose of archiving the default usernames and passwords for all manner of IT-related devices, you’d think that changing the default admin accounts on devices and their software would be one of the top tasks IT should be performing during the initial setup of enterprise-level devices. And yet, here we are, talking about how important it is to eliminate this attack vector by diligently changing all default accounts to safeguard your equipment and corporate data.
SEE: How to install VMware’s ESXi hypervisor on bare-metal hardware (TechRepublic)
3. Bind to directory services
ESXi hosts, like many services, can be run standalone or bound/joined to directory services to centrally manage users and groups and the granularly assigned permissions to virtualized resources and guest VMs. The benefits are similar to other servers, and the negatives are comparatively low for both IT managing these hosts and users tasked with accessing these resources. It’s also far simpler to manage one database of user accounts based on roles than it is to manage hundreds or thousands of servers individually.
4. Modify host services
ESXi hosts include multiple built-in services to ease management, data transfer, and secure access; examples of these services include FTP, SSH, and the ESXi Shell. While these services may not be necessary for your organization’s needs, it’s a good bet that at least one of these will be enabled at one time or another during the course of management.
Think ahead to account for which services may need to be run, from where, and by whom. This helps IT formulate a plan to secure access to limit access from unauthorized users and allow valid users a secure path with which to perform administrative tasks without compromising the host’s security.
SEE: VMware vSphere: Cheat sheet (TechRepublic)
5. Configure a host-based firewall
The built-in host-based firewall included with ESXi works well to limit access based on a number of parameters, such as limiting access to host servers based on the remote connection’s IP address. This lets admins designate a range that is allowed to connect to ESXi remotely to manage the server’s resources–all others will experience a dropped connection when filtered through the firewall’s ruleset. Determining which services are allowable and to what degree is paramount to ensuring access control lists (ACLs) are well-defined so traffic not explicitly matching the rules is filtered and never allowed to establish a connection with the server.