|
|
January 2001
This publication describes the internal architecture of the Cisco Secure Intrusion Detection System (IDS), which is made up of the Director, Sensor, and Intrusion Detection System Module (IDSM).
This document contains the following sections:
The goal of this document is to provide details on various internal functions and processes of Cisco Secure IDS, including file and directory structure; daemons, their associated configuration files and tokens; system files; and commands.
Under normal Cisco Secure IDS operation, detailed knowledge of the architecture and underlying configuration files is not required. Sensor configuration and control should normally be done via the GUI provided on the Director. The information contained in this document may be useful during troubleshooting and in specialized operational environments.
The intended audience is advanced Cisco Secure IDS administrators.
The following terms are used throughout this document:
| Token Name | Associated Configuration File |
|---|---|
ControlPost | sapd.conf |
ControlPre | sapd.conf |
ControlRun | sapd.conf |
ControlUndo | sapd.conf |
DisplayMode | sapd.conf |
DupDestination | smid.conf |
EnableAclLogging | managed.conf |
EventAlarmInterval | eventd.conf |
EventAlarmThreshold | eventd.conf |
EventApplication | eventd.conf |
FilenameOfIPLog | loggerd.conf |
FilenameOfLog | loggerd.conf |
FilenameOfLogNew | loggerd.conf |
FM_Action | sapd.conf |
FM_CronTime | sapd.conf |
FM_DirFiles | sapd.conf |
FM_DirSize | sapd.conf |
FM_DirUsed | sapd.conf |
LevelOfTrafficLogging | packetd.conf |
LogFileMask | sapd.conf |
LogFilePathDump | sapd.conf |
LogFilePathIPLog | sapd.conf |
LogFilePathNew | sapd.conf |
LogFilePathOld | sapd.conf |
LogFilePathTmp | sapd.conf |
LogFilePathVar | sapd.conf |
MaxShunEntries | managed.conf |
MinContextLevel | loggerd.conf |
MinutesOfAutoLog | packetd.conf |
MinutesOfAutoShun | packetd.conf |
NameOfPacketDevice | packetd.conf |
NetDevice | managed.conf |
NeverShunAddress | managed.conf |
NotifyInterval | sapd.conf |
NotifyPerson | sapd.conf |
NumberOfRcptTo | packetd.conf |
NumberOfSwitchBytes | loggerd.conf |
NumberOfSwitchMinutes | loggerd.conf |
PollingDelay | sapd.conf |
PortMapping | packetd.conf |
ProfileDetection | packetd.conf |
ProfileEnabled | packetd.conf |
ProfileResponse | packetd.conf |
ReassembleFragments | packetd.conf |
ReassembleMaxDgrams | packetd.conf |
ReassembleMaxFragmentsPerDgrams | packetd.conf |
ReassembleFragmentTimeout | packetd.conf |
ReassembleMaxTotalFragments | packetd.conf |
RecordofExcludedPattern | packetd.conf |
RecordOfStringName | packetd.conf |
ShunAclCisco | managed.conf |
ShunInterfaceCisco | managed.conf |
SigOfFilterName | packetd.conf |
SigOfGeneral | packetd.conf |
SigOfStringMatch | packetd.conf |
SigOfTcpPacket | packetd.conf |
SigOfUdpPacket | packetd.conf |
TCPThreeWayHandShake | packetd.conf |
TCPStrictReassembly | packetd.conf |
TCPOpenEstablishTimeout | packetd.conf |
TCPEmbryonicTimeout | packetd.conf |
WatchDogInterval | postofficed.conf |
WatchDogNumProcessRestarts | postofficed.conf |
WatchDogProcDeadAlarmLevel | postofficed.conf |
WatchDogProcTimeOutAlarmLevel | postofficed.conf |
WatchDogResponseTimeOut | postofficed.conf |
A thorough understanding of the Sensor file structure will help you configure and install the Sensor as well as help you better utilize Cisco Secure IDS's features. This file structure serves as the foundation for both the Director and Sensor systems.
The default directory location for the Sensor subsystem is /usr/nr, which contains the following directory structure:
/usr/nr/bin/usr/nr/bin/eventd /usr/nr/bin/eventd/skel /usr/nr/bin/sap /usr/nr/bin/sap/skel /usr/nr/bin/sap/sql /usr/nr/bin/sap/sql/skel
/usr/nr/etc/usr/nr/etc/.lt /usr/nr/etc/backups /usr/nr/etc/licenses /usr/nr/etc/nrConfigure /usr/nr/etc/oem /usr/nr/etc/oem/templates /usr/nr/etc/wgc /usr/nr/etc/wgc/templates
/usr/nr/lib /usr/nr/skel /usr/nr/tmp/usr/nr/tmp/queues
/usr/nr/var/usr/nr/var/dump /usr/nr/var/iplog /usr/nr/var/new /usr/nr/var/tmp
The remainder of this document provides information on the Cisco Secure IDS components in this file structure.
The /usr/nr/bin directory contains all of the executables required to run and administer the application services that support a Sensor or Director. These can be loosely grouped into three basic categories:
Cisco Secure IDS is a collection of discrete subsystems that have been implemented via daemons, each with its own well-defined set of services.
Cisco Secure IDS is also a highly configurable distributed application. The daemon services running on a Sensor or Director depend on the configuration of the application as a whole. At a minimum, a Sensor must have packetd, fileXferd, loggerd, and postofficed daemons running. A Director should have postofficed, fileXferd, smid, and loggerd running. In a multi-tiered configuration, one Director system could be configured to only stage data to an RDBMS via loggerd and sapd, while another Director system could be dedicated to monitoring and response via the smid and configd daemons.
The full complement of Sensor daemons is as follows:
The eventd daemon allows the Director or Sensor to generate user-defined actions for events received by smid. A common action is to generate pager notifications via e-mail for alarms of severity 4 and above.
The fileXferd daemon is used for file transfer between Sensors and Directors. It is used to transport configuration files between Directors and Sensors.
The loggerd daemon writes out sensor and error data to flat files generated 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. Data is written to flat files for reasons of performance and fault tolerance.
The managed daemon is responsible for managing and monitoring network devices (routers and packet filters). For example, when packetd identifies that a certain type of attack should be shunned, it sends a shun command to managed via the post office facility. managed then reconfigures an ACL appropriately. Similar commands can be sent to this daemon from the Director. managed can also be polled for operational statistics such as:
The packetd daemon interprets and responds to all of the events it detects on the monitored subnet. The types of messages packetd sends to other daemons is based on information stored in /usr/nr/etc/packetd.conf. Where these messages are routed is defined in /usr/nr/etc/destinations.
Although packetd supports 256 levels of alarm events (0-255), only levels 0-5 are currently being used. Level 0 is an internal alarm that packetd uses to track such services as RIP, ICMP, and so on; it is never routed to postofficed. Level 0 is also used to disable a signature.
Levels 1-5 are sent to postofficed, and they identify increasing patterns of misuse, where 5 is the highest type of alarm. Every alarm message includes an alarm ID that identifies a specific attack signature. These alarm signatures are enumerated in /usr/nr/etc/packetd.conf as SigOfGeneral entries.
In addition to generating alarm messages for a Director application, packetd can automatically instruct managed to shun an attack for a specified period of time.
The postofficed daemon serves as the communication vehicle for the entire Cisco Secure IDS product. All communication between daemons is routed through this service. In most Cisco Secure IDS configurations the Sensor and Director systems reside on separate hosts. Each system relies on postofficed to maintain communication with the other. postofficed is required even when all of the systems are located on a single host. This daemon service includes the following features:
Routing is based on a three-part key that includes the following information:
The organization IDs are defined in /usr/nr/etc/organizations; host IDs are defined in /usr/nr/etc/hosts; daemon IDs are defined in /usr/nr/etc/services.
The sapd daemon is a user-configurable scheduler that controls database loading and archival of old event and IP session logs. Oracle or Remedy database loading is accomplished with sapx. Data archival is controlled with the native dump scripts. sapd removes old files in the dump directory when disk usage reaches a specified level.
The smid daemon's primary function is to populate the alarm icons on the Director's HPOV maps. Additionally, smid can redirect messages to other daemon services, such as eventd and loggerd based on DupDestination entries in /usr/nr/etc/smid.conf file.
Table 2 lists the built-in commands on the Sensor that allow remote devices to configure and gather information about the Sensor. These commands serve as the foundation for the Director's nrConfigure interface.
| Command | Description | Syntax |
|---|---|---|
nrget | Retrieves single pieces of information (for example, one IP address of a managed router). | nrget <appid> <hostid> <orgid> <priority> <token> [<identifier>] |
nrgetbulk | Retrieves information as a list (for example, a list of IP addresses being shunned). | nrgetbulk <appid> <hostid> <orgid> <priority> <token> [<identifier>] |
nrset | Sets attributes. | nrset <appid> <hostid> <orgid> <priority> <token> [<identifier>] <value> [<value>...] |
nrunset | Unsets attributes. | nrunset <appid> <hostid> <orgid> <priority> <token> <identifier>] |
nrexec | Executes commands. | nrexec <appid> <hostid> <orgid> <priority> <timeout> <token> [<identifier>] |
Table 3 provides a syntax description for the commands.
| Syntax Element | Definition |
|---|---|
<appid> | The application ID. A complete list of application IDs is in /usr/nr/etc/services. |
<hostid> | The host ID. A complete list of host IDs is in /usr/nr/etc/hosts. |
<identifier> | An optional piece of information to further identify a token. |
<orgid> | The organization ID. A complete list of organization IDs is in /usr/nr/etc/organizations. |
<priority> | The relative priority of the command, expressed as an integer. |
<timeout> | The time in seconds to wait until the process is deemed unreachable (used only for nrexec.) |
<token> | The name of the token to set or get information from. |
<value> | The value that the |
For example, use the following command to retrieve the value set for sapd's ControlPre token (given a Host ID of 10 and Org ID of 100):
nrget 10007 10 100 1 ControlPre
The command returns the following:
/usr/nr/bin/sap/load_pre.sh
The following scripts are used to perform maintenance on the Sensor:
Executing this script returns a list of open Cisco Secure IDS communication routes. 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!
The following indicates an established connection:
<host_name>.<org_name> Connection 1: <ip_address> 45000 1 [Established] sto:5000
This script starts the Cisco Secure IDS daemons. It supports the following options:
-d Don't daemonize -v Show version number
The command takes the following form:
idsstart [-d] [-v]
Executing this script stops the Cisco Secure IDS daemons.
Executing this script returns a list of currently running daemons. The typical output for a Sensor would be the following:
netrangr 301 1 0 May 18 ? 0:01 /usr/nr/bin/nr.fileXferd netrangr 298 1 0 May 18 ? 0:01 /usr/nr/bin/nr.loggerd netrangr 198 1 0 May 18 ? 0:56 /usr/nr/bin/nr.postofficed netrangr 300 1 0 May 18 ? 0:01 /usr/nr/bin/nr.sapd netrangr 302 1 0 May 18 ? 1:33 /usr/nr/bin/nr.packetd netrangr 299 1 0 May 18 ? 0:01 /usr/nr/bin/nr.configd
On a Director, typical output would be the following:
netrangr 439 1 0 May 18 ? 0:09 /usr/nr/bin/nr.loggerd netrangr 466 1 0 May 18 ? 0:16 /usr/nr/bin/nr.fileXferd netrangr 465 1 0 May 18 ? 0:06 /usr/nr/bin/nr.smid netrangr 430 1 0 May 18 ? 0:07 /usr/nr/bin/nr.configd netrangr 455 1 0 May 18 ? 0:15 /usr/nr/bin/nr.sapd
The /usr/nr/etc directory contains two types of files:
This section discusses the system files, which currently include the following:
These files are modeled after UNIX /etc files, and UNIX system administrators should have no problem understanding their format and entity relationships.
 |
