CIDS Architecture

packetd

packetd is the interface between the network and the sensor. The packetd service captures packets on the monitored network and performs an intrusive detection analysis on those packets. If intrusive activity is discovered, packetd generates and forwards an alarm to the postofficed service. In addition to generating alarm messages, packetd can be configured to automatically instruct managed service to shun an IP address for a specified period of time.

postofficed

The postofficed service is the communication vehicle for the entire CIDS product. All communication between daemons is routed through this service. Each sensor relies on postofficed to maintain communication with the postofficed daemon running on other hosts. The postofficed daemon service includes the following features:

• A proprietary connection-based protocol that resends a message whenever any of its packets are lost.

• Point-to-point routes that might include intermediate post-office nodes.

• Communication integrity is maintained via alternate routes. When one route fails, communication is switched to an alternate route. Communication is reestablished to the preferred route as soon as it comes back online.

Routing is based on a three-part key that includes the following information:

• Organization ID

• Host ID

• Application ID

loggerd

loggerd is the logging service used by CIDS; as such, the loggerd daemon writes out sensor and error data to flat files received by one or more of the other daemons. This data is passed to loggerd via postofficed. loggerd creates two basic types of flat files: a single sensor event file and one or more IP session logs.

sapd

The Security Analysis Package Daemon (sapd) is responsible for file system maintenance, such as file deletion and moving log files to the database staging areas. The sapd daemon is a user-configurable scheduler that controls database loading and archival of old event and IP session logs.

managed

The managed daemon is responsible for the managing and monitoring of all network devices configured for device management. For example, when packetd discovers a signature has been matched and the signature is configured for IP blocking, packetd sends a shun command to managed via the postofficed service. managed is then responsible for reconfiguring the router’s ACL. The Director can also send these shun commands to the managed daemon. managed can also be polled for operational statistics, such as:

• The number of network devices being managed

• The type of device being managed

fileXferd

The fileXferd daemon is responsible for the transfer of configuration files between the director platforms and the sensors. On the sensor, fileXferd is responsible for receiving configuration files from the director platforms.

postofficed

The postofficed daemon runs on the director as well as sensors and performs the same function on each. The postofficed service is responsible for all communications between services residing on the host, as well as all communications between hosts.

smid

The smid daemon’s primary function is to populate the alarm icons on the director’s HP OpenView (HPOV) maps, but smid can also be used to redirect messages to other daemon services, such as eventd and loggerd.

eventd

The eventd daemon can be configured to take specific actions based on messages received from the smid service. A common use for this feature is to configure eventd to send notification via e-mail to pagers for any alarms of a severity 4 or higher.

loggerd

loggerd is the logging service used by CIDS. The loggerd daemon writes out sensor and error data to flat files received by one or more of the other daemons. This data is passed to loggerd via postofficed.

fileXferd

The fileXferd daemon is responsible for the transfer of configuration files between the director platforms and the sensors. The director platform fileXferd is responsible for sending the configuration files.

The organization File

The organization file lists all the organization IDs currently registered for a Cisco Secure Intrusion Detection System domain. The entries contained in the organization file must adhere to the following format:

<org_id> <org_name>

The org_id is the user-defined organization ID used to identify a group of director and sensor platforms. The org_name is the corresponding name associated with the org_id. This file must be exactly the same across all sensor and director platforms within a Cisco Secure IDS domain. A typical organization file might look like the following:

125 acmecorp
130 abccorp
135 xyzcorp

The hosts File

The hosts file is much like the \etc\hosts file on UNIX systems or the winnt\system32\etc\hosts file on Windows NT/2000 systems. Just like the associated files, the hosts file is used to identify sensors and directors within the CIDS domain. The hosts file lists the known host IDs, host names, organization IDs, and organization names. Besides listing all known hosts, this file must also have an entry for the local host. The contents of the hosts file should be identical across all sensors and directors, with the exception of the entry for the localhost. The entries contained in the host file must adhere to the following format:

<host_id> . <org_id> <host_name> . <org_name>

A typical hosts file might look like the following:

10.120 localhost
10.125 sensor_one.acmecorp
10.130 sensor_two.acemcorp
10.100 director_one.acmecorp

The services File

The services file lists the application IDs of all daemons. When the application_id is combined with the host_id and org_id, these identifiers uniquely identify a specific daemon running on the specified host. CIDS uses these IDs to build a complete Cisco Secure IDS security map. The entries contained in the services file must adhere to the following format:

<application_id> <daemon_name> [<comment>]

The application_id is a Cisco-generated ID number that identifies the CIDS daemon. The <daemon> parameter identifies the name of the daemon the application_id represents. The <comment> parameter is optional and can be set to provide additional information about the service. All sensor platforms should have the same default services file, which contains the following entries:

The auths File

The auths file is used for basic host authentication. This file lists the hosts, as well as which configuration commands these hosts are authorized to perform on the local host. The possible configuration commands that can be issued are nrget, nrgetbulk, nrset, nrunset, and nrexec. Configuration commands are discussed in the section “Configuration Commands.” The entries contained in the auths file must adhere to the following format:

<host_name> <configuration_command_1>, [<configuration_command_2….]

The host_name must follow the CIDS naming structure where the host name is <host_name.org_name>. An example auths file might contain the following:

director_one.acmecorp NRGET, NRGETBULK, NRSET, NRUNSET, NREXEC
director_two.acmecorp NRGET, NRGETBULK
sensor_one.acmecorp GET

