CIDS Architecture

CIDS Architecture

The preceding section described the operations and functionality of CIDS. To understand CIDS completely, you must also understand the architecture that makes up the CIDS. This section discusses the major architecture aspects of the CIDS environment. The following major components of the CIDS architecture are illustrated.

  • CIDS Software Architecture

  • CIDS Commands

  • CIDS Directory Structure

  • CIDS Log Files

CIDS Software Architecture

Both the sensors and the director platforms have their own OS and IDS software components. The components that make up the IDS software system are called daemons or services. Each function of CIDS is handled through different daemons or services, running on the sensor, director, or on both platforms. This architecture results in a modular software product that’s both fast and scalable.

CIDS is also a highly configurable distributed application. The services operating on a sensor or director platform depend on the configuration of the CIDS system as a whole. Minimally, a sensor must have packetd, postofficed, fileXferd, and loggerd daemons running, while the director should have smid, postofficed, fileXferd, and loggerd running.

The daemons each have a corresponding configuration file. This configuration file is used to tune the specific parameters used by the daemons. Parameters, called tokens, contained in the configuration files, are read by daemons residing on the sensor and director platforms. Configuration files are used to tune the CIDS system to operate according to your security policy. Another type of file, called system files, are used to configure the CIDS operating environment.

System files are used by the sensor and director platforms to describe and configure the environment in which they operate. System files are used to define the security infrastructure in which the host operates, as well as to identify other sensors and directors present on the network. System files provide vital information to the communications infrastructure used between sensors and directors.

The software installed on the director performs a different function than the software installed on the sensors. To describe the architecture of the IDS systems fully, this section first describes the sensor software architecture and then discusses the director software architecture.

Sensor Software Architecture

Sensors are the heart of any IDS system. Sensors perform the monitoring, analyzing, and alarm notification. Understanding the architecture of the CIDS sensors can provide a better understanding of the CIDS system as a whole. As seen in Figure 24-10, the architecture of the CIDS sensors is composed of six different services or daemons that work together to form the security system. The architecture of the sensors can be illustrated by defining each of these services and the functions they perform on behalf of the sensor. The services that run on each sensor are the following:

  • packetd

  • postofficed

  • loggerd

  • sapd

  • managed

  • fileXferd

    Click To expand
    Figure 24-10: CIDS sensor architecture


    You should be familiar with the daemons that make up the IDS system and the functions they perform.


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.


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


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.


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


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.

Cisco Secure Policy Manager Architecture

The architecture of the centralized director platform is illustrated in Figure 24-11. As the sensor monitors the networks and generates alarms, the postofficed daemon is responsible for receiving the alarms from packetd and forwarding them to the postofficed daemon on the director platform. Once an alarm or message is received on the director platform the director’s postofficed service will route the message or alarm to the appropriate service.

Click To expand
Figure 24-11: Director architecture

The director platform is responsible for alarm management, remote sensor configuration, event processing, and database functions. To accomplish these tasks, the following major daemons are run on the director platform:

  • postofficed

  • smid

  • eventd

  • loggerd

  • fileXferd


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.


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.


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


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.

Daemon Configuration Files

Each daemon, whether on the director or the sensor, has a corresponding configuration file. This configuration file allows security administrators to tune each daemon according to their own security requirements. These configuration files follow a simple naming convention: <daemon>.conf, where <daemon> is the name of the daemon with which the configuration file is associated. For example, the configuration file for the packetd daemon is named packetd.conf.

Each configuration file contains tokens. Parameters/tokens include things such as a router’s IP address or lists of IP addresses that should never be shunned. When a daemon is started, it reads the values associated with each token in its own configuration file. The values associated with each token are used as the daemon’s configuration. For example, the packetd daemon’s configuration file has a token named ReassembleFragments. The value for the ReassembleFragments token can be set to 0 or 1. If the value is set to 1, then the packetd daemon on the sensor will attempt to reassemble all fragmented packets. If the value is set to 0, the packetd daemon on the sensor won’t attempt to reassemble fragmented packets.

System Files

System files are used by the CIDS infrastructure to define and configure the environment in which they operate. System files are used to configure the security and network infrastructure of all CIDS components. System files are also used to identify organization, hosts, directors, routes, services, daemons, and signatures. The following list of system files are described in order of their use:

  • organization

  • hosts

  • services

  • auths

  • destinations

  • routes

  • daemons

  • signatures

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

