Back | Next | Contents Cams Administrator's Guide

Hardening Cams Security

Cams ships with default configurations to make initial setup and integration as easy as possible. However, there's a tradeoff between convenience and security risk, which means that you should take measures to ensure that your Cams security configuration is lock-tight. This document provides an overview of issues you should consider and specific values that should be changed to harden the security of your Cams installation.

Cams security issues fall into the following three categories:

  1. Securing Cams Network Connections, including firewall configuration, securing communications
  2. Securing Cams Files and Directories, including program, configuration, and log files
  3. Securing Cams Services and Web Agents, including the Cams policy server, security domains, graceful shutdown, web agent authentication, web agent access control, and web agent session hijacking protection

Securing Cams Network Connections

Cams works in conjunction with network hardware and other security software to create a cohesive security blanket for your resources. You can use Cams with many different network topologies. Perhaps the most important consideration is ensuring that Cams and your firewall(s) are working together.

Firewall Configuration

Figure 1 shows a topology with internal and external users accessing web servers with embedded Cams web agents. Web agents communicate with a Cams policy server across a firewall. In this case, there is a firewall between the web tier servers and the external users but not the internal users. You could just as well require a configuration with a firewall between the internal users and the web servers, which may have different restrictions on each user community. From the perspective of your Cams configuration security only, the most important consideration is the firewall configuration between the Cams web agents and the Cams policy server.

Figure 1 - A possible network topology using Cams

The firewall between Cams web agents and the Cams policy server should be configured to allow Cams web agents to initiate connections from any client-side port to the specific Cams policy server port listening for agent connections (9191 by default). Though there is nothing inherently insecure about leaving this port set to 9191, you may want to consider changing it to obscure it. You should also configure your firewall to only allow agent connections from known hosts. This is not foolproof as host names and IP addresses can be spoofed, but it does provide a measure of security.

In general, Cams web agents in this topology will be running on hosts within one TCP/IP subnet and the Cams policy server will be running on an internal subnet. The firewall will use static Network Address Translation (static NAT) to map an IP address from the Cams web agent's subnet to the internal IP address of the host running the Cams policy server.

The Cams policy server also listens for shutdown requests on a different TCP/IP port (9292 by default). You should not open a hole in your external firewall for the shutdown port, as it may allow someone to shutdown your Cams policy server remotely.

The Cams policy server communicates on the back end with servers that include user repositories. Typically, these repositories will reside on the same local area network as the Cams policy server, but this may not always be the case. Hence, you must examine the various issues for communicating with these resources. In fact, it may be desirable to have a firewall between the Cams policy server and these resources!

Securing Communications

By default, Cams selectively encrypts sensitive network communications using a configurable PKI algorithm and secret key. Cams selective data encryption provides adequate confidentiality for most sites with good performance and easy administration. Sensitive information, like user authentication credentials, agent passwords and shutdown passwords are encrypted, while other less-sensitive data like resource identifiers, network addresses, etc. are sent in cleartext. See Securing Cams Communications using Secret Keys for configuration information.

NOTE: Some sites may require that all communications between Cams web agents and Cams policy servers be encrypted. In this case, we recommend using a Virtual Private Network to implement transport-level security between the systems.

Communications between the Cams policy server and user directories may also need encryption. For example, if a login module communicates with an LDAP user directory, you may want to use secure LDAP for the connection.

Using SSL when accessing LDAP user directories (deprecated Active Directory and LDAP login modules)

This section is relevant only to configure deprecated Cams login modules that use the Novell LDAP libraries to encrypt network traffic using SSL, including:

  • ActiveDirectoryLoginModule
  • AESOActiveDirectoryLoginModule
  • AESOLdapLoginModule
  • AESOX509CertLdapLoginModule
  • LdapLoginModule
  • X509CertificateLdapLoginModule

The steps required to SSL-enable LDAP communications for these login modules are:

  1. Configure your Cams login module for SSL
  2. Ensure required SSL system properties are configured
  3. Import a trusted certificate chain into the Cams keystore at CAMS_HOME/conf/cams-keystore.jks

