Best Practices for Securing VMware ESX Server
As VMware ESX is loaded directly on hardware and is its own virtualization operating system, there are a number of factors to consider when securing it. While, due to its design architecture, ESX is inherently secure, there are still a number of security factors to consider. In this article we will cover the vulnerability points of ESX and how you can ensure that your ESX Servers are as secure as they can be.
Where is VMware ESX Server Vulnerable?
On a traditional server, you are only concerned with locking down the server OS. That OS could be Linux or Windows. Windows has, of course, been the favorite for security attacks so much of our time is spent securing it. So what if you put VMware ESX into this picture?
With VMware ESX being loaded on top of the server hardware, there are a few points of immediate concern:
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
- the VMKernel & its virtualization layer
- the VMware ESX Service console (based on Red Hat Linux Enterprise)
These two pieces are two very distinct parts of VMware ESX. VMware has periodically released patches for both of these different components although you probably just thought of them as “ESX patches”.
Concerning #1, the VMKernel and its virtualization layer is extremely secure. The Guest machines have hardware isolation in place and it seems impossible that a guest VM could somehow compromise the security of the host virtualization layer.
As for #2, with the services console being based on Linux, it will be affected by most of the Red Hat Linux vulnerabilities. Because the service console is a Linux OS with a direct link to the VMKernel, I will focus on securing the service console.
But first, what many admin’s forget about once they have virtualization software in place, is the underlying virtual guest operating systems. Because it is so easy to add a new server (in just seconds), it is easy to forget to add those servers to your patch distribution system (like SMS or WSUS), add anti-virus software, install the latest service packs, and or tweak security settings. In my opinion, the insecurity of those underlying virtual guest operating systems is the single largest source of concern for the security of your ESX servers. Fortunately, because ESX separates the guests from the host, if a guest is compromised it is unlikely it could affect the host except to perhaps take up more network bandwidth or server resources. My point being, don’t forget to secure your underlying Windows and Linux virtual guest operating systems!
With that, let’s get to securing your ESX Server service console…
Keep your ESX Service console patched
Just like any OS, ESX Server will have security patches that need to be deployed. Over half of these patches are related to the Linux-based OS inside the service console. Currently, this is done with esxupdate. This is a command line tool that is helpful but not as automated as it could be. For information on how to use esxupdate, see this whitepaper and checkout Scott Lowe’s Blog where he covers the process of applying patches with esxupdate.
There are two tools you should keep in mind for deploying patches:
- VMware will be introducing a new automated patch management application called “Update Manager” in ESX version 3.1.
- Since VMware’s automated patch management tool isn’t out yet, you should also take a look at the VMTS Patch Management application. I talked about this tool in my 3rd Party Tools available for VMware ESX article. This is a centralized automated patch management system for VMware ESX. What do you have to lose? VMTS Patch Management is free. Here is a screenshot of this application: For the latest ESX server security patches see the VMware ESX Patch and Update download site.
Use VMware ESX / Virtual Center Roles
In security circles, they talk about the “principle of lease privilege”. This says that you should not give anyone more security than the minimum security they need to do their job. Fortunately, this is pretty easy to do with VMware ESX. Built into the Virtual center are roles that can be used to give us different levels of security. because Virtual Center uses Windows AD, it is very each to give a user only the access they need to do their job. In fact, with Virtual center, you can assign privileges to users and groups at just about every level of the VC management tree (from Hosts & Clusters, to Data Center, to Cluster, to individual virtual guest servers). To do this, just right-click on the object you want to assign permissions to and click on Add Permission. Here is a graphic of how I assigned myself to be a virtual machine administrator to an individual virtual guest server:
To see who has permissions to what at the various levels of VC, just go to the Permissions tab, like this:
Use the VMware ESX Firewall
The ESX Server built in firewall is installed and enabled by default. That is a good thing. However, many admins who don’t want to deal with configuring the firewall if they install an application on the service console will disable the firewall. You should check to ensure that your ESX Server firewalls are enabled and see what ports are currently allowed through. To do this in VC, go to Configuration -> Security Profile (shown below).
At the service console command line, the firewall is disabled with:
esxcfg-firewall -allowOutgoing esxcfg-firewall -allowIncoming
And re-enabled with:
esxcfg-firewall -BlockIncoming esxcfg-firewall -BlockOutgoing
Consider ESX Server 3i
In my upcoming article, How will VMware ESX Server 3i Change the future of Virtualization, I discuss the new ESX Server 3i (currently in beta). With 3i, the service console is gone, thus reducing ESX Server from vulnerabilities, eliminating many openings of administration that could be exploited, and reducing the number of patches that need to be applied to ESX. Unless you need the Linux-based service console for scripting or application installed inside of, there is no reason not to go to 3i when it is released to manufacturing.
ESX Server 3i will make your ESX Server much more secure.
Advanced VMware ESX Security Hardening
As the service console is based on Red Hat Enterprise Linux, just about everything you can do in Linux to secure and harden your server can be done to the ESX service console. Here are some links to more advanced & additional security tasks that can be done to further harden ESX server:
VMworld 2007 public session video: Security Architecture Design and Hardening VI3
VMworld 2007 public session video: Security in a Virtualized Environment
VMWorld 2006 public presentation: How to Secure VMware ESX
In summary, if you are going to use ESX Server, it is important to secure your service console. Unless you upgrade to the 3i version of ESX, the service console remains as the most vulnerable point of ESX Server. Fortunately, it is not difficult to take steps to secure it. And don’t forget about all of those underlying guest operating systems. Most likely, they will need much more attention than your service console ever will.