If the hosts files aren’t identical across all directors and sensors (with exception to the localhost entry), some systems will generate an “unrecognizable host” error message in /usr/nr/var/errors.postofficed. If you’re having communication issues, check for this error message on each sensor and/or director.

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:




Provides the IDS communication system




Monitors network traffic when used with STK/Nortel




Provides ability to query runtime/configuration info




manages IDS components




Configurable shell script support for handling events




Logs locally generated events and messages




Sends data to the director and duplicates messages




File management control and database staging




Monitors network traffic directly or from Cisco router




Reserved for Cisco Systems use




File Transfer Service


Changing the application ID for any daemon on any host will cause IDS to fail and should only be done if directed by TAC.

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


Each entry in the auths file requires a corresponding host entry in the hosts file.

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 45000 1
director_one.acmecorp 1 45000 1
director_one.acmecorp 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 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:


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

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"

This file shouldn’t be confused with the signature database or the signature files located in the signature database. This is a system file used only to map a common name to a signature ID for use by Cisco Secure IDS applications.

CIDS Commands

Two different types of commands are available with CIDS: system commands and configuration commands. System commands allow the administrators to view and manage the IDS environment, while configuration commands are used to view and configure the CIDS sensor and director platforms.

System Commands

Several system commands can be used to view system information, as well as starting and stopping services running on the director or sensor platforms. Some of the more common commands that can be used are

  • idsstart

  • idsstop

  • idsconns

  • idsstatus

  • idsvers


    Be aware of the common system commands and the functions they perform.


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.


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


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]

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!

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.


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.

Configuration Commands

The sensors can be remotely configured and viewed via the director platforms. The following commands form the bases for remote configuration by the director platforms. Table 24-3 lists the sensor commands that allow for remote configuration from the director platform and Table 24-4 lists the syntax parameters used in these commands.

Table 24-3: Configuration Commands with Syntax





Used to retrieve a single piece of information from a token in a configuration file, such as the IP address of a managed router.

nrget <appid> <hostid> <orgid> <priority> <token> {<identifier>]


Used to retrieve multiple pieces of information from a token in a configuration file, such as a list of IP addresses currently being shunned.

nrgetbulk <appid> <hostid> <orgid> <priority> <token> {<identifier>]


Used to set attributes within a configuration file.

nrset <appid> <hostid> <orgid> <priority> <token> {<identifier>] <value1> [<value2>…..]


Used to remove or unset an attribute within a configuration file.

nrunset <appid> <hostid> <orgid> <priority> <token> {<identifier>]


Used to execute commands

nrexec <appid> <hostid> <orgid> <priority> <timeout> <token> {<identifier>]

Table 24-4: Syntax Parameter Description

Syntax Parameter



The application ID. The ID of the service or daemon. A complete list of application IDs can be located in /usr/nr/etc/services.


The PostOffice protocol host identification number, as previously defined.

<identifier> (Optional)

An additional piece of information that can be used to identify a token. This piece of information is optional.


The PostOffice protocol organizational identification number as previously defined.


An integer representing the priority of the command.


Used only for nrexec, this command specifies the amount of time (in seconds) to wait until the process is considered unreachable.


The name of the token to set or from which to get information.


The value to which the specified token should be set.

CIDS Directory Structure

The CIDS directory structure follows a hierarchy modeled after the UNIX OS. The organization of the structure allows administrators to locate important system and configuration files quickly. The only variable in the directory structure is the name and location of the installation directory on Windows NT 4.0 servers. As seen in Figure 24-12, below the install directory, each structure is the same on both the director and the sensors. The following are the directories installed on both the sensors and the director platforms:

  • Install directory

  • bin

  • etc

  • var

    Click To expand
    Figure 24-12: IDS Directory structure

The Install Directory (/usr/nr)

The installation directory on the sensors is the nr directory, which is a subdirectory of /usr, so the installation directory on all sensors is /usr/nr. Sensor appliances come with the IDS software preinstalled, so the installation directory should always be /usr/nr.

The bin Directory (usr/nr/bin)

The bin directory is used for the storage of all the executable files for CIDS. All CIDS’ daemons, services, and functions are stored in the /<install dir>/bin directory. These files were defined earlier in this chapter. The files stored in the bin directory can be loosely grouped into three categories:

  • Daemons

  • Configuration Commands

  • System Commands

