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

Figure 24-10: CIDS sensor architecture

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

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.

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.

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

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.

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

Note

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:

10000	postofficed	#	Provides the IDS communication system
10001	sensord	#	Monitors network traffic when used with STK/Nortel
10002	configd	#	Provides ability to query runtime/configuration info
10003	managed	#	manages IDS components
10004	eventd	#	Configurable shell script support for handling events
10005	loggerd	#	Logs locally generated events and messages
10006	smid	#	Sends data to the director and duplicates messages
10007	sapd	#	File management control and database staging
10008	packetd	#	Monitors network traffic directly or from Cisco router
10009	reserved	#	Reserved for Cisco Systems use
10010	fileXferd	#	File Transfer Service

Note

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

Note

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.

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

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

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:

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:

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"

Note

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.