Hardening VMware vSphere Security and the ESX v4 Console Operating System with Centrify

Monday, May 24, 2010

Recently VMware published its official release of the vSphere 4.0 Security Hardening Guide. I was pleased to see that Centrify was the only third-party identity management vendor called out by VMware to "provide tighter integration with Active Directory" when it recommends to use a directory service product for authentication for the ESX Service Console. While Centrify was called out vis a vis the security requirements around Console OS password policies, in looking at the hardening guide it became readily apparent that the Centrify Suite can address a wide range of vSphere hardening requirements for enterprises, and this blog post gives an example of some of the additional value add Centrify can provide.

[For brevity sake and to narrow down the examples, I am going to focus simply on the ESX Service Console specific hardening requirements that VMware published. This is not to say that Centrify can't help for example in say with a large set of the Virtual Networking set of requirements via our DirectSecure technology that does isolation, or some of the other vSphere requirements. ]

As a way of background, per Wikipedia the ESX Service Console is a "general purpose operating system most significantly used as the bootstrap for the VMware kernel, vmkernel, and secondarily used as a management interface. Both of these Console Operating System functions are being deprecated as VMware migrates to exclusively the 'embedded' ESX model, current version being ESXi."

While customers are migrating to ESXi, the reality is that the vast majority of VMware customers use ESX and will continue to use ESX for a long period of time and therefore need to secure that environment. This was evidenced by our recent virtualization security survey of 500 IT personnel which found customers have deployed ESX nearly 2x that of ESXi (see chart below of hypervisor deployments), so securing the ESX Service Console should be a concern, and VMware obviously thinks so as well hence a meaty section dedicated to hardening the Console Operating System in the vSphere hardening guide.

virtualization security survey of 500 IT personnel which found customers have deployed ESX nearly 2x that of ESXi

Specific to the Service Console, I should also point that the vSphere Hardening Guide makes this point: "Although the ESX Service Console is derived from Red Hat Linux, it is a unique operating platform that should not be managed as a true Linux host. As such, the Service Console should be managed according to VMware and other virtualization security best practices, which may differ from many well-known Linux-focused best practices in some ways." I definitely agree to that sentiment.

So now that we have the background info completed, here are some of the ways that Centrify can help harden the ESX Service Console. I am starting on page 90 of the PDF and quickly giving you a feel for the breadth of how Centrify can assist ...

[I should also mention the categories of security hardening requirements for the ESX Service are the following:

CON: Console OS Networks
COM: Console OS Management
COP: Console OS Password Policies
COL: Console OS Logging
COH: Console OS Hardening
COA: Console OS Access

that are referenced via the abbreviations below]

CON01 - Ensure ESX Firewall is configured to High Security (page 90)

They require checking to make sure that esxcfg-firewall is set properly. A Centrify DirectControl group policy can be configured to push an iptables firewall policy to the ESX host once joined to AD to enforce a much more specific firewall policy based on the current network. While we have not yet tested it, one should be able to leverage our DirectSecure in order to protect specific interfaces by requiring authentication from the remote host prior to access.

CON02: Limit network access to applications and services (page 91)

Same answer as the one above. It is much more important to define a specific firewall policy based on system usage.

CON03: Do not run NFS or NIS clients in the Service Console (page 91)

Centrify eliminates the need to use NIS by joining the system to Active Directory in order to provide centralized name services to the operating system to enable authorized AD Users to login.

COM03: Do Not Manage the Service Console as a Red Hat Linux Host (page 93)

Centrify DirectAuthorize provides Role Based Access and Privileges in order to control the actions of authorized users. The policy should be defined for ESX admins to only allow execution of esxcfg-* commands as required by the specific roles within your organization.

COM04: Use vSphere Client and vCenter to Administer the Hosts Instead of Service Console (page 94)

Centrify DirectAuthorize should be used to grant Service Console login permissions based on the user's Role where login is required for the specific job duties.

COP01: Use a Directory Service for Authentication (page 95)

Centrify DirectControl is designed specifically to provide Active Directory integration and user login functions for ESX 3.5-4.x Server. It is in this section that we get the shout-out from VMware: "It is also possible to use third-party packages, such as Winbind or Centrify, to provide tighter integration with Active Directory. Consult the documentation for those solutions for guidance on how to deploy them securely."

COP02: Establish a Password Policy for Password Complexity (page 96)

Centrify integrates the ESX Server into Active Directory for all authentication functions including management of the root password of the ESX Server. This integration will enforce all Active Directory defined password policies for user accounts authorized to login to the ESX Server.

COP03: Establish a Password Policy for Password History (page 97)

Same as above.

COP04: Establish a Maximum Password Aging Policy (page 98)

Same as above.

COP05: Establish a Password Policy for Minimum Days Before a Password is Changed (page 98)

Same as above.

COL01: Configure syslog logging (page 101)

A Centrify DirectControl group policy can be used to enforce a common syslog.conf configuration file across all ESX Servers joined to Active Directory.

COL02: Configure NTP time synchronization (page 102)

Centrify DirectControl will establish the Active Directory Domain Controller infrastructure as the authoritative time master for the ESX Server once joined to Active Directory.

COA02: Require Authentication for Single User Mode (page 105)

A Centrify DirectControl group policy can enforce a common configuration of the /etc/inittab file to ensure it contains the required entry.

COA03: Ensure root access via SSH is disabled (page 106)

A Centrify DirectControl group policy for SSH has a configuration setting to control root login, this should be set to deny root login over ssh.

COA04: Disallow Console root Login (page 107)

A Centrify DirectControl group policy can be configured to execute the commands required to ensure that root cannot login on the console.

COA05: Limit access to the su command (page 108)

The Centrify Suite configuration by default is to only allow end user login and to lock the root account so that administrators will not su and will only be given permissions to run specific commands based on their Role through DirectAuthorize. This is similar to using sudo, with the primary advantage of having a centrally defined policy that is dynamically updated upon login to ensure the most accurate rights are granted or denied. Additionally, DirectAuthorize provides additional facilities to time limit these privileges in order to facilitate temporary privileges that are periodically required during the support of production systems.

COA06: Configure and use sudo to control administrative access (page 109)

Same as above. I would also recommend DirectAudit to audit these privileged users' access to the Console.

I will stop here, but hopefully you get a feel for the power of the Centrify Suite to help you lockdown vSphere. The key to what Centrify offers is that it goes well beyond integrating ESX and Linux-based guests with Active Directory from an authentication perspective but even more importantly helps you control privileged access management to the underlying hypervisor.

[Special thanks to David McNeely for helping me greatly on this blog post.]