The etc Directory (usr/nr/etc)

The etc directory (pronounced etsee) is a common UNIX directory used for storing system configuration files. Anyone experienced with the UNIX OS should be familiar with the etc directory and the types of files stored there. The etc directory on the sensors and director platforms stores the following two types of files:

  • Daemon Configuration files

  • System files

The var Directory (usr/nr/var)

The var directory is the default directory for all log files. Files created by loggerd and error files for all the daemons are stored in this directory.

CIDS Log Files

During typical operations, the CIDS infrastructure components generate a great deal of information in the form of log files. Log files are created via the loggerd daemon. These log files are stored as text files on both the sensor and director platforms. To assist with troubleshooting your system, you should be aware of the types of files, as well as the location of these log files. Additionally, you can create your own custom scripts to pull information from the log files to create custom reports. Cisco Secure IDS provides four types of log files:

  • Events

  • Service Error

  • Commands

  • IP Sessions

All event, error, command, and session log data is stored in a common, comma-delimited flat file that can be imported into any database. These four types of logging are written to a text file for performance reasons. Adding text to an open text file is faster than writing the information to a database. Text files are always available and don’t rely on a database engine for access to the data, providing greater flexibility to access this important information. For manageability, these text files must periodically be closed, archived, and a new file opened.

Log File Management

For performance and manageability reasons, the log files must be periodically closed and archived. When one log file is closed, another must be opened to take its place. Two factors affect when a log file is closed and a replacement is created: the size of the log file and the time threshold.

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.

Event Logs

The purpose of any intrusion detection system is to generate alarms when intrusive activity is detected. These alarms, called events, are written to log files on the sensors and, in some cases, also on the directors. By default, level 1 and higher events are logged on the sensor, and level 2 to 5 events are forwarded to the director and written to the director’s log file. Therefore, level 2 to 5 events are written to the sensor and director log files. Information written to the event logs includes the following:

  • Which sensor detected the event

  • When the alarm was generated

  • The type of alarm

  • The source and target of the event

Event logs are written to the /usr/nr/var directory and follow the log .YYYYMMDDHHMM naming convention where:

  • Log Keyword identifying this as an event log

  • YYYY The four-digit year the file was created

  • MM The two-digit month the file was created

  • DD The two-digit day the file was created

  • HH The two-digit hour the file was created (24-hour clock)

  • MM The two-digit minute the file was created

An example of a CIDS event log file is


From the previous example, you can see this log file was created at 12:01 A.M. on 1/1/2003.

Service Error Logs

When any service or daemon generates an error, the error information is written to an error log file. Administrators can then use this error log file to troubleshoot and resolve issues within the CIDS infrastructure. The naming format used for service error log files is error.service.processID, where:

  • error—Keyword identifying this file as a service error log

  • service—The service or daemon that generated the alert

  • processeID—Numeric value of the service process identification number

Command Logs

Whenever a service or daemon performs any function that issues a command to the IDS system, the command is logged in a command log file. Information logged includes the name of the daemon that issued the command, the date and time, the host, and the service to which the command was issued.

IP Session Logs

The CIDS system can be configured to log IP session information once a specific event (alarm) is triggered. If a signature is matched, the sensor can respond by recording all IP session activity to a session log. This log provides a permanent record to the intrusion and activity. IP session logs capture all incoming and outgoing TCP packets associated with a specific connection, so they contain binary data.

By default, IP session logs are retained on the sensors until they’re needed on the director platforms. This prevents the large amounts of data recorded in IP session logs from impeding CIDS communications during periods of network load.

The naming format used for IP session log files is iplog.XXX.XXX.XXX.XXX .YYYYMMDDHHMM where:

  • iplog—Indicates this is an IP session log file

  • XXX.XXX.XXX.XXX—Indicates the IP address of the attacking host

  • YYYYMMDDHHMM—Indicates the year, month, day, hour, and minute the log file was created

An example IP session log might be named as the following:


From simply reading the file name, you know a host using the IP address performed some operation that triggered an alarm. The configured response on the sensor, for this alarm, was to create and IP session log. Additionally, you know this attack started on 12/31/2002 at 11:59 P.M. (assuming this is the only IP session log).

Part III: Virtual Private Networks (VPNs)