In this section, we explore some important security considerations that you must be aware of when using Oracle VM.

Limitation of Access To The Oracle VM Manager Host

It cannot be stressed enough that the Oracle VM Manager Core is a very powerful component within an Oracle VM deployment, providing control over many servers and virtual machines. With this in mind, access to this host should be severely restricted. User accounts should be limited to administrators who require access to manage a deployment. Furthermore, firewall rules should be hardened to limit access to networks where administrators may be located.

Users with access to utilities or tools that communicate with the Oracle VM Manager Core in any way, should be aware that the credentials that they use to authenticate, whether by username and password or by SSL certificate, are highly sensitive and that a compromise of this nature does not only threaten Oracle VM Manager itself, but also makes every server and virtual machine within the deployment vulnerable to attack.

Appropriate security practice with regard to identity and credential management should always be observed.

See Section 1.2, “General Oracle VM Security Principles” for more guidelines on system protection.

Use of SSL for Encryption

Many communications with Oracle VM Manager over HTTPS are encrypted using an SSL certificate to protect the communication of sensitive information. By default, this certificate is signed by an internal CA certificate that is generated for the Oracle VM Manager instance during installation. Since most client applications, including user web browsers, will not have this CA certificate installed it is not possible for many client applications to validate the SSL certificate presented when accessing an Oracle VM Manager service over HTTPS. Some client applications may fail entirely if an SSL certificate cannot be validated, while other applications may simply issue a warning and allow users to proceed at their own risk. To minimize the likelihood of a man-in-the-middle attack, it is important that validation can actually take place. Therefore, it is appropriate to take one of the following courses of action:

These operations are discussed in detail in Setting up SSL on Oracle VM Manager in the Oracle VM Administrator's Guide.

During initial Oracle VM Server discovery and key exchange, passwords are sent over the wire from the Oracle VM Manager to the Oracle VM Agent for authentication purposes. This communication is performed over SSL so should be secure. However, no certificate validation is performed against the Oracle VM Agent certificate at this point since the Oracle VM Agent certificate is unknown. Therefore, it is possible that this channel might be subject to a man-in-the-middle attack wherein a malicious entity impersonates the server so that the manager sends the password to this entity in an attempt to authenticate. Where possible the Oracle VM Manager system should be run within the same local area network as the Oracle VM Servers within your Oracle VM environment, and this network should have appropriate security controls to mitigate the risk that a malicious attacker is able to perform a man-in-the-middle attack. Additionally, it is worthwhile ensuring that the passwords for the Oracle VM Agent on each Oracle VM Server is unique. This means that in the unlikely event that a single server is compromised via a man-in-the-middle attack, access to all servers within the deployment is not immediately gained and the damage can be limited.

Use of SSL for Certificate Based Authentication

It is a common misconception that use of certificate-based authentication automatically makes a system more secure than the use of passwords, but this is not necessarily true. Certificate-based authentication is susceptible to many of the same attacks as password authentication. In this section we will discuss some of the ways in which this system could be attacked so that the security level can be well understood. All protocols that are used conform to current best practices documented in the OSCS (Oracle Secure Coding Standard).

In general, certificate authentication is less susceptible to dictionary attacks as well as brute-force attacks over the secure communication channel. However, in order for an SSL certificate to be signed and registered by Oracle VM Manager, password-based authentication is still used within Oracle VM Manager. This is particularly relevant to the Oracle VM Agent, which must use password-based authentication to support initial discovery and take ownership requests, as well as to allow discovery by secondary (non-owning) managers. Equally, it cannot be assumed that every user is issued with an SSL certificate-key pair that can be configured for use within a web browser to authenticate requests to use the Oracle VM Manager Web Interface. As a result, the Oracle VM Manager Web Interface only supports password-based authentication. Therefore, there are still channels within Oracle VM that are open to dictionary and brute-force attacks. These risks could be minimized by restricting access to systems using a strict firewall policy based on the requirements for different systems that need access to one another. It is important to understand that password exchanges are always encrypted using SSL, and are never exposed in clear text. Furthermore, stored passwords are always encrypted on the systems that hold them.

Where certificate-based authentication is used, if the private key used on either end of the communication is compromised, the attacker could use that private key and corresponding certificate to log into the other entity. On Oracle VM Manager, keys are encrypted and stored within a JKS keystore file which is protected by both a key password and a keystore password. These passwords are long, randomly generated passwords which are stored in the Oracle CSF (Credential Store Framework). The length and random nature of these passwords should preclude dictionary or brute-force attacks, but if the CSF is compromised then the keys could be retrieved. This mechanism conforms to the current security guidelines outlined by the OSCS.

In the case of Oracle VM Agent, the keys and certificates are stored in a non-encrypted PEM format. These files are readable only by the root user, but if the root user account is compromised, a user could then use this information to send bogus notification information to the manager. Likewise, a malicious user with root access could replace the Oracle VM Manager certificate information on the Oracle VM Agent with their own certificate to allow themselves to be authenticated for Oracle VM Agent commands. However, if they have already compromised the root account on the server this is probably a moot point since they already have unrestricted access to the system.

In the case where you choose to use certificate-based authentication within custom-built applications that make use of the WSAPI, you must ensure that appropriate actions are taken to protect keys from misuse. This includes setting a reasonable passphrase for your keys and ensuring that the keys are preferably stored in an encrypted format. A malicious user with access to a key that is registered for authentication against Oracle VM Manager has full access to the entire Oracle VM environment including all virtual machines, all storage, all servers and Oracle VM Manager itself.

When certificates are registered for authentication with Oracle VM Manager, the authorized certificate that allows authentication to the manager to take place is stored in the Oracle VM Manager database. This certificate only contains public key information, so it cannot be used in and of itself to log into Oracle VM Manager. However, a user who can modify the Oracle VM Manager database could replace this with a certificate of their own. For this attack vector to work, the certificate would need to be signed by a trusted CA (such as the Oracle VM Manager CA). Therefore, the risk can be mitigated by proper administration of the WebLogic trust store. To access the Oracle VM Manager CA private key to create such a certificate, the CSF would have to be compromised as well.