Saturday, May 26, 2012

Securing ESXi Host with Certificates - Obj 7.1 Part 1



I am covering here how to secure ESXi host. This include dealing with certificates (both default and CA assigned) and also some guidelines on what are the minimum steps you need to take to secure the VMware environment and make it a trusted one.


Generate New Certificates for ESXi

You typically generate new certificates only if you change the host name or accidentally delete the certificate. Under certain circumstances, you might be required to force the host to generate new certificates.

1          Log in to the ESXi Shell and acquire root privileges.

2          In the directory /etc/vmware/ssl, back up any existing certificates by renaming them
using the following commands.

        mv rui.crt orig.rui.crt
        mv rui.key orig.rui.key

Note:   If you are regenerating certificates because you have deleted them, this step is
unnecessary.

3          Run the command /sbin/generate-certificates to generate new certificates.

4          Restart the host after you install the new certificate.
Alternatively, you can put the host into maintenance mode, install the new certificate, and then use the Direct Console User Interface (DCUI) to restart the management agents.

5          Confirm that the host successfully generated new certificates by using the following command and comparing the time stamps of the new certificate files with orig.rui.crt and orig.rui.key.
           
        ls –la

Replace a Default Host Certificate with a CA-Signed Certificate

The ESXi host uses automatically generated certificates that are created as part of the installation process. These certificates are unique and make it possible to begin using the server, but they are not verifiable and they are not signed by a trusted, well-known certificate authority (CA).

Using default certificates might not comply with the security policy of your organization. If you require a certificate from a trusted certificate authority, you can replace the default certificate.

Note:   If the host has Verify Certificates enabled, replacing the default certificate might cause vCenter Server to stop managing the host. If the new certificate is not verifiable by vCenter Server, you must reconnect the host using the vSphere Client.

ESXi supports only X.509 certificates to encrypt session information sent over SSL connections between server and client components.

Note    For information about replacing default certificates on a vCenter Server system, see the vSphere Examples and Scenarios documentation.

Prerequisites

All file transfers and other communications occur over a secure HTTPS session. The user used to authenticate the session must have the privilege Host.Config.AdvancedConfig on the host. For more information on ESXi privileges, see About Users, Groups, Permissions, and Roles.

Procedure

1 Log in to the ESXi Shell and acquire root privileges.

2 In the directory /etc/vmware/ssl, rename the existing certificates using the following commands.

               mv rui.crt orig.rui.crt
               mv rui.key orig.rui.key


3 Copy the new certificate and key to /etc/vmware/ssl.

4 Rename the new certificate and key to rui.crt and rui.key.

5 Restart the host after you install the new certificate.

Alternatively, you can put the host into maintenance mode, install the new certificate, and then use the Direct Console User Interface (DCUI) to restart the management agents.

Encryption and Security Certificates for ESXi and vCenter Server

ESXi and vCenter Server support standard X.509 version 3 (X.509v3) certificates to encrypt session information sent over Secure Socket Layer (SSL) protocol connections between components. If SSL is enabled, data is private, protected, and cannot be modified in transit without detection.

All network traffic is encrypted as long as the following conditions are true:
              
You did not change the Web proxy service to allow unencrypted traffic for the port.

Your firewall is configured for medium or high security.

Certificate checking is enabled by default and SSL certificates are used to encrypt network traffic. However, ESXi and vCenter Server use automatically generated certificates that are created as part of the installation process and stored on the server system. These certificates are unique and make it possible to begin using the server, but they are not verifiable and are not signed by a trusted-well-known certificate authority (CA). These default certificates are vulnerable to possible man-in-the-middle attacks.

To receive the full benefit of certificate checking, particularly if you intend to use encrypted remote connections externally, install new certificates that are signed by a valid internal certificate authority or purchase a certificate from a trusted security authority. Replacing vCenter Server certificates is described in the vSphere Examples and Scenarios documentation.