NOTE: Before attempting to SSL-enable connections, we recommend that you first get a non-SSL configuration working to simplify the subsequent SSL configuration options.

Step 1: Configuring Cams login modules to use SSL

The following login module configuration option must be set to enable use of SSL:

<option name="useSSL" value="true"/>

Your LDAP server usually listens for SSL client connections on port 636, although the port number is configurable. With the login module useSSL option set to true, you'll also set the SSL port option:

<option name="port" value="636"/>

Step 2: Ensure SSL system properties are configured

A Java System property provides the trust store location, which indicates the file containing trusted X.509 certificates:

  • javax.net.ssl.trustStore

NOTE: The Active Directory and LDAP login modules that implement the UnboundID LDAP SDK for Java do not require configuration of a trust store.

The file where these Cams policy server values are set vary by operating system.

Windows

For Cams policy servers installed under Windows, the values shown in bold must be uncommented in CAMS_HOME/conf/runcams.conf:

# Uncomment to configure trustStore for use with deprecated LDAP login module
# SSL connections.
wrapper.java.additional.7=-Djavax.net.ssl.trustStore=../conf/cams-keystore.jks

Linux/UNIX

For Cams policy servers installed under Linux/UNIX, the values shown in bold must be uncommented in CAMS_HOME/bin/runcams.sh:

#--- Configure system properties.
P="-Dcams.home=${CAMS_HOME}"
P="${P} -DvalidateXML=true"
P="${P} -Dcams.server.bindaddr=127.0.0.1"
P="${P} -Dfile.encoding=UTF8"
# Uncomment to configure trustStore for use with deprecated LDAP login module
# SSL connections.
P="${P} -Djavax.net.ssl.trustStore=${CAMS_HOME}/conf/cams-keystore.jks"
# Uncomment to debug deprecated LDAP login module SSL connections.
#P="${P} -Djavax.net.debug=all:verbose"
if [ -n "${SECURITY_POLICY_FILE}" ] ; then
P="${P} -Djava.security.manager"
P="${P} -Djava.security.policy==${SECURITY_POLICY_FILE}"
fi

Step 3: Import a trusted certificate chain into the Cams keystore

The Cams keystore is a central location used by the Cams policy server to manage keys and certificates. When an SSL-enabled LDAP client connects with an LDAP server, the LDAP server returns a public certificate. The LDAP client checks its local keystore to see if the x.509 certificate returned by the LDAP server should be trusted.

A trusted certificate and certificate chain for your LDAP server must be imported into the Cams keystore at: CAMS_HOME/conf/cams-keystore.jks. In order to import the certificate, it must be in Base64-encoded format within a text file. For example, you should obtain a certificate with a format that looks like this:

-----BEGIN CERTIFICATE-----
MIIDxDCCAy2gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBozELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVNhbiBEaWVnbzEVMBMGA1UE
...
4DXFB0u+QoxlIfEqeke/Q29wY6+CHSbybHqBqq1vMvP7vZgX4W8VROYkF0JK4L1p
OoOKUom2ato=
-----END CERTIFICATE-----

Please consult the documentation for your LDAP server to determine how to obtain your server certificate. Once you've obtained your LDAP server certificate, copy it to a file in the Cams policy server directory CAMS_HOME/conf. For purposes of the instructions that follow, we'll assume the certificate to be imported is in file ldap_server.pem.

Open a command window, change directories to CAMS_HOME/conf, make sure the environment variable JAVA_HOME is set to the directory where Java 1.4.x is installed, and that directory JAVA_HOME/bin is in your command PATH (you can alternatively specify the fully qualified path to the keytool). Change directories and issue the following command:

keytool -import -alias ldap_server_cert -file ldap_server.pem  -keystore cams-keystore.jks -storepass changeit

NOTE: If you have multiple LDAP servers supporting SSL in your network, you must import certificates for each LDAP server and assign each certificate a different alias. For example: ldap_server1_cert, ldap_server2_cert.

