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 always 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 system 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 Agents, including: the Cams server, security domains, graceful shutdown, agent authentication, and agent access control

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

Figure 1 - A possible network topology using Cams

The firewall between Cams web agents and the Cams server should be configured to allow agents to initiate connections from any client-side port to the specific Cams 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 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 web agent's subnet to the internal IP address of the host running the Cams server.

The Cams 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 server remotely.

The Cams 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 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 Cams and these resources!

Securing Communications

By default, Cams selectively encrypts sensitive network communications using a configurable PKI algorithm and secret key. Some agents also support SSL communications with the Cams 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 clear text.

SSL provides superior security at the cost of lower performance and more difficult administration. When using SSL, all data transferred between the Cams agent and server are 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 agents to verify the identity of a Cams server.

NOTE: Cams is not currently packaged with SSL support of the agent connections to the Cams server. However, it is possible to configure Cams with SSL support. Packaged support will be provided in a future release. If you have need of this level of confidentiality now, please contact Cafésoft support for further instruction.

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

Securing Cams Communications using Secret Keys

Similarly, communications between the Cams server and user repositories 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 server is 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 server or agent are executed as the appropriate administrative user (root or Administrator), hereafter referred to as the owner. This enables Cams and Cams utilities 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 server is executed by root on your Linux/UNIX system. For the sake of this example, assume that:

Cams 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 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 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 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 agent. See the appropriate agent configuration guide for more details.

To test these permissions:

If the Unix system hosting Cams 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

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

The Cams Server is currrently stopped
Cams is installed at C:\camsServer
The configuration directory is at: 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 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 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 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 Server as a Windows NT/2000 "Service", make sure the service is run under the Admin user indentity. Try starting and stopping the Cams Server Service.

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

Securing Cams Services and Agents

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

Cams Server

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

You should change the name of your Cams server from MyCamsServer to something unique for your site. This value is used for logging and to distinguish Cams 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. For example: myhost_domain. Alphanumeric and underscore ("_") characters are valid. You'll also need to change the corresponding name in the configuration file for each Cams agent.

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

You can change the Cams 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 from the standard Cams default value. Again, you'll also need to make corresponding changes in the configuration file for each Cams agent.

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

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

#
#--- The TCP/IP port on which Cams 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 server. If a secret key is installed, the shutdown password is encrypted before being sent from the shutdown client to the Cams 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, many major Internet Service Providers, will transmit HTTP and HTTPS network traffic via different routes by use of proxy servers. In addition, some routers are setup to used "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.

Other usernames and passwords specified in session event handlers, service manager services, etc. are for connections to user repositories. Any defaults that are provided must obviously be changed to work with your site's data repositories. Data repository connections in login-config.xml also 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 agent authentication. In this respect, you could add a list of valid hostnames or IP addresses to the agent authentication rule.

You will need to change cams-users.xml in the system security domain. This is where the default Cams agent profiles are stored. You should minimally change the passwords and possibly the username and role for 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-users>
 	<!-- Cams http agent connection authentication accounts -->
 	<user name="cams-tomcat-agent" password="password" roles="cams-agent"/>
 	<user name="cams-apache-agent" password="password" roles="cams-agent"/>
</cams-users>

Agents

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

Securing Agent Authentication

Each Cams agent must authenticate with the Cams server by supplying a username and password. The username and password must match a profile in the corresponding security domain's user repository. By default, this is the cams-users.xml file in the system security domain, but can easily be modified to use an LDAP server or SQL server.

The Cams Tomcat web agent is pre-configured with the following username/password parameter defaults:

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

The Cams Apache web agent is pre-configured with the following username/password parameter defaults:

connection.authentication.principal=cams-apache-agent
connection.authentication.credential=password

You should change each of 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 server. For example, if you change the Cams server name or connection port, you must change the corresponding value in the 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 agents to a Cams server.

Securing Agent Access Control

The Cams system security domain's access control policy contains default rules for controlling access by Cams 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 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 agents

Back | Next | Contents