| Back | Next | Contents | Cams Administrator's Guide |
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:
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.
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!
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. This need is somewhat reduced if passwords are stored as hashed values in the directory, and if the local area network is not accessible by internal users.
Cams login modules that use the LDAP protocol (including Active Directory) to authenticate users and query groups/roles support use of SSL to encrypt network traffic. The steps required to SSL-enable LDAP communications are:
NOTE: Before attempting to SSL-enable communications with an LDAP directory, it is recommended that you get a non-SSL configuration working. This will simplify the number of configuration options that must be verified when hardening the connection to use SSL.
For Cams login modules that support LDAP over SSL, the following configuration option must be set to enable use of SSL:
<option name="useSSL" value="true"/>
In addition, your LDAP server will usually be listening for clients that connect using SSL on port 636, although this port number is configurable by administrators. So if the useSSL option is set to true, you'll also want to set the SSL port:
<option name="port" value="636"/>
Two Java system properties must be set to enable Cams support for SSL:
The location where these values are set for the Cams policy server may vary by operating system.
Windows
For Cams policy servers installed under Windows, the values (shown in bold below) must be set in file CAMS_HOME/conf/runcams.conf:
wrapper.java.additional.5=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
wrapper.java.additional.6=-Djavax.net.ssl.trustStore=../conf/cams-keystore.jksLinux/UNIX
For Cams policy servers installed under UNIX/Linux, the values (shown in bold below) must be set in file CAMS_HOME/bin/runcams.sh:
P="-Dcams.home=${CAMS_HOME}"
P="${P} -DvalidateXML=\"true\""
P="${P} -Djava.protocol.handler.pkgs=\"com.sun.net.ssl.internal.www.protocol\""
P="${P} -Djavax.net.ssl.trustStore=\"${CAMS_HOME}/conf/cams-keystore.jks\""
if [ -n "${SECURITY_POLICY_FILE}" ] ; then
P="${P} -Djava.security.manager"
P="${P} -Djava.security.policy==${SECURITY_POLICY_FILE}"
fi
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 2005 until: Sat Oct 15 15:58:00 PDT 2005
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 set in file CAMS_HOME/conf/runcams.conf
wrapper.java.additional.4=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
wrapper.java.additional.5=-Djavax.net.ssl.trustStore=../conf/cams-keystore.jks
wrapper.java.additional.7=-Djavax.net.debug="true"Linux/UNIX
For Cams policy servers installed under UNIX/Linux, the value (shown in bold below) must be set in file CAMS_HOME/bin/runcams.sh
P="-Dcams.home=${CAMS_HOME}"
P="${P} -DvalidateXML=\"true\""
P="${P} -Djava.protocol.handler.pkgs=\"com.sun.net.ssl.internal.www.protocol\""
P="${P} -Djavax.net.ssl.trustStore=\"${CAMS_HOME}/conf/cams-keystore.jks\""
P="${P} -Djavax.net.debug=\"true\""
if [ -n "${SECURITY_POLICY_FILE}" ] ; then
P="${P} -Djava.security.manager"
P="${P} -Djava.security.policy==${SECURITY_POLICY_FILE}"
fi
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. Make sure you disable all debug before deploying your Cams policy server into production.
In a typical production environment, the Cams policy server and web agents are started and executed by the administrative "root" user (Unix) or "Administrator" user (Windows NT/2000). The general strategy for securing Cams files and directories is to:
The following sections provide operating system-specific instructions for securing Cams files and directories.
In the instructions that follow, it is assumed that the Cams policy server is executed by root on your Linux/UNIX system. For the sake of this example, assume that:
As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writable only by root, but so must the directories, and parents of all directories. It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the Cams policy server, you should ensure that it is similarly protected.
A shell script for Unix/Linux is provided at CAMS_HOME/bin/setFilePerm.sh. This script hardens the security of files and directories under the default Cams server installation tree. The script executes the following steps:
cd /user/local/camsServer
chown -R root.root .
This command recursively finds all file and directories and sets user and group ownership to root.
find . -type d -exec chmod 700 {} \;
This command recursively finds all directories and gives the read/write/execute permissions only for the owner. Group and world are given now permissions.
chmod 700 bin/*
This command enables read/write/execute permissions for the owner of all files in the bin directory. Group and world are given no permissions.
find conf -type f -exec chmod 600 {} \;
find logs -type f -exec chmod 600 {} \;
find lib -type f -exec chmod 600 {} \;
find classes -type f -exec chmod 600 {} \;
find templates -type f -exec chmod 600 {} \;
find src -type f -exec chmod 600 {} \;
This series of commands recurses through the conf, logs, lib, classes, templates, and src directory trees looking for files (not directories) and gives them read/write permissions for the owner. Group and world are given no permissions.
Cams web agent configuration files and directories should use similar means to secure their contents, although instructions for doing so are necessarily specific to the software application hosting the Cams web agent. See the appropriate Cams web agent configuration guide for more details.
To test these permissions:
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:
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 NT and Windows 2000, so use the appropriate instructions below for your system.
This is done using the Windows graphical user interface.
To test these directory and file permissions under Windows 2000/2003/XP:
NOTE: Unless necessary, it is also recommended that you avoid sharing the Cams policy server installation directory and its contents between hosts.
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:
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.
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.
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
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.
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.
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.
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
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.
© Copyright 1996-2005 Cafésoft LLC. All rights reserved.