Detecting whether the root user ran /home/Joe/ls instead of /bin/ls is difficult to do from the accounting files. Information about any resources accessed by the user’s program are sketchy.

Axent’s Intruder Alert also watches syslog and other system logs for intrusive behaviors. ITA depends on a rule-based approach to look for problems on the system. The rule base is extensible for third-party applications. One useful benefit of this capability is that vendors who write messages to syslog can build rules for plugging into ITA. Because ITA also includes a distributed, heterogeneous, client-server event reporting framework, other vendors can develop rules that indicate intrusive behavior and watch the events get reported to the ITA console.

Unfortunately, syslog does not include all of the information necessary to detect a number of intrusive and misused behaviors. The OS audit logs are needed for a more detailed analysis. Which is better—syslog or audit logs? There is no simple answer.

If you are content to know about failed su events, failed logins, bad password changes, and other events reported by syslog, then this is a sufficient source of instrumentation. The question you must consider is whether other events, such as those described in the following sections, which you want to detect. Also, you must decide whether you can afford the price of auditing. When you turn on the auditing subsystem, performance implications will occur. On the other hand, if your site security policy requires auditing already, adding an IDS that processes this data further is probably acceptable.

Audit Trails

The OS audit trails contain a significant amount of data about system activities. Each OS reports on a different number of events, but almost any OS system activity is reported. For example, Solaris reports more than 240 audit events, AIX almost 100, and HP-UX around 125. Microsoft NT emits about 100 different events as well.

Unlike syslog and the accounting logs, audit records include important, security-relevant data values in each record. Figure 6.2 shows the audit header fields for AIX. Note that today AIX does not report the EUID or EGID of a process, which makes detection of buffer overflow attacks difficult.

Figure 6.2  Audit record header fields for AIX.

Among other values, the audit records contain the following:

•  Details about the object being accessed, such as the parameters passed to the program

•  Fully qualified path names of executables

When a user completes the login process, the kernel assigns as audit ID (AUID), which is the prefix for each audit record written for that user. Even if the user runs a SUID root program, the AUID remains the same. This means that a user cannot hide an activity by pretending to be someone else, whether root or another user. The AUID is what proves accountability for activities and identifies the user responsible for the event.

How reliable is the AUID? The answer depends on your environment. If most of your users log in using the normal mechanism, run various programs, execute commands, and then log out, the AUID will be a reliable indicator for accountability. However, in a couple of cases the AUID is not particularly helpful.

A number of daemon programs started automatically by the system will run with AUID=0. Any audit records cut for those programs will show that root initiated the activity, even though it did not happen from a login shell. If these programs are listening for interprocess communication from other programs run by normal users, assigning accountability gets a little more complicated. When your program sends a message to one of these daemons and asks it to perform an activity on your behalf, it is the root AUID that will appear as the prefix for the daemon’s audit records, not your UID.

A more complicated problem exists for Web servers and systems without login sessions. Systems of this type are usually running server programs that are listening for network connections from other nodes. The only AUID in the audit records might be the that of the root user. Even if you have created a special user ID under which you run your Web server, the AUID probably will be zero (root’s UID) because of the way in which the Web server is started by the system. If the server is started by an rc script or via the init program, the root AUID will be the prefix for the audit records.

The AUID can be changed by a privileged process, which is good because it provides a facility for programs to set the appropriate AUID value. However, this feature also means that an intruder who gains root access will be able to change the AUID. While this may seem nasty at first glance, this event itself will be logged with an audit record.

Can an attacker stop the audit subsystem from running? Yes. This process, too, will generate an audit record before the subsystem shuts down. The attacker then would either need to delete the entire audit log or try to modify it. Changing the audit log by editing portions of it is nontrivial, and there have been no public reports of this occurring successfully. Still, it is possible if the attacker understands the auditing subsystem.

If you look at security tool Web sites such as COAST, you will find a program called zap. It was written to hide intruder tracks and is likely to be the first program installed when your system is compromised. Specifically, it doctors the utmp, wtmp, and lastlog files so that they do not show evidence of the intruder’s logins. A second set of tools available as rootkit contains hacked versions of ps and other status tools that are designed to hide activities, too. So far, none of these treasure chests include tools for tricking the auditing subsystem. Chances are it’s just a matter of time.

Tracing the Path of Activity Can Be Difficult

An IDS traces the path of activity so that an operation can be traced back to a specific user. In other words, the IDS will look at more than one event to make a policy decision. This process is much different from an OS that relies on the credentials of the running process at the instant an access control decision is made. Consider the policy violation that occurs when a user is able to read a file for which that user is not granted explicit read access (see “Monitoring Policies”).