Note The system files are described in order of use rather than alphabetically. |
This file identifies all of the organizations and their organization IDs currently registered for a given Cisco Secure IDS. Each entry has the following format:
<org_id> <org_name>
where <org_id> is a user-generated ID that uniquely identifies a group of related Sensors and Directors, and <org_name> is a name that is associated with that unique ID. A typical file might look like the following:
100 companyabc 101 companydef 102 companyghi 1001 companyjkl
|
Note This file serves as a global registry that must agree across all of the Sensor and Director systems within a Cisco Secure IDS domain. |
This file is much like a UNIX /etc/hosts file. It enumerates the organizations and hosts that are recognized by a given Sensor or Director system in a Cisco Secure IDS configuration. Each entry has the following format:
<host_id>.<organization_id> <host_name>.<organization_name>
where <host_id> and <organization_id> are user-assigned numeric identifiers, and <host_name> and <organization_name> are DNS-like user-assigned names. In addition to a list of recognized hosts, this file always contains a localhost entry.
A typical hosts file might look like the following:
10.100 localhost 10.100 admin.companyabc 11.100 dev.companyabc 12.100 data.companyabc 13.100 Sensor-1.companyabc 14.100 Sensor-2.companyabc 15.100 Sensor-3.companyabc
|
Note Entries for each host must be consistent across all Sensor and Director systems. Otherwise, some systems will generate "unrecognizable host" messages in /usr/nr/var/errors.postofficed. |
This file defines the application_id for each of the daemon services found in /usr/nr/bin. When combined with the host_id and organization_id, these identifiers uniquely identify a daemon within a Cisco Secure IDS security map. Each entry has the following form:
<application_id> <daemon_name> [<comment>]
where <application_id> is a Cisco-generated ID number that uniquely identifies the Cisco Secure IDS daemon, <daemon_name> is the name of the daemon, and <comment> provides some additional information.
All Sensor hosts should have the same default services file, which is currently defined as follows:
10000 postofficed # Provides the IDS communications 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 or daemon_name of any of the existing records causes the IDS to fail. |
This file identifies which type of token operations are authorized for the each of the hosts listed in this file. Each entry follows this form:
<host_name> <configd_services>
where <host_name> is the name of the host (in Cisco Secure IDS format: hostname.orgname) and <configd_services> is a comma-delimited list of authorized commands allowed by the host.
In the following example, admin.cisco has full authorization, whereas data.cisco can only read configuration information:
admin.cisco GET,GETBULK,SET,UNSET,EXEC data.cisco GET,GETBULK sensor.cisco GET,SET,UNSET,EXEC
|
Note Each entry in /usr/nr/auths must have a corresponding entry in /usr/nr/etc/hosts. |
Cisco Secure IDS is a distributed application that has the ability to route messages from a given communication service (postofficed) to any of the daemon services registered in the /usr/nr/etc/hosts and /usr/nr/etc/services files. The destinations file identifies what type of messages get routed to a given application on a given host. Each entry is of the following form:
<destination_id> <host_name> <daemon_name> <message_level> <message_type>
where <destination_id> is a Numeric ID (up to 32 destinations are currently allowed); <host_name> must be an entry from /usr/nr/etc/hosts; <daemon_name> must be an entry from /usr/nr/etc/services; <message_level> identifies the level of messages that will be routed (messages below that level are not passed on to postofficed); <message_ type> identifies the types of messages to route in a comma-delimited list.
For example, in the following destinations file, level 2 (and higher) event, error, command, and IP_log message types are being routed to the smid daemon on the host admin.cisco. This type of configuration would normally be found on a Sensor system, where admin.cisco is a Director system:
1 admin.cisco smid 2 EVENTS,ERRORS,COMMANDS,IPLOGS
This file identifies the actual IP routes that postofficed uses to send messages between different hosts. Each entry is of the following form:
<host_name> <connection_num> <ip_address> <udp_port> <type>
where <host_name> must be an entry from /usr/nr/etc/hosts; <connection_num> identifies the priority of this entry relative to the other routes to the same host enumerated in this file (the lower the number, the higher the route priority—if there is more than one entry of the same priority, postofficed accepts the last entry of that priority); <ip_address> identifies the end-point or next hop IP address of the remote system; <udp_port> identifies the UDP port service to route through on each host—the default port is 45000; <type> identifies whether the connection is a dial-up vs. dedicated connection. This field is currently not used.
In the following routes file for sensor1.cisco, two direct connections exist between sensor1 and director1 (director1 is dual-homed with IP addresses 10.1.7.9 and 10.4.7.12):
sensor1.cisco 1 192.16.1.1 45000 1 director1.cisco 1 10.1.7.9 45000 1 director1.cisco 2 10.4.7.12 45000 1
In the following routes file for sensor1.cisco, a line has been added for a direct connection between sensor1 and director2 (director2 is also dual-homed, with IP addresses 192.16.1.12 and 10.4.7.13). The last line of the routes file indicates that sensor1 can route information to director1 via director2 if all other routes fail. Notice that director2's IP address is used for the third route to director1, and is not considered a direct connection. The third rout to director1 uses director2 as a hop.
sensor1.cisco 1 192.16.1.1 45000 1 director1.cisco 1 10.1.7.9 45000 1 director1.cisco 2 10.4.7.12 45000 1 director2.cisco 1 192.16.1.12 45000 1 director1.cisco 3 192.16.1.12 45000 1
This file contains the names of daemons that should be started when the system starts up. Each entry is of the following form:
<daemon_name>
where <daemon_name> is the name of the daemon in the following format: nr.<daemon_name>.
For example, the following sample entry would start postofficed, loggerd, and smid on a Director system:
nr.postofficed nr.loggerd nr.smid
|
Note Whereas the services file identifies all of the daemon services a given Sensor or Director system is capable of running, the daemons file identifies the services to launch upon startup. |
This file associates signature IDs with signature names for Cisco Secure IDS applications, and is used primarily by Director systems. The format of each entry in the file is:
<signature_id> "<signature_name>"
where <signature_id> is a numeric ID uniquely identifying the signature and <signature_name> is the name of the signature.
For example, the following sample entry defines a few attack signatures:
1000 "Bad Option List" 1001 "Record Packet Rte" 1002 "Timestamp" 1003 "Provide s,c,h,tcc" 1004 "Loose Src Rte" 1005 "SATNET ID"
 |
