VMware’s ESX Hardening Guideline Falls Far Short of ‘Secure’

As I’ve discussed in previous blogs on securityfor virtual environments, there is a severe lack of comprehensive guidance available on how to secure virtual servers and the parts of an IT infrastructure they touch.

Non-vendor organizations offer some help; more specific documentation is available from the vendors themselves. Even that guidance is somewhat lacking, however.

VMware has several white papers on security, most notable the VI3 Security Hardening guideline and DMZ Virtualization With VI3.

The DMZ paper is useful. But the VI3 Hardening Guideline, which is the place most virtual server managers would start to find security information, falls seriously short of the goal of helping to harden an entire virtual infrastructure or even a single VMware ESX system.

The VI3 Hardening Guideline suffers from the same issues I described in my blog on the CISecurity Benchmark. It gives lip service to the hardening of virtual machines, but most of the discussion is on how to use the remote logging service, and isolate the VM Network.

It does not cover the ability of a virtual machine to isolate itself and the data it protects—abilities with the potential to disallow information leakage to someone who has access to the virtual infrastructure but not to the specific VM being protected.

The discussion on the service console reads like a Linux hardening guideline but is already missing many of the items mentioned in the CISecurity Benchmark.

It further states you should only use the VI Client to access your host (physical) systems. As we all know, this is not only impossible, it fails to address the split-brain authentication and authorization problem of a system with three three separate login facilities.

Furthermore it says you should use a directory service like Active Directory but does not discuss how to structure permissions to disable access to critical files which could contain the root password.

Access to root passwords is possible only if configuration files hold the wrong permissions. While the guide does recommend that IT managers monitor the configuration files to make sure the correct permissions have been granted and have not been changed, it doesn’t say what the permissions should be in the first place.

The default setup is, not surprisingly, inadequate. It allows for quite a bit of information leakage.

The guide does start to discuss security of items outside the service console including storage, and networking.

However, the storage discussions focus only on iSCSI, and are misleading even then.

For iSCSI to work within VI3, the service console has to be involved in some way. Hence the statement in the white paper that it’s necessary to completely isolate an iSCSI network is incorrect. It cannot be 100% isolated.

There is also no mention of disabling webAccess, which has known security issues, or even how to minimize the impact of those weaknesses.

In the section about virtual networking, there is no mention of the need to isolate networks or even why to isolate them. The guide is missing quite a bit of information on virtual networking. The DMZ paper fills some of that gap, but the need to do so is alarming.

The VI3 guide contains some discussion of basic security for the Virtual Center Server, at least on how to enable the use of different certificates.

It doesn’t cover making these changes within VirtualCenter 2.5, though it does reference another white paper to do this, leaving it up to the reader to determine how to properly build OpenSSL to secure communications, what version to use, or whether or how to use it on a Linux system.

There is no mention of whether the OpenSSL installed on ESX will even work. Nor does it discuss how to make this change within ESXi.

There is much more VMware could go into on security outside the service console, but the guide falls short.

The only difference between the CISecurity Benchmark and the VI3 Hardening guide is that the guide covers more of the entire environment.

The biggest lack is how to apply these guidelines to ESXi. Something has to be done to secure ESXi, but there is no mention of what to do or how to do it.

The Tripwire Configcheck tool is based on the VI3 Hardening Guide and is a good start. However there is much more to do. Do not let this give you a false sense of security. Next we will look at the US Government DISA/STIG security guidelines.

Virtualization expert Edward L. Haletky is the author of “VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers,” Pearson Education (2008.) He recently left Hewlett-Packard, where he worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Haletky owns AstroArch Consulting, providing virtualization, security, and network consulting and development. Haletky is also a champion and moderator for the VMware discussion forums, providing answers to security and configuration questions.