Virtualization Pro

Nov 3 2008   6:52PM GMT

VMware ESXi security review: Firewall, please

Texiwill Edward Haletky Profile: Texiwill

VMware ESXi may have a smaller footprint than VMware ESX, but the pro-security theory behind the skinny ESX version may be defunct given the lack of ability to create a Defense in Depth strategy around the hypervisor. As is, I suggest you consider ESXi a safe hypervisor only when behind a firewall.

VMware touts ESXi as being more secure by having less of an attack footprint, but it is missing the most important feature of modern operating systems: The ability to build a strategy to protect the system from those reaching it and users gaining access to those things to which they are not authorized, currently known in the IT world as Defense in Depth.

Defense in Depth is more than just the availability of a packet filtering firewall, a la VMware ESX’s iptables-based firewall. It is the ability to control when and from where users can log in, and how they can access or view information on the system as well as audit all actions within the system for later perusal or immediate notification of unauthorized access to data or the system. Defense in Depth often starts with the use of a directory service as a centralized management point for all users.

VMware ESXi v3.x is missing all of these capabilities. Directory services are not supported within the VMware ESXi management appliance, there is no ability to audit actions that take place while on the management appliance, there is no control of when or how a user can access the appliance, and most importantly there is no built in firewall.

All of this begs the question: does ESX’s smaller footprint really offer a more secure hypervisor? From the network facing view, its attack surface is limited but not as much as you would expect. What a user can do or access once on the system is also limited, but also not as much as you would expect.

Network daemons almost the same as ESX, minus default SSH

From the network perspective, all the normal daemons that are available for VMware ESX are also available for VMware ESXi: vmware-hostd daemon, cimserver, time daemon, and webAccess.  What is missing by default is SSH access, which most ESXi users enable immediately. The ability to start most other services on the system is also missing. In other words it has nearly the same network daemons running by default that ESX does.

The major difference is that you can no longer log directly into the ESXi box without degrading your security first, in other words without enabling the dropbear SSH server. This does not need to happen and should not according to VMware.

Management of ESXi is performed by either direct access via Remote Command Line Interface (RCLI), the VMware Infrastructure Client (VI Client) and VMware webAccess or by going through VirtualCenter.  Each of these use SSL in order to encrypt and protect all traffic from the workstation and ESXi host. These are the same tools you can use to manage ESX and, as such, share all the weaknesses and strengths. All administrative access via these tools is performed through the vpxuser account which in turn runs many commands as the root user. This is no different than what ESX does. If you go through VirtualCenter, however, you can gain the benefits and disadvantages of using a directory service, but this is not the case when going direct to ESXi.

Possible split-brain authentication

The largest security difference as discussed above is that there is no Defense in Depth, and that once you break the shell by enabling SSH you now run into possible split-brain authentication and authorization that did not exist before. This implies that unprivileged users can gain access to data which they do not own and should not be able to access or even see.

Lastly, since ESXi has no Defense in Depth, its management appliance belongs behind a firewall of its own. This is a step backward in my opinion, and hopefully will be fixed in future releases!

2  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • VMRob
    Hey Edward....Rob here. I want to make an important point here in that while people are using the unsupported tech support shell, they are making the [B]conscious decision[/B] to make the trade-off between security and convenience. It absolutely could have better defense in depth built in, but if security is a primary concern for the folks enabling the dropbear ssh server, then they would not be doing this in the first place. As a matter of fact, the recommended security best practices is to completely disable the shell as outlined in the following kb article: [A href=""] Note that when disabled, it requires a change to the advanced options of the host and then a reboot is required to re-enable tech support mode. By following this best practice, they can mitigate the need for the controls you mention. So while I don't disagree that these controls would be useful and important to have, they are not there today so the best option from a security perspective is to disable the shell and only use the provided and supported management options.
    0 pointsBadges:
  • MikeDiPetrillo
    I have to agree with VMRob on this one. All you have to do is disable the *unsupported* technical support mode and then you force people to use Virtual Center where everything is logged, authenticated, and has access controls. Simple solution to the problems you're describing above. It's all in the implementation. Of course, like you laid out above, you could also stick the box behind a firewall.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: