Security Manager's Journal: Getting it all 'virtually' right

Computerworld - The results from our server virtualization assessment are back, and we failed miserably. There were a few bright spots, but mostly our implementation was found wanting. Fortunately, our mistakes can be remediated.

The report included more than a dozen findings, but I'll discuss only the most significant ones.

As I reported earlier, IT deployed a fairly significant VMware ESX implementation without telling me. When I found out, I called in a consultant to conduct an assessment.

His first finding concerned the VMware service consoles, which start up and administer the virtual machines associated with a single ESX server. Our engineers placed the IP addresses for the consoles on the same network used by the VMs. That's not good, since the consoles are the single point from which servers can be started and administered.

Worse, administrators were sharing a single administrative account for the consoles. They should have known better, and I told them as much when I instructed them to create individual accounts. I also had our network team create a new virtual LAN, and we created new IP addresses for the service consoles. Then we devised some firewall rules to control access.

Our next concern was VirtualCenter, which centrally manages all of the ESX servers. It allows administration of all the virtual servers from a single interface. The potential damage that a hacker could inflict if he had control of the VirtualCenter server is frightening to think of, but even more frightening is that it was not properly patched. What's more, it was sitting on a VLAN along with some arbitrary servers, and there were insufficient controls for delineating administrative duties between the help desk, which we outsource to India, and our Level 3 engineers at corporate headquarters in the U.S.

Another change of IP address was called for, and we placed the server on a different management VLAN, with the appropriate firewall rules to limit access. I also had the team update patches and create a process to ensure that the server would be patched on a more regular basis than other servers.

Less-critical findings included recommendations that we create warning banners, disable root access via Secure Shell (SSH) and use sudo for controlled administrative access. In addition, the team will need to properly configure syslogd to send system logs to our syslog server; disable SSH Version 1, which is plagued with vulnerabilities; minimize the number of unneeded services running on the ESX server, which is really just a stripped-down version of Red Hat Linux; and make some modifications to the kernel to prevent denial-of-service attacks.