Also, no reason exists to prevent the routines that make up products such as RealSecure and NetRanger to be embedded in the firewall logic. Sure, all of these products drag along their own systems management frameworks for configuration and event reporting. The core IDS logic could be easily combined with a firewall to add network IDS capabilities. Whether this is practical is another question altogether. Would you rather pay the performance penalty of adding IDS code to the firewall packet filters, or would you rather put an IDS sniffer inside the secure network immediately after the firewall? Different sites would prefer one approach over the other.

Relying on Others for Data

If your IDS philosophy is to rely on data sources provided by others, you do not pay performance penalties for intercept or replacing calls. Depending on another software component for data has its drawbacks, though:

•  The data is emitted by the component after the event has occurred.

•  The amount of data provided may not be sufficient for the IDS model. You might not get the UID of the offending process, for example.

•  The events you are interested might not be reported by the system.

•  At some point, the net value of generating data decreases as the amount of resources a system consumes emitting the data increases. In other words, if the system is spending most of its time reporting events instead of running the payroll, you should question the value of your approach.

•  The component emitting the data can change the format of log records. This change happens often enough so that IDS vendors are required to modify their software to keep up with OS or application changes.

•  The data may not be regularly reported for that system.

This last point is particularly important. System, application, and network logging can be an expensive operation. If a customer already is accustomed to storing large log files, rolling an IDS into the environment is not going to add additional requirements. If a customer does not regularly run the auditing subsystem, some convincing is necessary if the IDS relies on the audit trails. OS auditing can generate a fairly large number of records, although all of these records do not need to be stored if the IDS runs in real time, or if the environment does not require post investigative analysis of system audit logs.

System Data Sources

For monitoring systems, the two main sources of information about OS activity are syslog and the audit trail. In NT, the audit trail is called the event log. Audit log and audit trail are used interchangeably.

syslog

UNIX provides a common service for logging events called syslog. The syslogd daemon supports logging across systems, relying on IP address authentication for accepting remote log entries. By far, the more common approach is for processes to create syslog record entries and call the OS interfaces to log the event to the local syslogd daemon. The syslog configuration file controls whether events are reported to the console, a file, or both. Events from syslog also can be piped to other processes.

No commonly agreed upon standards exist for the format of messages logged to syslog. The record format consists of some header fields including the following:

•  name of the logging program

•  priority

•  facility generating the message

•  text of the message itself

The priorities for syslog in decreasing order of severity are as follows:

•  emer(gency)

•  alert

•  crit(ical)

•  err(or)

•  warning

•  notice

•  info

•  debug

Facilities provide a convenient way of indicating that the message came from a particular component of the OS. Common facility definitions include the following:

•  kern(el)

•  user (user processes)

•  mail

•  lpr (line printer)

•  auth(orization subsystem)

•  daemon (a system daemon)

•  news

•  uucp

•  local0..n

The syslog configuration file contains entries of the following form with wildcards supported in each of the two fields of the first parameter:

facility.priority     [TAB]     action

One or more tab characters must separate the first parameter from the action. Possible actions are as follow:

•  A destination log filename

•  A user name, list of names to which the message is mailed (^* means to all logged in users)

•  The form @hostname that identifies the remote syslogd to which the message should be sent

•  The pipe character “|” followed by a program name

The syslog daemon listens on UDP port 514 by default and accepts unauthenticated datagrams from any system. Therefore, the syslog daemon is not to be run across an untrusted network. Also, syslogd will accept messages from any program. It’s possible for a user program to emit any message onto the console.

Quite a bit of useful information about system behavior is available from syslog. Important information that an IDS looks for includes the following:

•  Failed and successful login events

•  Failed and successful su events

•  Password changes

•  System reboots

For many people, the amount of information provided by syslog is sufficient for watching their systems. However, activities are logged into other files. The UNIX OS also emits other useful logs including the following:

•  sulog that shows the use of the su command

•  utmp recording each current login session

•  wtmp in which login, logout, shutdown, and restart events are written

•  lastlog in which the most recent successful and unsuccessful login events are recorded for each user

•  A log file, dependent on the OS, in which bad login attempts are kept (/etc/security/failedlogin for AIX)

•  Accounting files

ITA also looks at accounting files for evidence of intrusions. Accounting files are designed for charge back systems. Therefore, their entries include information such as which command a user ran, how much CPU time the command consumed, whether the user was a privileged user, whether the command ran as the result of a fork() operation, and the time the process executed. Important information you do not get from accounting logs is as follows:

•  The full path name of the program executed

•  The arguments passed to the program