<div>Welcome to day 4 as we blog our way through the <a href="http://communities.vmware.com/docs/DOC-19605">VMware vSphere 5.0 Hardening Guide</a>. We've already covered the first 15 security checks in parts one, two and three. Here are our five security checks for today:</div>
<ul>
	<li>Guideline Title: Disable SSH
<ul>
	<li>Title: disable-ssh</li>
	<li>Discussion: We all know and love SSH. It's an ecrypted way to access a command line on a remote system. But the truth is that a stopped service is infinitely harder to exploit than a running service. SSH should only be enabled as necessary for troubleshooting and then should be stopped again.</li>
	<li><a href="http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.security.doc_50/GUID-12E27BF3-3769-4665-8769-DA76C2BC9FFE.html">Official VMware documentation<!--more--></a></li>
</ul>
</li>
	<li>Guideline Title: Enable lockdown mode to restrict remote access
<ul>
	<li>Title: enable-lockdown-mode</li>
	<li>Discussion: Lockdown mode is often incorrectly thought to be an extra layer of security for your ESXi hosts. What it really does is retrict who can login to the host and from where. Under normal vSphere operations, an ESXi host is managed by vCenter. However any user with the root password or a local account can connect directly to the host with the vSphere client. Since the root account it often known by more than one person, configuration changes made by "root" cannot be traced back to a specific individual. Lockdown modes restricts logins by all users from the vSphere client and from all users except root on the console. This forces all users to login to vCenter using Active Directory credentials in order to modify host settings and creates a record of who modified host settings and when. Note: root can still login to the local console when lockdown mode is enabled. This constitutes a change in behavior from previous versions of ESXi.</li>
	<li><a href="http://kb.vmware.com/kb/1008077">Official VMware documentation</a></li>
</ul>
</li>
	<li>Guideline Title: Do not provide root/administrator level access to CIM-based hardware monitoring tools or other 3rd party applications
<ul>
	<li>Title: limit-cim-access</li>
	<li>Discussion: CIM modules are commonly used to monitor ESXi host hardware and are provided by vendors such as Cisco, Dell, and HP. These modules have the capability of creating additional users on ESXi hosts and these users should only be given necessary permissions for monitoring. Avoid granting root permissions if it can be avoided.</li>
	<li><a href="http://pubs.vmware.com/vsphere-50/topic/com.vmware.cimsdk.smashpg.doc_50/CIM_SMASH_PG_Use_Cases.5.1.html">Official VMware documentation</a></li>
</ul>
</li>
	<li>Guideline Title: Remove keys from SSH authorized_keys file
<ul>
	<li>Title: remove-authorized-keys</li>
	<li>Discussion: We stated earlier that SSH is a great way to access a command line for a remote system securely and easily. But SSH access can get even easier - by using SSL key pairs. When a user generates an SSL key pair, they can choose to paste the contens of their public certificate into the /etc/ssh/keys-root/authorized_keys directory. When they open an SSH session, the ESXi host will issue a challenge encrypted with the stored public key. If the user is on a comptuer that stores the matching private key, the challenge can be decrypted and the user is allowed to logon without entering a password. Monitor the authorized_keys file regularly to ensure that no one has added their public key as a trusted SSH key.</li>
	<li><a href="http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.security.doc_50/GUID-392ADDE9-FD3B-49A2-BF64-4ACBB60EB149.html">Official VMware documentation</a></li>
</ul>
</li>
	<li>Guideline Title: Set a timeout for the ESXi Shell to automatically disable idle sessions after a predetermined period
<ul>
	<li>Title: set-shell-timeout</li>
	<li>Discussion: SSH (even when normally disabled and used sparingly only for troubleshooting) should be configured to end idle sessions. This is the ESXi equivalent of a password-protected screensaver policy for sysadmin workstations.</li>
	<li><a href="http://kb.vmware.com/kb/2004746">Official VMware documentation</a></li>
</ul>
</li>
</ul>