Exceptions for Recommended Patterns

When you configure your monitoring policy, one problem will be alerts generated with an RUID=0 from the root user. If the root user logs into a system and deletes files, the RUID is 0 in the audit records. When a program is a server process that listens for input from other programs and is started automatically by the system at boot time, the RUID also will be 0. If, by sending this server program a message, the hacker can trick it into writing to another user’s files, the audit event will seem to have originated from the root user. The only way to detect this type of attack is by tracing the path of activities through interprocess communication. Today, no commercial IDSs drill down this far into the audit stream, tracking socket or message queue transfers between processes to assign accountability.

If you want to avoid receiving notifications when the root user deletes or writes to files owned by other users, you could miss some types of attacks. On the other hand, watching every action of the root user can generate quite a bit of data that is not indicative of attacks. Unfortunately, the tradeoff is yours to make.

Pure and Simple Bugs

Often the hacker is lucky enough to have a crack handed to them. Buffer overflow attacks require some dedicated work to create, although after the details for a particular SUID program are known, a reusable hack spreads rapidly on the net. Once in a while an exploit is so simple that it is amazing that the problem could have been missed in code reviews. One such example is the rlogin -froot problem in AIX. Although rlogin is a remote-connection program, a local user can run the command. By typing the following a user could gain root access to the system:

rlogin remotehostname -froot

No special programming skills were needed. The user would be delivered into a root shell with complete control over the system.

Detecting this attack on a local system is easy. When a program is run out of a shell, a fork event is followed by an exec event in the audit log. The parameters used in the program are part of the audit record. Scanning specifically for the pattern “rlogin * -froot” where * matches any characters would detect the hack. What you would have discovered is a local user trying to launch this attack from the current system, possibly directed right back to the same system.

If your system is the target of such an attack from a remote user on another system, knowing what to look for in the audit logs is important for detecting this attack. Because the audit records emitted are different for the server that catches the rlogin request, you cannot use the same pattern as you would to catch the attack when it is launched from your system.

Why You’re Not Finished Yet

You have now taken a close look at Stalker and CMDS—two well-known system level UNIX IDSs. Both tools provide audit reduction but differ in primary focus. CMDS provides some attack pattern analysis, but its strength lies in the statistical anomaly detection techniques for which it is well known. Stalker also provides some statistical threshold notifications but boasts a wide range of attack patterns for catching intruders.

You also have seen how local users can hack a system for denial-of-service attacks and how to look for these attacks in the audit logs. An IDS will be able to detect these attacks if they are launched from your system because audit records contain detailed information about programs and their parameters. The audit system also assigns accountability in most cases when local users are the initiators of activities.

By far the greatest risk is not from denial-of-service attacks but from successful attempts by users to gain privileges. Sometimes privilege escalation can occur by tricking a user into running a command on your behalf. Other times, you can gain privilege by guessing someone’s password. The most frequently occurring hack announced on the Internet today is the buffer overflow attack against privileged programs. With a little digging, a cracker can gain access to a superuser shell via one of these attacks. Luckily, the most common cases surface in the audit logs with predictable patterns. Unfortunately, a general-purpose buffer overflow pattern is very difficult to build.

Although the audit logs provide a large amount of information about what’s happening on the system, they do not record all of the network activities for a system. Many of the network attacks on systems are thus not seen by system-level monitoring tools like Stalker and CMDS. Therefore, to complete your IDS solution, you need to deploy network tools as well. Turn to the next chapter to see how network sniffers catch problems that system IDSs and scanners miss.