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:

Securing Cams Network Connections, including firewall configuration, securing communications
Securing Cams Files and Directories, including program, configuration, and log files
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. Some Cams web agents also support SSL communications with the Cams policy server. Tradeoffs between these confidentiality mechanisms include: performance, security, and ease of administration.

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.

SSL provides superior security at the cost of lower performance and more difficult administration. When using SSL, all data transferred between the Cams web agent and policy server is encrypted. In addition, the SSL architecture ensures the integrity of data. If the receiving server can decrypt the data, then it has not been altered in transit. A final benefit is that SSL enables Cams web agents to verify the identity of a Cams policy server.

NOTE: Cams does not currently include documentation on how to enable SSL support of the Cams web agent connections to the Cams policy server. However, it is possible to configure Cams with SSL support. If you need this level of confidentiality now, please contact Cafésoft support for further instructions.

The following document provides more information on the configuration of specific confidentiality measures:

Securing Cams Communications using Secret Keys

Similarly, communications between the Cams policy server and user directories may need encryption. For example, if a login module communicates with an LDAP user repository, you may want to use secure LDAP for the connection. This need is somewhat reduced if passwords are stored as hashed values in the repository, and if the local area network is not accessible by internal users.

Securing Cams Files and Directories

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:

Ensure that Cams policy server or web agent are executed as the appropriate administrative user (root or Administrator), hereafter referred to as the owner. This enables Cams programs to run within the secured file and directory environment described below.
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.
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.
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.

The following sections provide operating system-specific instructions for securing Cams files and directories.

Securing Cams Files and Directories under Linux/UNIX

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:

the Cams policy server is installed at /usr/local/camsServer
the configuration directory is at /usr/local/camsServer/conf
that you are logged in as root.

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:

Step 1 - Change directories to the Cams policy server installation directory

cd /user/local/camsServer

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

chown -R root.root .

This command recursively finds all file and directories and sets user and group ownership to root.

Step 3 - Set directory permissions

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.

Step 4 - Set executable 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.

Step 5 - Set file 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:

If the Unix system hosting the Cams policy server supports normal user accounts, try logging in as a normal user.
Try to list the contents of: /usr/local/camsServer (permission should be denied)
Try changing directories to: /usr/local/camsServer (permission should be denied)
Try creating a test file in: /usr/local/cams/test.txt using a text editor like "vi" or "emac" (permission should be denied)

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:

the Cams policy server is currrently stopped
the Cams policy server is installed at C:\camsServer
the configuration directory is C:\camsServer\conf
You are logged in as Admin to your Windows NT/2000 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 NT and Windows 2000, so use the appropriate instructions below for your system.

Securing Windows NT Files and Directories

The following instructions apply to Windows NT 4.0.

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

This is done using the Windows NT graphical user interface.

Using the Windows Explorer file browser, select the top-level Cams policy server installation directory: C:\camsServer
Right click on the folder and select Properties from the pop-up menu
In the dialog box that appears, select the Security tab
Click on the Ownership button
In the dialog box that appear, confirm that Admin\Administrators is the intended owner, then click Take Ownership

Step 2 - Set all directory and file permissions

From the same Security tab in the context-sensitive dialog box for directory C:\camsServer used in Step 1:

Click on the Permissions button
In the Directory Permissions dialog box that appears, confirm that the directory Owner is now Admin\Administrators
Select check box Replace Permissions on Subdirectories (i.e. make sure it is checked)
Select check box Replace Permissions on Existing Files (i.e. make sure it is checked)
In the list of all User\Group items listed, Remove all items except Admin\Administrator
Select the list item Admin\Administrator, then select Type of Access = Full Control

Securing Windows 2000 Files and Directories

The following instructions apply to Windows 2000.

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

This is done using the Windows 2000 graphical user interface.

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.
Select the Security tab
Select the Advanced button. A dialog box entitled Access Control Settings for camsServer will appear.
Select the Owner tab.
Select the Admin user from the list at the top.
Select the Replace owner on subcontainers and objects check box
Select the OK button to apply ownership changes

Step 2 - Set all directory and file permissions

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.
Select the Remove button to remove inherited permissions explicitly specified on the camsServer directory.
Select the Add button. A dialog box entitled Select Users or Groups will appear.
Select the admin user from list at the top.
Select the Add button. The Admin user should now be added to the list at the bottom of the dialog box.
Select the OK button to apply the selected Admin user.
In the Permissions list, select check box: Allow/Full Control. This will cause all Allow column check boxes to become selected.
Select the OK button to apply the camsServer properties changes.

To test these directory and file permissions under Windows NT/2000:

Log out from the Windows NT/2000/2003 server Admin account and login using a normal user account (not Admin)
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).
If you will be running the Cams policy server as a Windows NT/2000/2003 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.

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, various HTTP request header values from the browser 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.

Cams web agent session hijacking is enabled by default, but you should also customize at least the following parameter for your site:

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

NOTE: Choose a new salt value and make sure all Cams web agents are configured with the same value.

Back | Next | Contents