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

log.200301010001

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:

iplog.192.168.1.1.200212312359

From simply reading the file name, you know a host using the IP address 192.168.1.1 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).

cp24 cr