Just ran across this article on The Lone Sysadmin blog along with some comments from readers and figured that I would post here in reference to it seeing as I work for Tripwire and am pretty close the development of the ConfigCheck tool and the full Tripwire Enterprise solutions.
Bob asks the question: “Is ESX a Linux distro or an appliance?” we’ll.. that depends on the version you are running, if you are running ESX 3.0 or 3.5 then it’s really more of a linux distro since it has a service console and a bunch of linux binaries. If you are running the newest ESX 3i (also called ESXi sometimes) then it is really more of an appliance since there is no service console and hence no method of directly connecting to the system like you can with 3.0/3.5. In fact I believe that while you can install it on a standard disk based server (I have, it’s quick and easy) it is really intended to be OEM’d on a chip from vendors such as Dell and HP.
So.. back to the real issue. If you treat ESX 3.0/3.5 like an appliance and take a ‘hands-off’ approach then over time you will have an insecure hypervisor. VirtualCenter has an update manager plug-in that helps you keep the ESX hosts patched so that is one method of keeping it up to date.. at least in-so-far as system binaries go. However there is nothing in VC that addresses incorrect or insecure configurations. That is where ConfigCheck comes in and provides an easy means to spot check your ESX server configurations and provide remediation guidance. This is important since there are settings that are not set securely via a standard ESX installation. Heck.. this is true of most software installations as they generally tend towards more flexible / open access and it is up to the enduser to lock them down, the same is true of ESX.
Another question was: “Will it mess up something in the future when a patch from VMware assumes something about my environment that isn’t true because I’ve changed it?” I don’t think so and that is simply because ConfigCheck is based entirely on the VMware hardening guidelines from VMware themselves. Theoretically a future patch might have an issue since rapid change is the norm in our industry (and right now especially true of VMW) but then again we will always be subject to possibilities like that. In any case I really can’t imagine you going sideways by making sure your ESX systems are configured to the Vendors (VMware’s) own hardening guidelines.
As one person commented on Bob’s blog though, if you are testing servers that are purely in a controlled test/dev environment then you may indeed decide not to fully harden the ESX servers since you do give up some flexibility (the age old security vs convenience issue) but for ESX servers hosting production applications, you will definitely want to fully harden them.