- Management and Deployment Data Flow
- Management and Deployment Authentication
- Security of Management and Deployment Network
- Security Issues during Management and Deployment
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Security of Management and Deployment Network
We have discussed how to enable directory services and the need for remote logging of data from all systems on the management and deployment network, and in Chapter 9, "Virtual Networking Security" we discuss the networking constraints of this network. However, it is important to also maintain good encryption using the tools within this network. Many use SSL to pass data back and forth while others use clear-text protocols.
Using SSL
As discussed in Chapter 2, SSL is susceptible to MiTM attacks using certificate injection because the client blindly accepts the certificate given to it. In general, the certificate, if it is a self-signed certificate with a root certificate authority not registered within the system, is checked by a human, and humans are notorious for just wanting to get their job done regardless of security. Part of the use of SSL is to educate users on the features of a good certificate so that they do not make this common mistake.
The other option is to use a set of certificates that you control and maintain based on well-known root certificate authorities. To do this we need to replace the certificates created on the installation of the components of the virtual environment. We will replace these certificates with the ones you received from your certificate authority.
Using Certificates
Certificates contain information about the server to which you are going to connect. This information should be verified either programmatically or by your own eyes and information. How to verify certificates is outside the scope of this book. After the certificate is verified, it is then available for use. There is a second part to the certificate for the server component, and that is a private key to encrypt the traffic. Each certificate must be in the form of a base64 encoded X.509 file, commonly known as a base64 encoded PEM file because of its extension. For more information on these formats, review Appendix D, "Suggested Reading and Useful Links." Also refer to Appendix D if you are unfamiliar with the role of certificates, how they are created, from where to receive them, or how SSL works in general.
Certificate Authority
As explained in Chapter 2, the certificate authority is the important aspect of the securing of data via SSL. If you do not know or trust the certificate authority, how can you trust that there is no man in the middle or that the certificate is not a weak certificate with a well-known key? Well-known certificate authorities such as Verisign and RSA are already well known by all security principals involved. The security principals will be the Web servers, applications, and browsers we will be using to serve up data and access this data. However a self-signed certificate can also be used. A self-signed certificate is one that is created by a certificate authority that is not known. For example, you may get a certificate from a vendor using its own certificate authority with its own root certificate unrelated to the known authorities.
Self-Signed Certificates
Self-signed certificates are not necessarily insecure certificates. However, their use is sort of claiming you are who you are just because you said so. Yet VMware uses self-signed certificates by default. Most of the tools will detect if a certificate is in use, and if they cannot determine the root certificate, they will consider the certificate to be self signed and ask for human intervention to determine if this is acceptable. If you trust the certificate authority, whether it is self-signed or not, the certificate is valid. Some companies use self-signed certificates internally.
The tools that do not ask for human intervention are the VI SDK, RCLI, and VC to ESX connections. These tools do not present to the user a chance to review the certificate and do not programmatically verify much of anything.
Replacing Certificates
Many companies, namely several government agencies, require the replacement of the default certificates with the ones given to them by their certificate authority. How to create a certificate authority is outside the scope of this section, but given a certificate and the public key for the certificate, we will show how to replace the certificates. Because multiple components exist, we will go through each one. It should be noted that we are replacing the certificates on servers and not those for clients, because VMware management tools do not currently support preshared certificates and keys, which is the only real way to prevent a MiTM attack.
Replacing VC Certificates
Replacing the VC certificates will be a very good start if you are using this tool within your environment. If not, I would ignore this particular section. The steps are very straightforward.
First, back up your old certificates, which are located in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL. The two files to back up are rui.crt (the certificate) and rui.key (the private key). A backup can easily be created by renaming these files.
The next step is to upload the new key and certificate files to the directory C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL. Name the new key file to be rui.key and the new certificate to be rui.crt. These names are important to maintain. Also, make sure that the rui.key and your backup of the previous file grant read access to only the System User and the Administrators group. Because this is the private key for the entire vCenter server, it is important to protect appropriately by denying read access by anyone not a system user or within the Administrators group.
The last step is to restart the vCenter service on the host. Replacing virtualization host certificates is the second phase.
Replacing VMware ESX Certificates
The VMware ESX certificates are composed of two files, a key and the base64 encoded X.509 or PEM file (in the following, the PEM file is the rui.crt file).
First back up your old certificates:
cd /etc/vmware/ssl; cp rui.key rui.key.orig; cp rui.crt rui.crt.orig
Next, upload the new key and certificate files using your favorite secure copy tool. Place them in /etc/vmware/ssl and name them rui.key for the key file and rui.crt for the certificate file.
Modify the permissions of the rui.key and rui.key.orig file so that they are readable only by the root user.
/bin/chmod 600 rui.key rui.key.orig
Now restart the hostd and webAccess daemons to use the new certificates.
service mgmt-vmware restart; service vmware-webAccess restart
Replacing VMware ESXi Certificates
The VMware ESXi certificates are composed of two files: a key and the base64 encoded X.509 or PEM file.
First, back up your old certificates using the RCLI supplying the appropriate hostname and username to the following commands:
vifs --server hostname --username username --get rui.crt rui.crt.orig vifs --server hostname --username username --get rui.key rui.key.orig
Next, upload the new key and certificate files using your favorite secure copy tool. Place them in /etc/vmware/ssl and name them rui.key for the key file and rui.crt for the certificate file.
vifs --server hostname --username username --put ssl_crt rui.crt vifs --server hostname --username username --put ssl_key rui.key
Now use the Restart Management Agents option available through the local console, as shown in Figure 6.8.
)
Figure 6.8 ESXi Restart Management Agents menu option
Mitigating SSL MiTM Attacks
The only true way to mitigate a MiTM attack for SSL is to use preshared keys and certificates between the clients and the servers. Unfortunately, this is not possible at the moment because it is not supported within VMware. So that leads us to other options to use preshared keys to alleviate MiTM attacks. None of these options, however, addresses the communication between VC and the VMware ESX or ESXi host. It is extremely important that this communication be behind an administrative firewall.
It is possible for the administrative clients to live on the other side of the firewall, as long as a secure mechanism exists to access VC or the hosts. Preferably, that secure mechanism would be over some form of tunnel. However, because that is not always possible, it is also recommended that the management clients be on the same side of the firewall as the VC server and hosts and that a secure mechanism is used to access the management workstation. VMware has created the VMware Infrastructure Management Appliance to aid in this endeavor. I use an internal VPN built in to my firewall between the production and administrative servers to secure this aspect of my management network.
It is possible to configure VMware vCenter to verify ESX host certificates by using the following within the VIC, use the menu option Administration -> VirtualCenter Management Center Configuration, select the SSL Settings link and check the "Check host certificates" checkbox and click OK.
Using IPsec
One option is the use of IPsec in main mode with preshared certificates to enable an encrypted communication between the management clients and the servers and hosts involved in the work to be done. Often, IPsec implementations switch to aggressive mode when preshared certificates are in use. However, this does require quite a bit of work to configure. Namely, you need to set up a Public Key Infrastructure (PKI) configured for IPsec, including the use of preshared certificates. Without preshared certificates, IPsec is no more secure than SSL. This option will work for clients connecting to VC but not VMware ESX or ESXi.
Using Tunnels
Another option is to use various tunneling or VPN tools that are not IPsec. One of the most commonly used tunnel tools is secure shell (SSH). SSH allows the creation of an encrypted tunnel between one host and another. It does this by allowing you to send packets to various ports on the local host, and then sending these packets over the tunnel to the remote host. As long as you use a preshared key created on the client and stored on the host, this type of tunnel is also secure. The creation of the preshared key differs between each OS. The most common tool to create this is the ssh-keygen tool. The resultant file's contents must be placed within the appropriate file on the host. This will work for VC as well as VMware ESX hosts. Unfortunately, it will not work very well for VMware ESXi because SSH is not enabled, nor should it be enabled.
Using Deployment Servers
One of the largest insecurities is the physical to virtual (P2V) conversion and deployment. In many cases, a P2V will cross security zones—that is, from a production to a virtualization administration network—or even worse, from a DMZ to a virtualization administration network. The solution to this problem is quite simple. Use a P2V helper machine that has access to enough disk space to convert the entire machine. One such use case is a laptop that has been blessed by the security administrators to work within the target security zone—for example, the DMZ. The laptop would contain the VMware Converter tool and enough external storage (USB, eSATA, FireWire, and so on) storage to contain the entire virtual machine.
After the conversion takes place, detach the USB or FireWire storage and move it to the virtual environment management security zone. From there you would again power up the converter and import the VM into the appropriate virtualization host with the proper network connections to run within the appropriate security zone that was already prepared within the host—in our example, a DMZ.
This approach has several advantages: first, there is no network involved that would cross security zones, and second, because the resultant VM will not be powered on until it is back within the appropriate security zone, there is no chance of contamination from one security zone to another. Contamination could be considered a change in DHCP server, registration in the wrong DNS server, or the inadvertent introduction of a virus, worm, or other nasty things.
The other option to consider is the use of a deployment server to which you would deploy all VMs before moving them to the appropriate virtualization hosts. The deployment server would have all the required networks that are within the virtual environment but would not be connected to them, except through virtual firewalls that disallow direct access to the new VMs. This gives you the capability to properly patch VMs in a safe and secure environment before you migrate them to the true production network using either cold migration, VMware VMotion, or SVMotion.
In this fashion, the systems can be deployed within an extremely secure virtual network without the risk of zero day or other attacks. The virtual firewalls involved would disallow all access to the VMs but allow the VMs to access AD, DNS, DHCP, and other necessary servers and services to complete any patches, updates, and software as required.
This deployment method provides the added advantage of being able to test the VM before final migration.