If the keytool command cannot be found, then you must set your PATH environment variable to include directory JAVA_HOME/bin where the Java keytool command is located. When prompted, type yes to trust the certificate and add it to the cams-keystore.jks file. You should see information like the following:

Owner: EMAILADDRESS=support@mydomain.com, CN=ldap.mydomain.com, OU=marketing, O=MyCompany Inc, L=San Diego, ST=California, C=US
Issuer: EMAILADDRESS=support@mydomain.com, CN=ldap.mydomain.com, OU=marketing, O=MyCompany Inc, L=San Diego, ST=California, C=US
Serial number: 0
Valid from: Fri Oct 15 15:58:00 PDT 2010 until: Sat Oct 15 15:58:00 PDT 2010
Certificate fingerprints:
MD5: C3:24:C8:41:1B:C9:22:33:7C:05:8C:B0:DA:E1:72:99
SHA1: F5:2F:27:5B:C2:87:C7:C6:A1:B7:BD:94:DF:8F:FF:AC:64:B3:89:C2
Trust this certificate? [no]: yes
Certificate was added to keystore

For more information on use of the keytool command, please see keytool - Key and Certificate Management Tool.

Once you've successfully imported your LDAP server certificate, you're ready to restart your Cams policy server and test LDAP authentication using SSL. You may want to turn on the login module debug flag during configuration testing. You may also find it helpful to enable network debugging using a Java system property in CAMS_HOME/conf/runcams.conf (for Cams policy servers installed on Windows) or CAMS_HOME/bin/runcams.sh (for Cams policy servers installed on Linux/UNIX).

Windows

For Cams policy servers installed under Windows, the value (shown in bold below) must be uncommented in file CAMS_HOME/conf/runcams.conf

# Uncomment to debug deprecated LDAP login module SSL connections.
wrapper.java.additional.8=-Djavax.net.debug=all:verbose

Linux/UNIX

For Cams policy servers installed under UNIX/Linux, the value (shown in bold below) must be uncommented in file CAMS_HOME/bin/runcams.sh

# Uncomment to debug deprecated LDAP login module SSL connections.
P="${P} -Djavax.net.debug=all:verbose

This property enables verbose display of network debugging information in the console window where you started your Cams policy server and in the main Cams policy server log file.

WARNING: Make sure you disable debug before deploying your Cams policy server into production.

Securing Cams Policy Server Files and Directories

The general strategy for securing Cams Policy Server files and directories is to:

  1. Ensure that Cams policy server is executed as an appropriate user (e.g. "cams" or some other account name of you choice under Linux/Unix). This enables Cams programs to run within the secured file and directory environment described below.
  2. Enable owner read/write/execute permissions on all Cams directories, but no permissions for all other users and groups. This enables owner processes to scan and modify the contents of directories, while prohibiting all other users and groups from seeing or modifying the contents of directories.
  3. Enable owner read/write/execute permissions on the Cams programs and scripts in: CAMS_HOME/bin, but no permissions for all others users and groups. This ensures that arbitrary users cannot execute administrative commands available within the Cams environment.
  4. Enable owner read/write permissions on configuration files and log files, but no permissions for all other users and groups. This ensures that an arbitrary user cannot replace, overwrite, or redirect log files to obscure security violations or obtain sensitive information via trace logs.

Securing Cams Files and Directories under Linux/UNIX

In the instructions that follow, we recommend that your setup a non-root account to run the Cams Policy Server. Though "hacking" the Cams Policy Server is not likely, running as a non-root account assures that if there is a breach, that the Cams Policy Server is not running as the highly privileged "root" user that might execute sensitive programs or access confidential files in the underlying operating system.

For the sake of this example, assume that:

  1. the Cams policy server is installed at /var/cams (CAMS_HOME)
  2. the configuration directory is at /var/cams/conf (CAMS_HOME/conf)
  3. that you are logged in as root so that you can setup a "cams" user account for use by the Cams Policy Server and change file ownership and permissions.

