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:
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
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.
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
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
YYYY The four-digit year the file was
MM The two-digit month the file was
DD The two-digit day the file was
HH The two-digit hour the file was created
MM The two-digit minute the file was
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
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
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
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 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).