If you're just joining us, I'm blogging my way through the <a href="http://communities.vmware.com/docs/DOC-19605">VMware vSphere 5.0 Hardening Guide</a>. The preceding posts, <a href="http://egroup.jasonmangone.com/vsphere-5-0-hardening-guide-discussion-part-1">one</a> and <a href="http://egroup.jasonmangone.com/vsphere-5-0-hardening-guide-discussion-part-2">two</a>, are also available. Today's post discusses self-signed certificates, the DCUI console, and the memorable ESXi shell. Let's dive in!
<ul>
	<li>Guideline Title: Enable SSL for NFC
<ul>
	<li>Title: enable-nfc-ssl</li>
	<li>Discussion: NFC (Network File Copy) is used to copy or migrate VMs between ESXi hosts. The vulnerability being addressed here is network traffic sniffing. If an attacker sniffed NFC traffic as it was being used to ship an entire VM, they would get an effective duplicate of your entire virtual server. Normally turning SSL on here would be an easy decision to recommend, but in this case, VMware's guidance on this issue is that NFC over SSL between ESXi hosts "has ... not been extensively tested and so may cause HA and other operations to fail in certain circumstances." Ouch. We'll keep our eye on this one and hope that NFC over SSL gets more testing in the future. In the meantime, make sure your vSphere management networks and VLANs are sufficiently isolated as a partial mitigation.</li>
	<li><a href="http://kb.vmware.com/kb/2010332">Official VMware documentation</a></li>
</ul>
</li>
	<li>Guideline Title:  Do not use default self-signed certificates for ESXi communication
<ul>
	<li>Title: esxi-no-self-signed-certs</li>
	<li>Discussion: This hardening guidance is written towards vSphere, but it's always good guidance for any system that uses encryption, even plain ol' Windows Remote Desktop! Wikipedia has a <a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">detailed explanation of man-in-the-middle attacks</a>, but here's the gist: whenever you choose to connect to a server with an unverified SSL certificate, you have no certainty that your encrypted SSL tunnel reaches all the way to the server you're talking to. It's possible that your traffic is being intercepted, decrypted, stored, re-encrypted, and sent to its destination - all without you or the server you're connecting to being aware your traffic was intercepted. Self-signed SSL certs are generic and hard to distinguish from each other. They also lose the benefit of having a Certificate Authority confirm the validity of the cert. The solution is always replace default/vendor certificates on all network endpoints with certs issued by a commercial or organizational Certificate Authority.</li>
	<li><a href="http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.solutions.doc_50/GUID-37AAEDFE-EF2E-45FC-B0C6-44841E4FB302.html">VMware Official documentation</a></li>
</ul>
</li>
	<li>Guideline Title: Prevent unintended use of dvfilter network APIs
<ul>
	<li>Title: verify-dvfilter-bind</li>
	<li>Discussion: The dvfilter network APIs are part of the larger <a href="http://blogs.vmware.com/vcloud/2010/04/what-actually-is-vmsafe-and-the-vmsafe-api.html">VMsafe API</a> and they allow VMware partners to develop virtual security appliances to control the behavior of guest virtual machines. These virtual appliances have the benefit of simplifying guest VM configuration while increasing the overall security of your environment. Some great examples of this include <a href="http://www.trendmicro.com/us/enterprise/cloud-solutions/deep-security/index.html">Trend Micro Deep Security</a>, the <a href="http://www.cisco.com/en/US/products/ps11208/index.html">Cisco Virtual Security Gateway</a>, and the <a href="http://www.juniper.net/us/en/products-services/software/security/vgw-series/">Juniper Virtual Gateway</a>. These appliances allow you to manage firewalls around your VMs as easily as dragging and dropping VMs in vCenter, enabling secure VM isolation (e.g. "DEV servers can't talk to PROD servers") but without sacrificing any ease of management (one of the reasons we virtualized everything in the first place, right?) These virtual security appliances using the dvfilter APIs receive privileged access to other guest VM network traffic. If you're not using any security appliances that leverage these APIs, you'll want to confirm they're not in use to prevent a malicious VM from receiving the data instead.</li>
	<li>No official http://www.vmware.com/go/vmsafe/</li>
</ul>
</li>
	<li>Guideline Title: Disable DCUI to prevent local administrative control</li>
	<li>Title: disable-dcui</li>
	<li>Discussion: <strong>NOTE: This is only recommended by VMware for the most secure environments. </strong>The DCUI is the name of the service that runs the gray and yellow console screen we all see when we first install ESXi and then promptly forget exists. This service can be stopped (and configured to not auto-start) which prevents any operations from occurring at the console or over a KVM.


allows for low-level host configuration such as configuring IP address, hostname and root password as well as diagnostic capabilities such as enabling the ESXi shell, viewing log files, restarting agents, and resetting configurations. Actions performed from the DCUI are not tracked by vCenter Server. Even if Lockdown Mode is enabled, someone with the root password can perform administrative tasks in the DCUI bypassing RBAC and auditing controls provided through vCenter. DCUI access can be disabled. Disabling it prevents all local activity and thus forces actions to be performed in vCenter Server where they can be centrally audited and monitored. 1 Parameter From the vSphere Client, select the host and select "Configuration -&gt; Security Profile". In the services section select “Properties". Select "Direct Console UI" and click “Options”. From the pop-up stop the DCUI service and set the startup policy to "start and stop manually". DCUI access can also be configured using APIs and PowerCLI as well as with Host Profiles. N/A N/A Stopped Modify No TBD</li>
	<li>disable-esxi-shell vSphere 5.0 ESXI Console Disable ESXi Shell unless needed for diagnostics or troubleshooting. ESXi Shell is an interactive command line environment available from the DCUI or remotely via SSH. Access to this mode requires the root password of the server. The ESXi Shell can be turned on and off for individual hosts. Activities performed from the ESXi Shell bypass vCenter RBAC and audit controls. The ESXi shell should only be turned on when needed to troubleshoot/resolve problems that cannot be fixed through the vSphere client or vCLI/PowerCLI. 1,2,3 Parameter From the DCUI: select "Troubleshooting Options" from the main menu and select "Enable ESXi Shell". From the vSphere Client, select the host then select "Configuration -&gt; Security Profiles". In the Services section select "Properties". Select the "ESXi Shell" and click Options. Stop the ESXi Shell and select the option to "Start and stop manually". Note: A host warning is displayed in the vSphere client when the ESXi Shell is enabled. N/A N/A Stopped Modify Yes http://kb.vmware.com/kb/1017910</li>
</ul>