A shell script for Unix/Linux is provided at CAMS_HOME/bin/setFilePerm.sh, which hardens the security of files and directories under the default Cams server installation tree (as described in Steps 2-5). This script can be executed rather than manually typing the commands in Steps 2-5, but only after you have created a "cams" user and group as described in Step 1.

Step 1 - Create a "cams" user and group

The details for creating a new user differ based on Linux/Unix operating system, but the following commands are commonly used, though you may need to provide additional parameters like a home directory, login shell, password, etc.:

useradd cams
groupadd cams
NOTE: On some Linux/Unix systems, useradd will also create a group by the same name. Consequently, you may get a warning message when using groupadd indicating that group "cams" already exists.

Step 2 - Set user and group ownership on files and directories

chown -R cams /var/cams/
chgrp -R cams /var/cams/

These commands recursively find all file and directories under the cams directory and set user and group ownership to cams.

Step 3 - Set directory permissions

find /var/cams/ -type d -exec chmod 770 {} \;

This command recursively finds all directories and gives the read/write/execute permissions only for the owner and members of the "cams" group. World is given no permissions.

Step 4 - Set general executable permissions

chmod 770 /var/cams/bin/*

chmod 770 /var/cams/jetty/camstest.sh

This command enables read/write/execute permissions for the owner and those in the "cams" group for all files in the bin directory. World is given no permissions.

Step 5- Set file permissions

find /var/cams/conf -type f -exec chmod 660 {} \;
find /var/cams/logs -type f -exec chmod 660 {} \;
find /var/cams/lib -type f -exec chmod 660 {} \;
find /var/cams/classes -type f -exec chmod 660 {} \;
find /var/cams/public -type f -exec chmod 660 {} \;
find /var/cams/jetty/etc -type f -exec chmod 660 {} \;
find /var/cams/jetty/ext -type f -exec chmod 660 {} \;
find /var/cams/jetty/lib -type f -exec chmod 660 {} \;
find /var/cams/jetty/logs -type f -exec chmod 660 {} \;
find /var/cams/jetty/webapps -type f -exec chmod 660 {} \;

This series of commands recurses through the specified directory trees looking for files (not directories) and gives them read/write permissions for the owner and group. World is given no permissions.

To test these permissions:

  1. If the Linux/Unix system hosting the Cams policy server supports normal user accounts, try logging in as a normal non-root and non-cams user.
  2. Try to list the contents of: /var/cams (permission should be denied)
  3. Try changing directories to: /var/cams (permission should be denied)
  4. Try creating a test file in: /var/cams/test.txt using a text editor like "vi" or "emacs" (permission should be denied)
  5. Try reading the contents of the Cams policy server configuration file: cat /var/cams/conf/cams.conf (permission should be denied)

Step 6 - Run the Cams Policy Server as user "cams"

Running the Cams Policy Server as a non-root user can be achieved in a number of ways in Linux/Unix environments. The appropriate solution for your environment may depend on available functionality or personal preference. The approaches described in the following documentation include:

  1. Executing the Cams Policy Server while logged into the "cams" user account (Option 1).
  2. Using the "sudo" command (if available) to enable a script owned by "root" to run the Cams Policy Server as the "cams" user (Option 2).
  3. Using "setuid" functionality (if available) to enable a script owned by "root" to run the Cams Policy Server as the "cams" user (Option 3).

In Cams Policy Server production environments, you will most likely have installed the /etc/init.d/cams service script as described in the Installation section of this document. If the "sudo" command is available on your Linux/Unix system, using it is the preferred approach. If the "sudo" command is not available, you can either download it from the following site:

http://www.sudo.ws/sudo/

or you can trying using the "setuid" approach, which tends to work in Solaris-based Unix environments, but not Linux environments. Some experimentation may be necessary.

Step 6 (Option 1) - Executing the Cams Policy Server while logged into the "cams" user account

This approach is generally useful only for test environment. Simply log into the "cams" user account and execute the CAMS_HOME/bin/runcams.sh script. To shutdown the Cams Policy Server, execute the CAMS_HOME/bin/shutdown.sh script.

Step 6 (Option 2) - Executing the Cams Policy Server using "sudo"

You may need to configure "sudo" to allow specific user accounts to run Cams. By default "root" will be able to run any program as another user, but if you need to enable a developer or web administrator withour root access to start and stop Cams using "sudo", so basic configuration will be necessary. See the "sudo" manual page for more information.

To run the Cams Policy Server as the "cams" user using "sudo", type:

sudo -u cams $CAMS_HOME/bin/runcams.sh &

The Cams Policy Server will be executed in the background. Confirm that it is running as the "cams" user by using the "ps" command as follows:

ps -edalf | grep cams

You should see processes like the following listed:

0 S cams 25776 25775 0 78 0 - 1163 wait 18:07 pts/1 00:00:00 /bin/sh ./runcams.sh
0 S cams 25780 25776 74 84 0 - 70559 322561 18:07 pts/1 00:00:08 /usr/java/jdk1.6.0_02/bin/java -server ...

The third column shows the name of the account running the process (cams).

You should also be able to run the Cams Policy Server shutdown.sh script using sudo as follows:

sudo -u cams $CAMS_HOME/bin/shutdown.sh &

The Cams Policy Server should shutdown.

If you installed the Cams Policy Server initd service script as described in the Installation section, then you will need to edit that script to run your Cams Policy Server as user "cams" rather than "root". Simply change the following two lines in the file:

$CAMS_HOME/bin/runcams.sh >> $CAMS_HOME/logs/console.log 2>&1 &
$CAMS_HOME/bin/shutdown.sh >> $CAMS_HOME/logs/console.log 2>&1 &

to:

sudo -u cams $CAMS_HOME/bin/runcams.sh >> $CAMS_HOME/logs/console.log 2>&1 &
sudo -u cams $CAMS_HOME/bin/shutdown.sh >> $CAMS_HOME/logs/console.log 2>&1 &

To test this, you will need to login as root, then type:

Linux or Unix with "service" command

service cams start

Linux or Unix without "service" command

/etc/init.d/cams start

Step 6 (Option 3) - Executing the Cams Policy Server using "setuid"

The "setuid" approach enables privileged users (generally root) to execute programs based on configured file ownership and permissions. It is generally useful when a program executed by root (e.g. /etc/init.d/cams) at system startup and shutdown time wants child processes to run as another user.

NOTE: The "setuid" approach generally works on Unix operating systems based on System V Unix (e.g. Solaris, HPUX, AIX, etc), but not on Linux or BSD Unix-based operating systems. In some Unix environments, setuid support based on file permissions can be enabled/disabled by file system. Some experimentation may be necessary to confirm support in your environment.

To configure the Cams Policy Server to run as user "cams" using setuid file permissions, you must set the "sticky bit" for executable scripts as follows:

chmod 4770 /var/cams/bin/*.sh

NOTE: These scripts were already changed to owner "cams" and group "cams" in Step 4.

To confirm that the "sticky bit" is set, type the following command:

ls -laF /var/cams/bin/*.sh

You should see a listing that looks something like this:

-rwsrwx--- 1 cams cams 1320 Mar 1 14:38 /var/cams/bin/initd_cams_linux.sh*
-rwsrwx--- 1 cams cams 2705 Mar 1 14:38 /var/cams/bin/runcams.sh*
-rwsrwx--- 1 cams cams 2530 Mar 1 14:38 /var/cams/bin/secretKeyGen.sh*
-rwsrwx--- 1 cams cams 2836 Mar 1 14:38 /var/cams/bin/setFilePerm.sh*
-rwsrwx--- 1 cams cams 1714 Mar 1 14:38 /var/cams/bin/shutdown.sh*

The permission "rws" for the owner (cams) shows that each execute script file has read/write/sticky execution permissions. If one of the scripts is executed by a "root" process (e.g. /etc/init.d/cams) and file-based setuid functionality works in your environment, then the script will be executed as user "cams".

To test the setuid approach, you will need to login as root, then type:

Linux or Unix with "service" command

service cams start

Linux or Unix without "service" command

/etc/init.d/cams start

Confirm that it is running as the "cams" user by using the "ps" command as follows:

ps -edalf | grep cams

You should see processes like the following listed:

0 S cams 25776 25775 0 78 0 - 1163 wait 18:07 pts/1 00:00:00 /bin/sh ./runcams.sh
0 S cams 25780 25776 74 84 0 - 70559 322561 18:07 pts/1 00:00:08 /usr/java/jdk1.6.0_02/bin/java -server ...

The third column shows the name of the account running the process (cams).

Securing Cams Files and Directories under Windows NT/2000/2003

In the instructions that follow, it is assumed that the Cams policy server is executed by the Admin user on your Windows NT/2000/2003 server. For the sake of this example, assume that:

  1. the Cams policy server is currrently stopped
  2. the Cams policy server is installed at C:\camsServer
  3. the configuration directory is C:\camsServer\conf
  4. You are logged in as Admin to your Windows server or domain controller

As is the case with any command that Admin executes, you must take care that it is protected from modification by non-Admin users. The file permissions graphical user interface varies between Windows versions, so use the appropriate instructions below for your system.

Securing Windows Files and Directories

Step 1 - Set user and group ownership of all files and directories

This is done using the Windows graphical user interface.

  1. Using the Windows Explorer file browser, right click on the top-level Cams policy server installation directory: C:\camsServer and select the Properties menu item. A dialog box entitled camsServer Properties will appear.
  2. Select the Security tab
  3. Select the Advanced button. A dialog box entitled Access Control Settings for camsServer will appear.
  4. Select the Owner tab.
  5. Select the Admin user from the list at the top.
  6. Select the Replace owner on subcontainers and objects check box
  7. Select the OK button to apply ownership changes
Step 2 - Set all directory and file permissions
  1. In the camsServer Properties dialog box, deselect the Allow inheritable permissions from parent to propagate to this object check box. A dialog box entitled Security will appear.
  2. Select the Remove button to remove inherited permissions explicitly specified on the camsServer directory.
  3. Select the Add button. A dialog box entitled Select Users or Groups will appear.
  4. Select the admin user from list at the top.
  5. Select the Add button. The Admin user should now be added to the list at the bottom of the dialog box.
  6. Select the OK button to apply the selected Admin user.
  7. In the Permissions list, select check box: Allow/Full Control. This will cause all Allow column check boxes to become selected.
  8. Select the OK button to apply the camsServer properties changes.

To test these directory and file permissions under Windows:

  1. Log out from the Windows server Admin account and login using a normal user account (not Admin)
  2. Using a file browser or command prompt, attempt to view the contents of directory C:\camsServer. (You should not be able to view any files in this directory).
  3. If you will be running the Cams policy server as a Windows service, make sure the service is run under the Admin user indentity. Try starting and stopping the Cams policy server service.

NOTE: Unless necessary, it is also recommended that you avoid sharing the Cams policy server installation directory and its contents between hosts.

Changing the Cams keystore Password

The Cams keystore is primarilly used as a key and certificate repository by the Cams Policy Server to authenticate SSL clients, including Cams agents, and LDAP clients. Changing the Cams keystore password help protect you should your organization should your keystore file be accessed by unauthorized individuals. Without the keystore password, the keys and certficates cannot be exported and subsequently used to impersonate trusted indentities.

To change the Cams keystore password:

1. Open a console window
2. Change directories to CAMS_HOME/conf
3. Issue the following command:

keytool -storepasswd -keystore ./cams-keystore.jks

The keytool command will ask for the old password (by default it is changeit) then the new password, then a confirmation of the new password.

WARNING: It is extremely important that you remember your new password. If you forget it, you will not be able to manage keys and certificates.

NOTE: If the keytool command cannot be found, then directory JAVA_HOME/bin is not in your command search path. Update your command search PATH to include JAVA_HOME, then try again.

Securing Cams Services and Web Agents

The Cams policy server hosts a set of services that should be secured with site-specific configuration values. Cams web agents should be configured with compatible values and described in the following sections.

Cams Policy Server

This section explains the Cams policy server values that you should change to harden your site security. Start by opening the CAMS_HOME/conf/cams-reg-default.conf file in a text editor.

You should change the name of your Cams policy server from MyCamsServer to something unique for your site. This value is used for logging and to distinguish Cams policy server installations and their corresponding user sessions from each other. It does not need to correspond to the host's DNS name. You should change it's value to something unique for your company or department, etc. Only alphanumeric characters are valid. You'll also need to change the corresponding name in the configuration file for each Cams web agent.

#--- The name of the Cams policy server. This value and cams.server.url
#--- are used to uniquely identify a Cams policy server instance and its
#--- available services.
#
cams.server.name=MyCamsServer

Next, open the CAMS_HOME/conf/cams.conf file in a text editor.

You can change the Cams policy server connection port. Though the default port 9191 is not insecure, you can gain a measure of security by obscuring the port you are using. Again, you'll also need to make corresponding changes in the configuration file for each Cams web agent.

#
#--- The TCP/IP port on which Cams policy server listens for general security
#--- service connections.
#
cams.server.port=9191

You may want to change the Cams policy server shutdown port with the next value. Unlike the connection port, the Cams web agents do not require the same value.

#
#--- The TCP/IP port on which the Cams policy server listens for shutdown
#--- service connections.
#
cams.server.shutdown.port=9292

You should definitely change the shutdown password from the default. The shutdown password is required to send a valid shutdown command to the Cams policy server. If a secret key is installed, the shutdown password is encrypted before being sent from the shutdown client to the Cams policy server.

#
#--- The password that must be supplied by shutdown clients
#--- to authenticate requests.
#
cams.server.shutdown.password=theEndIsNear

Security Domains

You must consider values in each security domain that should be hardened. Use a text editor to open the security-domain.xml file for each security domain in your configuration. The Cams session manager service uses a key to encrypt the session id for each security domain. Each security domain should have a unique key, which should be changed from the default value of secret-key.

<session-manager-service ...>
 	<param-list>
    ...
      <param name="sessionIdIPAddrValidationMask" value="255.255.255.255"/>
 	  <param name="sessionIdKey" value="secret-key"/>
 	</param-list>
...
</session-manager-service>

The session-manager-service's sessionIdIPAddrValidationMask should be made as restrictive as practical. This value is used to validate the IP address of a remote, authenticated client (like a web browser) against the IP address when the client authenticated and its session was created. The mask value 255.255.255.255 causes the entire IP address associated with client requests to be validated. This may be too restrictive in cases where a web browser client may access protected resources via different network routes. For example, Internet Service Providers may transmit HTTP and HTTPS network traffic via different routes by use of proxy servers. In addition, some routers use Dynamic Network Address Translation. Both conditions lead to HTTP/HTTPS requests for the same client that appear to come from different IP addresses. In such cases, it may be necessary to make IP address validation less restrictive by using a validation mask like 255.255.255.0, which would validate only the first 3 triplets in a class C address. The value is set to 0.0.0.0 by default, which disables the address validation mask.

Other usernames and passwords specified in session event handlers, service manager services, etc. are for connections to your site's data stores. Any defaults must be changed to work with your site. User directory connections in login-config.xml share the same issue.

The access-control.xml file does not require hardening, just configuration to your site specific needs. However, you may desire to make changes to strengthen, for example, the rules associated with Cams web agent authentication. In this respect, you could add a list of valid hostnames or IP addresses to the Cams web agent authentication rule.

You should change cams-users.xml in the system security domain. This is where the default Cams web agent profiles are stored. You should minimally change the passwords and possibly the username and role for your Cams web agents. If you change the name of the role, you must change the corresponding role name for the agent rule in the system security domain's access-control.xml file.

Cams Web Agents

Connection of Cams web agents to a Cams policy server should be carefully secured in a production environment. The system security domain is usually responsible for authenticating and checking access control rules for Cams web agents.

Securing Cams Web Agent Authentication

Each Cams web agent must authenticate with the Cams policy server by supplying a username and password. The username and password must match a profile in the corresponding security domain's user directory. By default, this is the cams-users.xml file in the system security domain.

All Cams web agents are configured with default username/password parameters:

cams.client.authentication.principal=cams-web-agent
cams.client.authentication.credential=password

You should change these values according to your username and password policies. In addition, you should update any other configuration values for which you may have changed a corresponding value on the Cams policy server. For example, if you change the Cams policy server name or connection port, you must change the corresponding value in the Cams web agent configuration file.

In addition, you should use Cams secret keys (described in Securing Cams Communications using Secret Keys) to encrypt username/password values sent from Cams web agents to a Cams policy server.

Securing Cams Web Agent Access Control

The system security domain's access control policy contains default rules for controlling access by Cams web agents. These rules are shown in Example 1 and control access by requiring the authenticated agent to belong to the cams-agent role. If an agent has the cams-agent role, then access is granted, else access is denied.

<access-control-policy>
...
   <!-- Authenticated agents must have the "cams-agent" role  -->
   <auth-acr id="cams agent rule">
      <role-constraint>
         <role-name>cams-agent</role-name>
      </role-constraint>
   </auth-acr>
...
</access-control-policy>

Example 1 - Default system security domain access control rules for connecting Cams web agents

You can harden access control for Cams agents by incorporating IP address constraints into the system security domain's access control policy as shown in Example 2.

<access-control-policy>
...
   <!-- Authenticated agents must have the "cams-agent" role
        and be connecting from an approved remote address -->
   <acr id="cams agent rule">
      <auth-acr>
         <role-constraint>
            <role-name>cams-agent</role-name>
         </role-constraint>
      </auth-acr>
      </and>
      <host-acr>
         <allow-address>
            <address>127.0.0.1</address>
            <address>192.168.1.112</address>
            <address>192.168.1.113</address>
         </allow-address>
      </host-acr>
   </acr>
...
</access-control-policy>

Example 2 - Hardened system access control rules for connecting Cams web agents

Using Cams Web Agent Session Hijacking Protection

Cams web agents using HTTP cookies to track authenticated Cams users. Although the use of Cams session cookies is safe (Cookies are not persisted to disk), a hacker could intercept a Cams session cookie by use of an HTTP proxy server or some other means and attempt to use it in a manufactured HTTP request. Cams web agent session hijacking protection provides a way to detect a hijacked Cams session cookie.

Cams session hijacking protection works by computing a secure one-way hash value using a common message digest algorithm. A Cams deployment-specific value, HTTP request header values from the browser (Accept-Language and User-Agent) originally used to authenticate the user and a few other parameters are used to compute the hash value.

If a hacker does not provide exactly the same Cams session cookie value and associated HTTP request parameters, the session hijacking will be detected, access will be denied by the web agent, and the client will be redirected to the configured error page. A detailed error message is also logged to the cams-webagent.log file.

To enable session hijacking, simply set the session hijacking properties to true in cams-webagent.conf. You should also choose a new salt value and make sure all Cams web agents are configured with the same value.

#
#--- Enable Cams session hijacking protection
#
cams.session.hijacking.protection.enable=true

#
#--- The message digest algorithm used to compute a session hijacking detection hash value
#
cams.session.hijacking.protection.algorithm=sha1

#
#--- A value used to obfuscate the session hijacking hash value.
#
cams.session.hijacking.protection.salt=epsom

WARNING: All Cams web agents in a Cams policy server cluster must be configured with the exact same session hijacking properties. If not, Cams session cookies will not work consistently across all Cams web agents and access to some server resources will ALWAYS be denied.

WARNING: Cams session hijacking is disabled by default. This is to prevent situations where session hijacking false-positives will cause Cams to ALWAYS deny access to resources that are displayed by browser plugins. For example, if session hijacking is enabled and the user tries to fetch an Adobe Acrobat PDF file, access will be denied because the Acrobat plugin does not send the same HTTP User-Agent as the browser. Cams interprets this as an attempt to hijack the session and denies access.

Back | Next | Contents