In the previous example, director_one.acmecorp is allowed full authorization, while director_two.acmecorp is only allowed to read data.

The destinations File

CIDS is a distributed application that allows the exchange, or routing, of information from a given communication service (postofficed) to a daemon service on any host. Using the PostOffice protocol, daemons running on any host can communicate with other daemons running on any other host, as long as the following three conditions are met.

1. Both the sending host and the receiving host must be identified in the hosts file (previously mentioned).

2. Any daemons attempting to send or receive messages must be listed in the services file (previously mentioned).

3. An entry in the destinations file permits both the severity and the type of message being sent.

The destinations file defines the type and severity of messages that will get routed to any given daemon on any specific host. The entries contained in the destinations file must adhere to the following format:

<destination_id> <host_name> <daemon_name> <message_level> <message_type>

An example auths file entry might contain the following:

1 director_one.acmecorp smid 2 EVENTS, ERRORS, COMMAND, IPLOG

The previous example represents an example configuration on a sensor. In the example, the sensor would send all level 2 and higher events, errors, commands, and IP logs to the host director_one.acmecorp (assuming an entry exists in the hosts file for director_one.acmecorp). You can configure a maximum of 32 different locations in the destinations file.

The postofficed daemon can forward messages to the following three services:

• loggerd

• smid

• eventd

The routes File

The routes file represents the routing table used by the postofficed to send messages to remote hosts. The routes file maps the IP address or next hop IP address to the host. The host name used in this file must have a corresponding listing in the hosts file. The entries contained in the routes file must adhere to the following format:

<host_name> <connection_num> <ip_address> <udp_port> <type>

The host name must match an entry in the hosts file. The <connection_num> represents the priority of this route as compared to other entry’s listing routes for the same host. The lower the number, the higher the priority. If two route entries have the same priority, postofficed will use the last entry for that priority. The <ip_address> represents the end-point IP address or the next-hop address to reach the specified host name. The <udp_port> represents the UDP port number that should be used when communicating with the host. By default, the UDP port number is 45000. The <type> defines the type of connection that should be used to reach the host, dialup or dedicated. The <type> field currently isn’t in use.

An example routes file might contain the following entries:

sensor_one.acmecorp 1 192.168.1.1 45000 1
director_one.acmecorp 1 10.10.10.1 45000 1
director_one.acmecorp 3.10.100.100.1 45000 1

In the previous example, sensor_one has two different connections that can be used to reach director_one. Sensor_one will prefer to use the IP address 10.10.10.1 to reach director_one because it has a lower connection_num.

The daemons File

The daemons file lists the name of the daemons that should be started when the sensor or director platforms are started. The services file lists all the services that a director or sensor is capable of running, while the daemon file lists which services should be run each time the system is started. The entries contained in the daemons file must adhere to the following format:

<daemon_name>

The following example illustrates a daemons file that would start the postofficed, loggerd, and smid daemons:

nr.postofficed
nr.loggerd
nr.smid

The signature File

The signature file is used primarily by the director platforms to map a common signature name to a signature ID. The signature file shouldn’t be modified manually. The entries contained in the routes file must adhere to the following format:

<signature_id> “<signature_name>“

An example signature file would contain the following entries:

1000    "Bad Option List"
1001    "Record Packet Rte"
1002    "Timestamp"
1003    "Provide s, c, h, tcc"
1004    "Loose Src Rte"
1005    "SATNET ID"

idsstart

You can use the idsstart command to start the CIDS services on your sensor. This command will start all services located in the /usr/nr/etc/daemons configuration file.

idsstop

The idsstop script can be used to stop the CIDS services running on your sensor.

idsconn

The idsconn script is provided to assist with troubleshooting communication issues between the sensors and other IDS hosts. The idsconn script can be used to display the status of all connections between the local sensor and other IDS devices, such as a sensor or a director. When this command is issued on the sensor, the script returns a list of open Cisco Secure IDS communication routes.

The script returns the following information for each open connection:

<host_name>.<org_name> Connection 1: <ip_address> 45000 1 [Established]
sto:5000

If a connection is down, the following is returned:

<host_name>.<org_name> Connection 1: <ip_address> 45000 1 [SynSent] sto:5000 syn NOT rcvd!

dsstatus

To view or confirm that the correct services are running on your sensors, you can use the idsstatus script, which returns a list of all IDS daemons currently running on the sensor. The UNIX ps command can also be used to list all services running, however, the ps command returns a list of all daemons, while the idsstatus script returns a list consisting of only the IDS daemons currently running.

idsvers

The idsvers script can be used to verify the version of services the sensor is currently running. The idsvers script returns a list of currently running daemons and their version numbers.

Closing Log Files

Whenever a log file grows too large or is open too long, a new log file is created to take its place. The name of the new log file depends on the type of log. file and is discussed in the next few sections detailing each type of log file. By default, a log file is closed and another is created when the log file is 60 minutes old or has reached a file size of 1GB, whichever happens first. The 60-minute and 1GB defaults can be changed by modifying tokens in the loggerd.conf daemon configuration file.

The IP session log files have their own set of criteria that determines when a new log file is created. IP session logs are closed every 30 minutes or when the IP session they’re recording is terminated.

Storage of Active and Archived Log Files

Current event and error log files are stored in the /usr/nr/var directory, while archived event and error log files are stored in the /usr/nr/var/new directory. Current IP session log files are stored in the /usr/nr/ var/iplog directory and archived IP session logs are stored in the /usr/nr/var/iplog/new directory.