|
|
This document contains the following sections:
The goal of this document is to provide details on various internal functions and processes of NetRanger, including file and directory structure; daemons, their associated configuration files and tokens; system files; and commands.
Under normal NetRanger 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 are advanced NetRanger 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 |
FilenameOfError | all conf files |
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 |
ProfileDetection | packetd.conf |
ProfileEnabled | packetd.conf |
ProfileResponse | 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 |
WatchDogInterval | postofficed.conf |
WatchDogNumProcessRestarts | postofficed.conf |
WatchDogProcDeadAlarmLevel | postofficed.conf |
WatchDogProcTimeOutAlarmLevel | postofficed.conf |
WatchDogResponseTimeOut | postofficed.conf |
One of the quickest ways to gain a detailed understanding of NetRanger is to review the Sensor file structure and underlying elements. A thorough understanding of the Sensor file structure will help you configure and install the Sensor as well as help you better utilize NetRanger's features. It should be noted that 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 NetRanger 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 system. These can be loosely grouped into three basic categories:
NetRanger is a collection of discrete subsystems that have been implemented via daemons, each with its own well-defined set of services.
NetRanger is also a highly configurable distributed application. The daemon services running on a Sensor or Director host 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 system should have postofficed, fileXferd, smid, loggerd, and configd 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 configd daemon reads and writes data to the Sensor configuration files (which are currently restricted to /usr/nr/etc). All communication with this daemon is controlled by the following set of SNMP-like executables:
Refer to the "Configuration Commands" section later in this document for more information on commands.
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 daemon services. 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. As noted in the Overview, data is written to flat files for reasons of performance and fault tolerance. This data can be staged into an RDBMS and managed for archival via sapd.
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. Note that 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 NetRanger product. All communication between daemons is routed through this service. In most NetRanger configurations the Sensor and Director systems reside on separate hosts. Each system relies on postofficed to maintain communication with the other. Note that 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:
The Organization IDs are defined in /usr/nr/etc/organizations; Host IDs are defined in /usr/nr/etc/hosts; Application 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.
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.
Table 3 provides a syntax description for the commands.
| 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> ] |
| 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. |
<token> | The name of the token to set or get information from. |
<value> | The value that the |
For example, you would 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 should return 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 NetRanger 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 NetRanger daemons. It supports the following options:
-d Don't daemonize -h Show help -v Show version number
The command takes the following form:
nrstart [-d] [-h] [-v]
Executing this script stops the NetRanger 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:
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.
This file identifies all of the organizations and their organization ids currently registered for a given NetRanger system. 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
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 NetRanger 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
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 NetRanger 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 NetRanger 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 NetRanger communications system 10001 sensord # Monitors network traffic when used with STK/Nortel 10002 configd # Provides ability to query runtime/configuration info 10003 managed # Manages NetRanger 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
This file identifies which type of configd 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 NetRanger 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
NetRanger is a distributed application that has the ability to route messages from a given post office 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 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 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.
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, configd, loggerd, and smid on a Director system:
nr.postofficed nr.configd nr.loggerd nr.smid
This file associates signature ids with signature names for NetRanger 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>
For example, the error file for nr.managed is identified in managed.conf as follows:
FilenameOfError ../var/errors.managed
This file contains tokens that control NetRanger's event processing infrastructure. The tokens that require special attention follow.
The loggerd.conf file is used by NetRanger to configure the daemon that writes log files.
The managed.conf file is used by the NetRanger Sensor to configure the management daemon that controls actions on the router.
NetDevice <router_ip_address> CiscoDefault <password> <enable_password>
<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.<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
ShunInterfaceCisco <router_ip_address> <interface> <direction>
<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.
MinutesOfAutoLog <log_minutes> MinutesOfAutoShun <shun_minutes>
RecordOfExcludedAddress <sig_id> <subsig_id> <ip_address>
<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.RecordOfExcludedNetAddress <sig_id> <subsig_id> <ip_address> <netmask> <direction>
RecordOfInternalAddress <internal_network_address> <internal_network_netmask>
RecordOfLogAddress <logged_network_address> 255.255.255.0
RecordOfStringName <string_id> <port> <direction> <num_occurrences> "<matched_string>"
<string_id> establishes the unique ID for that particular string; <port> tells NetRanger 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 alarms; <matched_string> is the actual string to be matched. | Direction Code | Direction of Attack |
|---|---|
1 | external-to-internal |
2 | internal-to-external |
3 | both directions |
SigOfGeneral <sig_id> <action> <dest1> <dest2> <dest3> <dest4> # Description of event
<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 |
SigOfGeneral 3001 0 5 5 5 4 # TCP port sweep
<string_id>:SigOfStringMatch <string_id> <act> <dest1> <dest2> <dest3> <dest4> # Description of event
RecordOfStringName 51302 513 3 1 "[/]etc[/]shadow"
SigOfStringMatch 51302 6 4 4 4 4
SigOfTcpPacket <port> <action> <dest1> <dest2> <dest3> <dest4>
<port> is the TCP or UDP destination port; <action> specifies an action to take (see Table 5) ; and <dest[1-4]> specifies the destinations listed in /usr/nr/etc/destinations.SigOfTcpPacket 23 0 2 2 2 2
SigOfUdpPacket 69 1 3 3 3 3
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 NetRanger processes as well as a conduit for messages.
The sapd.conf file contains tokens used for setting up database batch processes, database user IDs and passwords, and other similar bits of information.
DisplayMode Brief DisplayMode Full
FM_Action <label> <exec> <args>
<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.FM_Action DBLoad1 DBLoad $FileOldest
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 |
FM_CronTime Report_Day 0500 Daily Batch_Day
FM_Action Batch_Day /usr/nr/bin/sap/ctl_batch_report.sh DAY $Today-1 $TimeStamp
FM_DirFiles Oracle_Load 1 /usr/nr/var/new DBLoad1
FM_Action DBLoad1 DBLoad $FileOldest
FM_DirSize TRAP_New 50000 /usr/nr/var/new Trap_New
FM_Action Trap_New /usr/nr/bin/sap/ctl_dump.sh $DirPath NEWLOG log.*
FM_DirUsed NOTIFY_Urgent 95 /usr/nr/var/dump Notify_Urgent
FM_Action Notify_Urgent /usr/nr/bin/sap/ctl_notify.sh $DirPath $DirUsed $Notify1 URGENT
FM_IdleTime Purge_Dump /usr/nr/var/dump Purge
FM_Action Purge /usr/nr/bin/sap/custom_purge.sh $DirPath
<timestamp>.NotifyInterval 20
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.
DupDestination director1.cisco loggerd 1 ERRORS,COMMANDS,EVENTS
DupDestination director2.cisco smid 2 ERRORS,COMMANDS,EVENTS,IPLOGS
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 discusses 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 NetRanger communications during periods of network load.
Even though the DMP is designed to transfer NetRanger 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 NetRanger documents:
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Posted: Tue Jul 18 13:15:01 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.