Chapter 1 Oracle VM Security Overview

Oracle VM is a platform that provides a fully equipped environment with all the latest benefits of virtualization technology. Oracle VM enables you to deploy operating systems and application software within a supported virtualization environment. Oracle VM insulates users and administrators from the underlying virtualization technology and allows daily operations to be conducted using goal-oriented GUI interfaces. The components of Oracle VM are shown in Figure 1.1, “Oracle VM Architecture”.

Figure 1.1 Oracle VM Architecture

Click to view larger image ovm3arch.png

The Oracle VM security architecture, by design, eliminates many security threats. The guidelines for secure deployment of virtualized solutions based on Oracle VM are largely based on network security. As these guidelines are generally applicable, they should always be reviewed for applicability in the context of each implementation and the security requirements and policies of the broader environment in which Oracle VM is deployed.

The following list describes the main aspects of the Oracle VM security architecture:

All components of the Oracle VM installation communicate with each other in a secure way. The following table shows, in detail, how each individual line of communication is set up securely:

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.

Encrypted Communication

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 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.

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/TLS, 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.

One of the principles of good security practice is to keep all software versions and patches up-to-date. Throughout this document, we assume that you are installing the necessary security patches and package updates on the Oracle Linux host running Oracle VM Manager, as well as the Oracle VM Servers in your environment. It is recommended that you:

Secure your network properly with firewalls. Software firewalls are part of the Oracle VM Manager and Oracle VM Server installations, but a best practice is to use an external firewall in addition. Keep all Oracle VM services on private network segments and allow public access only to and from services and systems that effectively require it. While firewalls are not infallible, they provide a high level of certainty that access to these systems is limited to a known network route, which can be monitored and further restricted, if necessary.

Should you decide to restrict access based on IP address, note that this often causes application client/server programs to fail for DHCP clients. In general, this is resolved by using static IP addresses or IP address reservation on the DHCP server. Note that with address reservation on the DHCP server, a connection may still fail if the IP lease expires while the DHCP server is unreachable. For Oracle VM in particular, static IP address assignment is highly recommended. In fact, the Oracle VM Manager host must maintain its IP address because the Oracle VM Servers under its control all record that IP address during server discovery. The IP is stored in the Oracle VM Agent database and used for communication with Oracle VM Manager. The same mechanism applies to the virtual IP address of a server pool, which must also be statically configured.

The network model of a given Oracle VM implementation depends on the hardware used, the scale of the environment, and the particular services deployed through its guest virtual machines. Various network configurations, security features of the network model, and guidelines for each networking type are described in more detail in the Security Features chapter; more specifically in Section 3.1, “Oracle VM Network Model”.

The principle of least privilege states that users should be given the least amount of privilege to perform their jobs. Over-ambitious granting of responsibilities, roles, grants, etc., especially early on in an organization’s life cycle when people are few and work needs to be done quickly, often leaves a system wide open for abuse. User privileges should be reviewed periodically to determine relevance to current job responsibilities.

However, Oracle VM is a server virtualization solution, and is an administrator's tool in the first place. Access to Oracle VM Manager is controlled by the underlying WebLogic application server, and while it is possible to create multiple accounts to log in to Oracle VM Manager, the privileges for all administrator accounts are the same. Consequently, it is recommended to create administrator accounts only for those who need full access to Oracle VM configuration and resources, and to use a strong password on each account. Use passwords between 8 and 16 characters in length consisting of a combination of small letters, capital letters and numeric characters.

For users who need access to one or more virtual machines, but are not allowed to modify the Oracle VM configuration, an administrator may set up remote access on the virtual machines. For a Windows server, RDP can be used; for a Unix server you can use SSH for command line access, and VNC in case a graphical desktop environment is used. Connect the virtual machines to a network that is accessible from the trusted internal network.

If the specific implementation of Oracle VM is a large scale configuration that requires finer grained role based access control, an alternative is to manage the environment through Oracle Enterprise Manager Ops Center. In this configuration, access control is an integral part of Enterprise Manager Ops Center.

Oracle VM subscriptions include full, complete use of Oracle Enterprise Manager Cloud Control and Oracle Enterprise Manager OpsCenter. Customers who purchase Oracle VM subscriptions have an included license to use these products' virtualization and operating system management features as part of Oracle VM. The complete set of products (Oracle Enterprise Manager Cloud Control, Oracle Enterprise Manager OpsCenter, Oracle VM Manager and Oracle VM Agent) are regarded as one product suite.

System security stands on three legs: good security protocols, proper system configuration and system monitoring. Auditing and reviewing audit records address this third requirement. Each component within a system has some degree of monitoring capability. Follow audit advice and regularly monitor audit records.

As an Oracle VM administrator you have access inside the Oracle VM Manager GUI to events and statistics. These are your first indicators of potential problems, including security risks. Particularly important errors to investigate are Oracle VM Server disconnect and offline events, as they indicate unexpected connectivity issues.

Oracle VM keeps a number of log files on different components in the environment. These log files are important for the manageability and supportability of Oracle VM. The following tables provide an overview of the log files that can assist you in troubleshooting and security auditing:

Oracle VM Manager Logs

Oracle VM Server Logs

In the context of product security and auditability, the various log files show which operations have been performed by each Oracle VM Manager administrator account. Also, any unauthorized login attempt on Oracle VM Manager or SSH connection failure to an Oracle VM Server is reflected in the log files. Monitor the logs actively in order to detect security issues as early as possible.

Oracle continually improves its software and documentation. Check the Oracle web site and relevant product and technology pages regularly. For example: