12 Securing the Configuration Change Console

This section outlines various configurations that can be made after installing the Agents or server to secure your Configuration Change Console installation.

Securing Agent Files

The directory where the agent is installed must be set to readable only by the user the agent is running as. These files should not be world readable as they contain information that could be used to compromise the security of the agents.

On Unix, the installation will set all files to have Read, Write and Execute permissions revoked for Group or Others.

On Windows, the permissions are not set out of the box. The administrator must set the security rules either locally or from a domain controller to block any other users from reading files in the agent installation directory.

Securing Server Files

The directory where the server is installed must be set to readable only by the user the server is running as and privileged administrators. These files should not be world readable as they contain information that could be used to compromise the security of the server or agent to server communication.

The permissions are not set out of the box. The administrator must set the security rules either locally or from a domain controller to block any other users from reading files in the server installation directory.

Configuring JMS Access Control List

All communication between the agents and server uses Java Messaging Services (JMS). By default, the installation of the agent and servers sets the JMS connection to be over JMS with SSL which provides encryption of content being passed. The beta however does not include a mechanism to ensure there is a trust relationship between agent and server. To set up a secure environment, you need to modify the configuration of the JMS provider to create a list of hosts that are allowed to connect to the JMS queues and topics. Configuration Change Console is using the ORMIS protocol for JMS communication under the OC4J container.

ORMIS supports the ability to restrict incoming IP access by defining access control list (ACL) masks. These settings are made with the <access-mask> element and its <host-access> and <ip-access> subelements in the rmi.xml configuration file.

Access controls can be either exclusive or inclusive.

In the exclusive mode, access is denied to all IP addresses or hosts except those specifically included. Use mode="deny" in <access-mask>, then specify which particular hosts or IP addresses to allow by using mode="allow" in <host-access> or <ip-access> subelements (or both).

In the inclusive mode, access is available to all IP addresses or hosts except those specifically excluded. Use mode="allow" in <access-mask>, then specify which particular hosts or IP addresses to deny by using mode="deny" in <host-access> or <ip-access> subelements (or both).

The following snippet from rmi.xml configures an exclusive mode, allowing access to only localhost and 192.168.1.0. (255.255.255.0 is the applicable subnet mask.)

<rmi-server>…. <access-mask default="deny"> <host-access domain="localhost" mode="allow"/> <ip-access ip="192.168.1.0" netmask="255.255.255.0" mode="allow"/> </access-mask>.... </rmi-server>

The rmi.xml file is located on the server in the following path:

SERVER_INSTALL_PATH/oc4j/j2ee/home/config/rmi.xml

Changing the SSL Method

The SSL communication between the agent, server and JMS provider uses an anonymous cipher crypt method. This will encrypt the contents, but does not ensure the agent or server is trusted. One way to protect this is through the use of JMS Access Control Lists described above, another is to change the SSL method from anonymous cipher crypt to using certificate based SSL.

The process involves either using an Oracle wallet based certificate and adding an XML snippet such as the following to your rmi.xml configuration file:

<ssl-config keystore="/wallets/wallet-server-a/ewallet.p12" keystore-password="serverkey-a" />

If you want to use Java keystore instead of Oracle Wallet, you would create a keystore using the Java keytool and then add something similar to the following example to your rmi.xml configuration file:

<ssl-config keystore="/keystores/keystore_a.jks" keystore-password="serverkey-a"/>

The rmi.xml file is located on the server in the following path:

SERVER_INSTALL_PATH/oc4j/j2ee/home/config/rmi.xml

When using keystores and passwords, the server keystore must contain the signed certificate of any client that is authorized to connect to OC4J through ORMIS, or contain the root CA-issued certificate of the client.

The process of configuring certificate based SSL is documented thoroughly in the Oracle Containers for J2EE Security Guide 10g (10.1.3.1.0). Please see this documentation for additional details