Note:      If the self-signed certificate is used, clients receive a warning about the certificate. To address this issue, install a certificate that is signed by a recognized certificate authority. If CA-signed certificates are not installed, all communication between vCenter Server and vSphere Clients is encrypted using a self-signed certificate. These certificates do not provide the authentication security you might need in a production environment.

The certificate consists of two files: the certificate itself (rui.crt) and the private-key file (rui.key).
Default Location of ESXi and vCenter Server Certificate Files

Server                                                   Location____________________________________

ESXi 5.0                                               /etc/vmware/ssl/

vCenter Server (Windows 2008)           C:\Program Data\VMware\VMware VirtualCenter\SSL

vCenter Server (Windows 2003)           C:\Documents and Settings\All Users\Application
                                                             Data\VMware\VMware VirtualCenter\SSL


General Security Recommendations

To protect the host against unauthorized intrusion and misuse, VMware imposes constraints on several parameters, settings, and activities. You can loosen the constraints to meet your configuration needs, but if you do so, make sure that you are working in a trusted environment and have taken enough other security measures to protect the network as a whole and the devices connected to the host.

Consider the following recommendations when evaluating host security and administration.

             Limit user access.

To improve security, restrict user access to the management interface and enforce access security policies like setting up password restrictions.

The ESXi Shell has privileged access to certain parts of the host. Therefore, provide only trusted users with ESXi Shell login access.

Also, strive to run only the essential processes, services, and agents such as virus checkers, and virtual machine backups.

            Use the vSphere Client to administer your ESXi hosts.

Whenever possible, use the vSphere Client or a third-party network management tool to administer your ESXi hosts instead of working though the command-line interface as the root user. Using the vSphere Client lets you limit the accounts with access to the ESXi Shell, safely delegate responsibilities, and set up roles that prevent administrators and users from using capabilities they do not need.

             Use only VMware sources to upgrade ESXi components.

The host runs a variety of third-party packages to support management interfaces or tasks that you must perform. VMware does not support upgrading these packages from anything other than a VMware source. If you use a download or patch from another source, you might compromise management interface security or functions. Regularly check third-party vendor sites and the VMware knowledge base for security alerts.

               In addition to implementing the firewall, risks to the hosts are mitigated using other methods.

             ESXi runs only services essential to managing its functions, and the distribution is limited to the features required to run ESXi.

             By default, all ports not specifically required for management access to the host are closed. You must specifically open ports if you need additional services.

             By default, weak ciphers are disabled and all communications from clients are secured by SSL. The exact algorithms used for securing the channel depend on the SSL handshake. Default certificates created on ESXi use SHA-1 with RSA encryption as the signature algorithm.

             The Tomcat Web service, used internally by ESXi to support access by Web clients, has been modified to run only those functions required for administration and monitoring by a Web client. As a result, ESXi is not vulnerable to the Tomcat security issues reported in broader use.

             VMware monitors all security alerts that could affect ESXi security and, if needed, issues a security patch.

             Insecure services such as FTP and Telnet are not installed, and the ports for these services are closed by default. Because more secure services such as SSH and SFTP are easily available, always avoid using these insecure services in favor of their safer alternatives. If you must use insecure services and have implemented sufficient protection for the host, you must explicitly open ports to support them.

Cannot Configure vSphere HA When Using Custom SSL Certificates

After you install custom SSL certificates, attempts to enable vSphere High Availability (HA) fail.

Problem

When you attempt to enable vSphere HA on a host with custom SSL certificates installed, the following error message appears: vSphere HA cannot be configured on this host because its SSL thumbprint has not been verified.

Cause


Solution

1
In the vSphere Client, disconnect the host that has custom SSL certificates installed.
2
Reconnect the host to vCenter Server.
3
Accept the host's SSL certificate.
4
Enable vSphere HA on the host.

For more information on other security related issue, refer the online documentation and search the particular
topic.

There are other areas I could have covered here such as ESXi lock down mode,  authenticalion proxy, 
hardening virtual machines etc. etc. but it will be adding little complexity in the above subjects so may be 
later.

 

No comments:

Post a Comment