To protect an ESXi host against unauthorized intrusion and misuse, VMware imposes constraints on several parameters, settings, and activities. You can loosen the constraints to meet your configuration needs. If you do, make sure that you are working in a trusted environment and that you have taken enough other security measures to protect the network as a whole and the devices connected to the host.
Built-in Security Features
Risks to the hosts are mitigated out of the box as follows:
ESXi Shell and SSH are disabled by default.
Only a limited number of firewall ports are open by default. You can explicitly open additional firewall ports that are associated with specific services.
ESXi runs only services that are essential to managing its functions. The distribution is limited to the features required to run ESXi.
By default, all ports not specifically required for management access to the host are closed. You must specifically open ports if you need additional services.
By default, weak ciphers are disabled and communications from clients are secured by SSL. The exact algorithms used for securing the channel depend on the SSL handshake. Default certificates created on ESXi use PKCS#1 SHA-256 With RSA encryption as the signature algorithm.
The Tomcat Web service, used internally by ESXi to support access by Web clients, has been modified to run only those functions required for administration and monitoring by a Web client. As a result, ESXi is not vulnerable to the Tomcat security issues reported in broader use.
VMware monitors all security alerts that could affect ESXi security and issues a security patch if needed.
Insecure services such as FTP and Telnet are not installed, and the ports for these services are closed by default. Because more secure services such as SSH and SFTP are easily available, avoid using these insecure services in favor of their safer alternatives. For example, use Telnet with SSL to access virtual serial ports if SSH is unavailable and you must use Telnet.
If you must use insecure services and have implemented sufficient protection for the host, you can explicitly open ports to support them.
Additional Security Measures
Consider the following recommendations when evaluating host security and administration.
If you decide to enable access to the Direct Console User Interface (DCUI) the ESXi Shell, or SSH, enforce strict access security policies.
The ESXi Shell has privileged access to certain parts of the host. Provide only trusted users with ESXi Shell login access.
Do not access managed hosts directly
Use the vSphere Web Client to administer ESXi hosts that are managed by a vCenter Server. Do not access managed hosts directly with the vSphere Client, and do not make changes to managed hosts from the host's DCUI.
If you manage hosts with a scripting interface or API, do not target the host directly. Instead, target the vCenter Server system that manages the host and specify the host name.
Use the vSphere Client or VMware CLIs or APIs to administer standalone ESXi hosts
Use the vSphere Client, one of the VMware CLIs or APIs to administer your ESXi hosts. Access the host from the DCUI or the ESXi Shell as the root user only for troubleshooting. If you decide to use the ESXi Shell, limit the accounts with access and set timeouts.
Use only VMware sources to upgrade ESXi components.
The host runs a variety of third-party packages to support management interfaces or tasks that you must perform. VMware does not support upgrading these packages from anything other than a VMware source. If you use a download or patch from another source, you might compromise management interface security or functions. Regularly check third-party vendor sites and the VMware knowledge base for security alerts.
Follow the VMware security advisories at http://www.vmware.com/security/.