Previous | Table of Contents | Next |
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.
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:
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.
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.
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:
The priorities for syslog in decreasing order of severity are as follows:
Facilities provide a convenient way of indicating that the message came from a particular component of the OS. Common facility definitions include the following:
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:
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. Its 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:
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:
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:
Previous | Table of Contents | Next |