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.
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.
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
When you add a host to vCenter
Server, and vCenter Server already trusts the host's SSL certificate, VPX_HOST.EXPECTED_SSL_THUMBPRINT
is not populated in the vCenter Server database. vSphere HA obtains the host's
SSL thumbprint from this field in the database. Without the thumbprint, you
cannot enable vSphere HA.
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