Caution The /usr/nr/etc/signatures file should not be modified manually. |
This section discusses the following topics:
There is a one-to-one correspondence between daemons and their configuration files. Whereas the naming convention for a daemon is nr.<daemon>, the convention for its configuration file is <daemon>.conf. Each of these files contains token-based configuration information of the form:
<token> <value>
This file contains tokens that control Cisco Secure IDS's event processing infrastructure. The tokens that require special attention follow.
The EventAlarmInterval token specifies how much time, in seconds, that Cisco Secure IDS waits before sending a second notification on alarm activity that meets the event script's conditions.
|
Note The EventAlarmInterval token corresponds to the Consolidation Interval in nrConfigure. |
The EventAlarmThreshold token specifies how many alarms should occur before the event processing infrastructure sends a notification. The value for this token can be a comma-delimited list. For example, an entry of "1,5,100" would execute an action the first, fifth, and hundredth time an event occurred during the specified interval.
The EventApplication token specifies the name of the event script. This token is set to the event script in the /usr/nr/bin/eventd directory. Regardless of whether you build custom notification scripts, your script must be able to understand the data fields passed on to it by the event script.
The loggerd.conf file is used by Cisco Secure IDS to configure the daemon that writes log files.
The MinContextLevel token specifies the minimum alarm level for logging optional context data. For example, context data associated with level 1-3 alarms will not be written to a Director's event log file when this token is set to "4."
|
Note The MinContextLevel token does not affect access to context information from the Director console. Users can still view context information for alarms that fall below the MinContextLevel threshold. |
The NumberOfSwitchBytes token specifies a size threshold for log files. In other words, it specifies how large a log file can get, in bytes, before loggerd pushes the log file to /usr/nr/var/tmp and starts writing to a new log file in /usr/nr/var/new.
The NumberOfSwitchMinutes token specifies a time threshold for log files. In other words, it specifies the maximum amount of time that loggerd should write to a log file in /usr/nr/var/new before pushing the logfile to /usr/nr/var/tmp and starting a new log file.
The loggerd daemon ensures that log files are kept open for at least one minute, even if this means that the file's size crosses the size threshold set with the NumberOfSwitchBytes token.
The managed.conf file is used by the Cisco Secure IDS Sensor to configure the management daemon that controls actions on the router.
The EnableAclLogging token is used to identify whether logging of policy violations is occurring on the managed router. It is either set to 0 ("off") or 1 ("on").
The MaxShunEntries token specifies a maximum number of hosts to shun. This ceiling keeps the Sensor from writing a runaway ACL to the router's shunning interface.
The NetDevice token identifies the IP address, password, and enable password of a Cisco router to which the Sensor is connected. A separate NetDevice entry is required for every Cisco router being managed by the Sensor.
The NetDevice token has the following format:
NetDevice <router_ip_address> CiscoDefault <password> <enable_password>
where <router_ip_address> identifies the IP address of the Cisco router, <password> is the router's password, and <enable_password> is the router's enable password.
The NeverShunAddress token identifies a host or network device you never want the Sensor or its managed router to shun. At the very minimum you make sure that this file contains NeverShunAddress entries for the local system and the remote Sensor or Director system. Other addresses can be added based on your operational needs.
Example entries of the NeverShunAddress token might look as follows, where <255.255.255.255> identifies the subnet mask for the IP address you do not want shunned.
NeverShunAddress ROUTER_IP_ADDRESS 255.255.255.255 NeverShunAddress Sensor_IP_ADDRESS 255.255.255.255 NeverShunAddress INTERNAL_NETWORK 255.255.255.255
The ShunAclCisco token is used to identify the number of the ACL applied to the shunning interface on the router. This token is normally set to 199.
The ShunInterfaceCisco token identifies which interface on the router is being used to shun. The Sensor writes an ACL (whose number is set with the ShunAclCisco token) to the interface indicated.
The ShunInterfaceCisco token has the following format:
ShunInterfaceCisco <router_ip_address> <interface> <direction>
where <router_ip_address> is the IP address of the interface the Sensor uses to communicate with the router (not necessarily the shunning interface!), <interface> is the name of the router interface doing the shunning (for example: Ethernet0, Serial1), and <direction> is either in or out.
The packetd.conf file serves as the heart of the Sensor system and is the largest of all of the configuration files.
The ExtendedOptionsSigofGeneral token manipulates the thresholds, expire times, and other parameters of certain user-configurable signatures.
The ExtendedOptionsSigofGeneral token has the following format:
ExtendedOptionsSigofGeneral <sig_id><opt 1>[<opt n>]...
The MinutesOfAutoLog and MinutesOfAutoShun tokens establish the amount of time that Cisco Secure IDS will shun or log after a particular alarm is received.
The MinutesOfAutoLog and MinutesOfAutoShun tokens have the following formats:
MinutesOfAutoLog <log_minutes> MinutesOfAutoShun <shun_minutes>
The NameOfPacketDevice token specifies the name of the interface used to capture packets from the monitored subnet.
The NameOfPacketDevice token has the following format:
/dev/<device_name>
The following are legal device names:
The PortMapping token specifies whether these signatures—TCP HIJACK Ports, TCP SYNFLOOD Ports, TCP Telnet Ports, TCP HTTP Ports—are to be configured only on specific ports.
The PortMapping token has the following format:
PortMapping <category><port1>....[<port n>]
where <category> is hijack, synflood, http, or telnet.
The ReassembleFragments token turns IP fragmentation and reassembly on and off.
The ReassembleFragments token has the following format:
ReassembleFragments 0/1
where 0 is off and 1 is on. The default is off.
The ReassembleFragmentTimeout token specifies a timeout for partial fragmented datagrams.
The ReassembleFragmentTimeout token has the following format:
ReassembleFragmentTimeout <value>
where <value> is 1-65536. The default is 10
The ReassembleMaxDgrams token specifies the maximum number of tokens that are in the process of reassembly at one time.
The ReassembleMaxDgrams token has the following format:
ReassembleMaxDgrams <value>
where <value> is 0-6553. The default is 500.
The ReassembleMaxFragmentsPerDgram token specifies the maximum number of fragments that a datagram can have for the purpose of reassembly.
The ReassembleMaxFragmentsPerDgram token has the following format:
ReassembleMaxFragmentsPerDgram <value>
where <value> is 1-65536. The default is 190.
The RecordOfExcludedAddress token identifies alarms that can be locked out for events at specific source addresses.
The RecordOfExcludedAddress token has the following format:
RecordOfExcludedAddress <sig_id> <subsig_id> <ip_address>
where <sig_id> corresponds to the primary signature established in the Event Specification section that establishes all of the primary IDs; <subsig_id> corresponds to those signatures established in the latter sections, such as those for filtering and string matching; and <ip_address> is the IP address of the source of the alarms.
The RecordOfExcludedNetAddress token can be used to exclude alarms from an entire network.
The RecordOfExcludedNetAddress token has the following format:
RecordOfExcludedNetAddress <sig_id> <subsig_id> <ip_address> <netmask> <direction>
The RecordofExcludedPattern token allows you to exclude signatures, subsignatures, source IP addresses, and destination IP addresses.
The RecordofExcludedPattern token has the following format:
RecordofExcludedPattern<sig_id> <subsig_id> <source_ip_address>
<destination_ip_address>
The RecordOfInternalAddress token establishes which network Cisco Secure IDS is protecting. It is important to include all internal addresses, because this information is also used for intrusion detection. You should have one entry for each network address.
The RecordOfInternalAddress token has the following format:
RecordOfInternalAddress <internal_network_address> <internal_network_netmask>
The RecordOfLogAddress token establishes a binary log of a particular host or network. This is most commonly used to support an investigation and creates a binary record of all data originating from a particular source address. Initially, this line will probably be commented out.
The RecordOfLogAddress token has the following format:
RecordOfLogAddress <logged_network_address> 255.255.255.0
This RecordOfStringName token defines the strings to look for within a given TCP/IP service.
The RecordOfStringName token has the following format:
RecordOfStringName <string_id> <port> <direction> <num_occurrences> "<matched_string>"
where <string_id> establishes the unique ID for that particular string; <port> tells Cisco Secure IDS which port to watch to look for this string; <direction> tells the Sensor which direction to look for this string (see Table 4); <num_occurrences> indicates how many times the Sensor must see this string before it sends alarms; <matched_string> is the actual string to be matched.
|
Note The exact format of the matched string is controlled by regular expression (regex) syntax. |
| Direction Code | Direction of Attack |
|---|---|
1 | external-to-internal |
2 | internal-to-external |
3 | both directions |
The SigOfGeneral token identifies an action and alarm levels for various types of events. packetd.conf contains a number of different SigOf tokens.
The SigOfGeneral token has the following basic format:
SigOfGeneral <sig_id><action><dest1><dest2><dest3><dest4> # Description of event
where <sig_id> is a numeric identifier that establishes a logical link to internal signature IDs in the packetd daemon; <action> is an action to take (see Table 5); <dest[1-4]> list each of four destinations for alarm activity (these entries should match the entries in /usr/nr/etc/destinations).
| Action Code | Action |
|---|---|
0 | no action |
1 | shun |
2 | log |
3 | shun and log |
4 | TCP reset |
5 | shun and TCP reset |
6 | TCP reset and log |
7 | shun, log, and TCP reset |
For example, the following SigOfGeneral token defines what to do when a TCP Port Sweep is encountered. It first states that no automatic action should be taken (ACT=0). It also defines that level 5 alarms should be sent to its first three destinations, and a level 4 alarm to the last destination:
SigOfGeneral 3001 0 5 5 5 4 # TCP port sweep
The SigOfStringMatch token uses the same format as SigOfGeneral described previously, and is linked to a RecordOfStringName by its <string_id>;
The SigOfStringMatch token has the following format:
SigOfStringMatch <string_id><act><dest1><dest2><dest3><dest4> # Description of event
For example, the following RecordOfStringName token detects any time a user tries to grab the /etc/shadow file using rlogin on port 513:
RecordOfStringName 51302 513 3 1 "[/]etc[/]shadow"
The corresponding SigOfStringMatch determines the response when this signature is triggered:
SigOfStringMatch 51302 6 4 4 4 4
The response is to send out a TCP reset and log the event (action 6), and send level 4 alarms to each of the four destinations in the /usr/nr/etc/destinations file.
The SigOfTcpPacket and SigOfUdpPacket tokens establish the alarm levels for any packet, successful or not, with a TCP or UDP destination port corresponding to the entry. The action fields and the event level specification are the same as in previous sections.
Each SigOfTcpPacket and SigOfUdpPacket token has the following format:
SigOfTcpPacket <port><action><dest1><dest2><dest3><dest4>
where <port> is the TCP or UDP destination port; <action> specifies an action to take (see Table 4); and <dest[1-4]> specifies the destinations listed in /usr/nr/etc/destinations.
The following entry illustrates that all Telnet attempts (Port 23) should have no action taken but should send level 2 alarms to each of four destinations:
SigOfTcpPacket 23 0 2 2 2 2
The next entry indicates level 3 alarms for all TFTP (port 69) attempts that log the packets:
SigOfUdpPacket 69 1 3 3 3 3
|
Note The SigOfGeneral 3000 and 4000 signatures provide default actions and alarms sent to destinations. The SigOfTcpPacket and SigOfUdpPacket entries override these defaults for traffic on specific ports. |
The TCPEmbryonicTimeout token sets the amount of time in seconds that the Sensor waits for the three-way handshake to finish once it has started.
The TCPEmbryonicTimeout token has the following format:
TCPEmbryonicTimeout <value>
where <value> is 1-65536. The default is 15.
The TCPOpenEstablishedTimeout token sets the amount of time the Sensor waits for the next packet before resetting the session state and recycling the state information.
The TCPOpenEstablishedTimeout token has the following format:
TCPOpenEstablishedTimeout <value>
where <value> is 1-65536. The default is 90.
The TCPStrictReassembly token tells the Sensor to watch for traffic when the receiver has sent an ACK for the TCP connection.
The TCPStrictReassembly token has the following format:
TCPStrictReassembly <value>
where <value> is 0 (no TCP reassembly), 1 (loose reassembly), or 3 (strict reassembly).
The TCPThreeWayHandshake token tells the Sensor to watch for three-way handshake-related traffic.
The TCPThreeWayHandshake token has the following format:
TCPThreeWayHandshake <value>
where <value> is 0 (off) and 1 (on). The default is off.
The postofficed.conf file contains tokens that control postofficed's heartbeat interval and associated tokens, which together make postofficed an effective purveyor of status about Cisco Secure IDS processes as well as a conduit for messages.
The WatchDogInterval token specifies how many seconds postofficed waits between polling each process with a status query.
The WatchDogNumProcessRestarts token specifies how many times postofficed attempts to restart a dead process.
The WatchDogProcTimeOutAlarmLevel token specifies the level of alarm to send to the Director when a process fails to answer a status query.
The WatchDogProcDeadAlarmLevel token specifies the level of alarm to send to the Director when a postofficed detects a dead process.
The WatchDogResponseTimeOut token specifies how many seconds postofficed waits for a response to a status query before determining that the process is not alive.
The sapd.conf file contains tokens used for setting up database batch processes, database user IDs and passwords, and other similar bits of information.
The ControlPost token specifies the executable file used to control moving of log files from /usr/nr/var/tmp to /usr/nr/var/dump after they are staged to the database. The default is /usr/nr/bin/sap/load_post.sh.
The ControlPre token specifies the executable file used to control moving of log files from /usr/nr/var/new to /usr/nr/var/tmp. The default is /usr/nr/bin/sap/load_pre.sh.
The ControlRun token specifies the executable file used to control the staging of log files in /usr/nr/var/tmp into the database. The default is /usr/nr/bin/sap/load_run.sh.
The ControlUndo token specifies the executable file used to move files from /usr/nr/var/tmp back to /usr/nr/var/new if the database staging failed for any reason. The default is /usr/nr/bin/sap/load_undo.sh.
The DBAux1 token specifies additional data needed by Remedy ARS.
The DBAux2 token specifies additional data needed by Remedy ARS.
The DBAux3 token specifies additional data needed by Remedy ARS.
The DBPass token specifies the password used to access the Oracle database.
The DBPass2 token specifies the Remedy ARS password.
The DBUser token specifies the username used to access the Oracle database.
The DBUser2 token specifies the Remedy ARS username.
The DisplayMode token specifies how much information is displayed on the console. It can be set to Brief or Full:
DisplayMode Brief DisplayMode Full
The FM_Action token is used to create the action component of a trigger. Triggers consist of a condition and an action. If a condition is true, then the action is carried out. Another way of looking at it is that a condition specifies when to launch an action, whereas the action is what to carry out.
The five conditions that trigger an FM_Action are as follows:
The FM_Action token has the following format:
FM_Action <label> <exec> <args>
where <label> is a unique identifier for the action; <exec> is the name of the script to execute; and <args> is one or more arguments passed to the <exec> script.
For example, the following action, labeled DBLoad1, passes the name of the oldest file in the queried directory to the DBLoad script (see Table 6 for a complete list of mappings between macro names and what they mean to sapd):
FM_Action DBLoad1 DBLoad $FileOldest
The condition that triggers this action might look like the following:
FM_DirFiles Oracle_Load 1 /usr/nr/var/new DBLoad1
| Macro | Meaning | Type |
|---|---|---|
$DirFiles | count of all files in queried directory | Filesystem |
$DirSize | size in bytes of all files in queried directory | Filesystem |
$DirUsed | disk percentage used where queried directory resides | Filesystem |
$DirPath | directory location | Filesystem |
$FileOldest | name of oldest file in queried directory | Filesystem |
$FileNewest | name of newest file in queried directory | Filesystem |
$Notify1 | value of NotifyPerson token | Token Value |
$Notify2 | value of NotifyPerson2 token | Token Value |
$DBUser | value of DBUser token | Token Value |
$DBPass | value of DBPass token | Token Value |
$TimeStamp | standard date/time stamp | Date/Time |
$CurrTime | current time string | Date/Time |
$Today+1 | tomorrow's date | Date/Time |
$Today | today's date | Date/Time |
$Today-1 | yesterday's date | Date/Time |
$Today-2 | day-before-yesterday's date | Date/Time |
$Today-3 | day-before-the-day-before-yesterday's date | Date/Time |
$Week | day-a-week-ago date | Date/Time |
$Week-1 | day-two-weeks-ago date | Date/Time |
$Month | day-starting-current-month date | Date/Time |
$Month-1 | day-starting-previous-month date | Date/Time |
The FM_CronTime token specifies an action to take at a specific time of day. It is the condition part of a trigger, and must have an FM_Action associated with it.
The FM_CronTime token has the following condition format:
FM_CronTime Report_Day 0500 Daily Batch_Day
This specifies that the daily report should be run at 5 a.m. (0500 hours).
The corresponding action token might look like the following:
FM_Action Batch_Day /usr/nr/bin/sap/ctl_batch_report.sh DAY $Today-1 $TimeStamp
The FM_DirFiles token specifies the maximum number of files that a holding directory can hold before an action is triggered. It is the condition part of a trigger, and must have an FM_Action associated with it.
The FM_DirFiles token has the following condition format:
FM_DirFiles Oracle_Load 1 /usr/nr/var/new DBLoad1
This specifies that the DBLoad1 action should be triggered when the number of files in /usr/nr/var/new reaches 1.
The corresponding action token might look like the following:
FM_Action DBLoad1 DBLoad $FileOldest
The FM_DirSize token specifies the maximum size a directory can grow to before an action is triggered. It is the condition part of a trigger, and must have an FM_Action associated with it.
The FM_DirSize token has the following condition format:
FM_DirSize TRAP_New 50000 /usr/nr/var/new Trap_New
This specifies that the Trap_New action should be triggered when the files in /usr/nr/var/new total 50,000 bytes.
The corresponding action token might look like the following:
FM_Action Trap_New /usr/nr/bin/sap/ctl_dump.sh $DirPath NEWLOG log.*
The FM_DirUsed token specifies a threshold of disk usage, that when met, triggers an event. It is the condition part of a trigger, and must have an FM_Action associated with it.
The FM_DirUsed token has the following condition format:
FM_DirUsed NOTIFY_Urgent 95 /usr/nr/var/dump Notify_Urgent
This specifies that the Notify_Urgent action should be triggered when the /usr/nr/var/dump directory reaches 95 percent capacity.
The corresponding action token might look like the following:
FM_Action Notify_Urgent /usr/nr/bin/sap/ctl_notify.sh $DirPath $DirUsed $Notify1 URGENT
The FM_IdleTime token specifies an action to take after a specified amount of time passes. It is the condition part of a trigger, and must have an FM_Action associated with it.
The FM_IdleTime token has the following condition format:
FM_IdleTime Purge_Dump /usr/nr/var/dump Purge
The corresponding action token might look like the following:
FM_Action Purge /usr/nr/bin/sap/custom_purge.sh $DirPath
Notice that the directory specified on the FM_IdleTime token (/usr/nr/var/dump) gets passed to the FM_Action token as $DirPath.
The LogFileMask token specifies that part of the log filename that comes before the timestamp. The default is "log."
The LogFileMask token has the following format:
log.<timestamp>.
The LogFilePathDump token specifies the directory where log files are sent for purging. The default is /usr/nr/var/dump.
The LogFilePathIPLog token specifies the directory where new IP log files are written to. The default is /usr/nr/var/iplog.
The LogFilePathNew token specifies the directory where new log files are written to. The default is /usr/nr/var/new.
The LogFilePathTmp token specifies the temporary directory where log files from /usr/nr/var/new are pulled to. The default is /usr/nr/var/tmp.
The LogFilePathVar token specifies the root directory for log file handling. The default is /usr/nr/var.
The NotifyInterval token specifies how often to send a notification while the condition of the event remains true.
The NotifyInterval token has the following format:
NotifyInterval <number_of_minutes>
For example, the following sets the interval to every 20 minutes while the condition is still true.
NotifyInterval 20
The NotifyPerson token specifies which e-mail address should receive notifications from sapd on various events.
The NotifyPerson2 token specifies a second e-mail address that should receive notifications from sapd on various events.
The PollingDelay token specifies how quickly sapd evaluates the triggers. Valid values range from 1 to 9, which, when multiplied by 10, provide a number of seconds from 10 to 90 between cycles. The lower the number, the faster sapd operates.
The smid.conf file is the configuration file for the smid daemon, which passes information to the Director nrdirmap application for display within the HP OpenView user interface.
The DupDestination token defines duplicate destinations for Cisco Secure IDS events. This token allows a Director system to forward event information onto other services and systems. In the following example, events, commands, and errors of level 1 and above are forwarded onto loggerd. This allows the Director to monitor and log events based on a single Sensor data stream. This in turn, helps reduce the amount of network traffic a Sensor must transmit to a Director. Instead of having to transmit two identical (but separate) data streams to director1.cisco, the Sensor is able to send a single stream that is duplicated on the Director platform.
The DupDestination token has the following format:
DupDestination director1.cisco loggerd 1 ERRORS,COMMANDS,EVENTS
As the next example shows, this token can also be used to forward events onto another Director system. In this case, however, only events of level 2 and above are forwarded.
DupDestination director2.cisco smid 2 ERRORS,COMMANDS,EVENTS,IPLOGS
|
Note The host and organization IDs must match entries defined in /usr/nr/etc/hosts. |
This directory contains basic UNIX configuration files (such as .profile) that are required to configure remote login accounts.
This is the directory where sockets are created by the different daemons. The names of these sockets are dictated by the parent daemon. postofficed creates sockets with names such as mailbox.packetd and mailbox.configd. configd creates sockets with names such as socket.command.
This is the default location for all of the log files generated by loggerd and error files for all of the applications listed in the /usr/nr/etc/daemons file.
This section includes the following topics:
Event logs are ASCII files written to the /usr/nr/var directory with the naming convention of log.YYYYMMDDHHMM. By default, level 2-5 events are written to event logs on a Director system, and low-level 1 events are written to an event log on the Sensor system. Log files capture data on alarms, command, and errors.
Event alarm data are unique because the record format contains optional as well as fixed components.
Fixed alarm data include the following information:
The optional data field contains information that cannot be described by the fixed portion of the alarm record format. This information may be a string associated with an event, or context data that consists of a snapshot of incoming and outgoing TCP traffic (a 256-byte maximum in both directions).
For example, a typical line written to a log file would look like the following:
4,1025294,1998/04/16,16:58:36,1998/04/16,11:58:36,10008,11,100,OUT,OUT,1,2001,0,TCP/IP,10. 1.6.1,10.2.3.5,0,0,0.0.0.0,
Each comma-delimited field contains different data. The first field indicates what kind of record was logged. Table 7 maps a log file's initial field with its corresponding record type.
| Field Value | Record Type |
|---|---|
0 | Default |
1 | Command |
2 | Error |
3 | Command Log |
4 | Event |
5 | IP Log |
6 | Redirect |
In the previous example log record, 4 denotes an Event record. Table 8 provides a reference for the rest of the fields in the sample Event record.
| Sample Field Value | Field Type |
|---|---|
4 | Record Type |
1025294 | Record ID |
1998/04/16 | GMT Datestamp |
16:58:36 | GMT Timestamp |
1998/04/16 | Local Datestamp |
11:58:36 | Local Timestamp |
10008 | Application ID |
11 | Host ID |
100 | Organization ID |
OUT | Source Direction |
OUT | Destination Direction |
1 | Alarm Level |
2001 | SigID |
0 | SubSigID |
TCP/IP | Protocol |
10.1.6.1 | Source IP Address |
10.2.3.5 | Destination IP Address |
0 | Source Port |
0 | Destination Port |
0.0.0.0 | Router IP Address |
Two other types of records, error and command log, are similar in structure to the event record. Both of these record types have the same first eight fields contained in Event records (Record Type, Record ID, GMT Date and Timestamp, Local Date and Timestamp, Application ID, Host ID, and Organization ID).
An error record type has a ninth field denoting the actual error string generated by a service. The command log record type also contains fields for the source application ID, host ID, and organization ID, as well as the command string. In both cases, you will have a complete record of errors and commands.
IP session logs capture all incoming and outgoing TCP packets associated with a specific connection, and therefore contain binary data. They are written to a Sensor's /usr/nr/var/iplog directory with the naming convention of iplog.source_IP_address.
In addition to detecting attack signatures, sensord and packetd are able to monitor the traffic associated with a specific type of attack. For example, sensord can be configured to monitor all of the packets associated with an IP spoof. sensord or packetd creates a separate log file in /usr/nr/var/iplog for each of these monitoring sessions. The name of each session log file is based on the IP address of the attacking host (for example, iplog.10.145.16.152).
There is a performance penalty associated with the logging of context data. DMP provides two options for controlling overhead:
Context data is not loaded if this variable is set.
By default, level 1 event and IP session logs are left on a Sensor until they are required. This prevents the relatively large amounts of data associated with these types of events from impeding Cisco Secure IDS communications during periods of network load.
Even though the DMP is designed to transfer Cisco Secure IDS data into industrial strength databases, both types of data are initially written to flat files for two reasons: speed and fault tolerance. Data can be written to a flat file much faster than to a database, and access to flat files is guaranteed as long as the host system is operational. Databases, on the other hand, are subject to unpredictable load, and contain too many access layers to be truly fault tolerant—if the database is down, there are no places to turn.
Use this document in conjunction with the following Cisco Secure IDS documents:
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Cisco documentation is available in the following ways:
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Attn Document Resource Connection
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
P3 and P4 level problems are defined as follows:
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
http://www.cisco.com/register/
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
http://www.cisco.com/tac/caseopen
If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
P1 and P2 level problems are defined as follows:
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, PIX, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Voice LAN, Wavelength Router, WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, Network Registrar, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries.
All other brands, names, or trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0011R)
Copyright © 2001, Cisco Systems, Inc.
All rights reserved.
Posted: Mon May 13 08:04:05 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.