| Previous | Table of Contents | Next |
The patented component of Stalker that is most interesting is the collection of intrusion detection patterns along with the engine that analyzes them. In simplistic terms, audit records are dropped into the engine, which maintains a series of state transition diagrams representing intrusions and misuses. When a particular pattern reaches a terminal state, a misuse or intrusion event is indicated.
This analysis component of Stalker is called the Misuse Detector (MD) for historical reasons. Technically, it is both a misuse detector and an intrusion detector. Recall from earlier discussions that misuse detection looks for abuses by internal users, and intrusion detection is focused on attacks from outsiders. Today, these terms are often used interchangeably.
Like the TB, the MD can be run interactively or scheduled to operate in batch mode. Stalker detects roughly 80—90 different attacks depending on the version of UNIX running on the client. Not all patterns are supported on each OS. From the MD GUI, you can choose which attack signatures you want to monitor.
Stalker conveniently groups patterns into classes, such as Trojan Horse. Space does not permit an exhaustive list and description of attacks detected by Stalker. Table 8.1 summarizes this information.
| Attack Signature Category | Types of Attacks Detected |
|---|---|
| Covering Tracks | Detects when a user tries to modify audit configurations, delete entries in system log files, or run known rogue programs like zap to cover tracks. |
| Gaining Privilege | Detects a number of different ways that user gains privilege on the system. |
| These signatures can be configured to permit or deny specific privilege transitions, such as when the RUID changes to zero. | |
| Known Attack Programs | Looks for instances of a user running one or more known rogue programs. |
| A preconfigured list is provided but can be modified. | |
| Misuse Outcomes | Looks for evidence of attacks that have a known outcome, such as password guessing attempts matching the order of names in /etc/passwd (indicating the user file has been stolen). Another example is reading someone else’s data or bypassing ACLs by gaining privilege. |
| Self Defense | Watches the Stalker directories for evidence of tampering. |
| System Access | Detects when critical systems files have been altered, or attempted to be altered. This category includes Trojan Horse signatures. |
| Vulnerabilities | Looks for evidence of someone trying to exploit a known security advisory. |
| Masquerading | A user switches to another user and then attacks the system. |
| Tagged Events | Tagged files or programs that a user accesses (planted by the administrator as bait) or a tagged user account being accessed. |
The MD was developed over several years and has a good foundation in intrusion detection research. IDSs use different engines for analyzing attacks. Some, such as CMDS, rely on rule-based expert systems. Stalker employs a finite state machine (FSM) for recognizing attacks. As you probably know, finite state machines are the underlying technology for compilers. Recognizing patterns with the utmost speed is one of the reasons FSMs are used in compilers. This reason was also one of the reasons it was chosen for Stalker.
You also can buy a Misuse Detector Toolkit to add signatures to Stalker. This toolkit is not particularly easy to use and requires skill in C++. Over time you can expect Stalker and other IDSs to provide a scripting language for writing new patterns.
At the time this chapter was written, the real-time, client-server, heterogeneous Stalker product was not available. Naturally, you should check the Network Associates Web site for the latest information. Many enhancements to Stalker have been planned and will roll out over time. You want to remember that batch reports are an important part of security monitoring. Monitoring everything in real time is probably not the best approach. Also, Stalker’s capability to go query and search through past audit logs is valuable. If you find that you have been hacked, it’s good to know that you easily can filter for specifics through large amounts of historical audit data using Stalker.
Stalker will be a good match for your environment if you consider the following:
Stalker has a large set of attack patterns for UNIX system-level monitoring. If the set of attack patterns is useful to you, which it probably is, deploying Stalker on critical systems is a good way to get started.
Unlike accounting files, the audit trail can detect privilege transitions. The Morris worm, which overlaid itself with a fork() and then an exec(), would not have been detected in the accounting files, although it does show up in audit logs. When a user runs a similar attack, the AUID remains unchanged, and thus accountability is preserved. The AUID also persists when a user runs the su command, even though the RUID changes. Other transitions in privilege also are surfaced in the audit log. With Stalker’s TB and MD capabilities, you can catch these type of security events on your systems.
Depending on your needs, Stalker may not be the best tool for your environment. For example, if you want real-time consolidation of audit logs from the clients to the Stalker server, the tool does not provide this feature today. Your requirements might cause you to see the following as limitations of Stalker:
Given the number of valuable reports that Stalker can generate for you, these problems are not particularly difficult.
| Previous | Table of Contents | Next |