VMware's ESX Hardening Guideline Falls Far Short of 'Secure'
VMware offers several guides to how to harden virtual servers, but the primary ones say little about how to deal with some of the most critical issues.
Tue, July 08, 2008
CIO — As I've discussed in previous blogs on security for 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.
