| Previous | Table of Contents | Next |
In Chapter 4, “Traditional Network Security Approaches,” you found a brief over-view of firewalls, cryptographic protocols for network security, and descriptions of problems in TCP/IP. Reasons for adding an IDS even if you have these products were given. The usual suspects—software bugs and configuration errors—applied in this area of traditional security as well.
Network security includes many topics such as I&A beyond single systems, communications between processes on different systems, privacy, integrity, nonrepudiation, and trust. Comments IDS vendors frequently heard about a year ago were, “Hey, why do I need intrusion detection? I have a firewall.” Hopefully, this type of comment is encountered less often today. Most firewall vendors have partnerships or their own programs for intrusion detection, thus highlighting the complementary nature of the product families.
The traditional approach to security has been to shore up defenses with as much prevention as one can muster. Because numerous examples have shown that this strategy by itself is insufficient, you can improve your site security by more closely monitoring events. IDSs monitor security relevant activities by checking for specific attack patterns, individual events, configuration problems, rogue programs, buggy versions of programs, and other holes through which a hacker can sneak. If you do not monitor conformance to your security policies and inspect your configurations, you are taking unnecessary risks. Even though IDSs are not perfect and can miss some attacks, the incremental security offered by these types of products is worth the investment.
IDSs share some common characteristics. Because many are deployed in distributed environments, features such as remote configuration, secure communications, and authentication are included. Systems management capabilities such as centralized event notification, logging, templates, and automated responses to fix a reported problem are commonly seen across IDSs. Beyond these similarities, IDSs can be divided into three main types.
The three main categories of IDS tools are scanners, system-level monitors, and network sniffers. Because each type of tool detects attacks that the others do not, these IDSs are complementary to each other. Unfortunately, no single vendor today offers all three types across multiple OS platforms in a single solution.
Scanners come in two flavors. Remote scanners run on a central node and attempt to probe remote systems from a central console for weaknesses. No component of the remote scanner runs on the probed node. System scanners run on the target node and thus have an advantage of being to operate as a user would. They can read files and access other resources that a remote scanner cannot. Vendors, such as ISS, offer both kinds of scanners in a single suite of products. In a different marketing twist, IBM gives away a limited version of a remote scanner with the purchase of one of its firewalls.
Because they run on an interval basis, scanners cannot detect attacks as they occur. The argument, of course, is that they were not designed to do so in the first place. You need to decide how often to run the scan if this is the only tool you use. However, if you have both a scanner and a real-time system-level IDS, the two fit together nicely. When you receive your system or when you make major changes to its contents, run the scanner to uncover configuration problems. After the system tests clean, your real-time system-level IDS can detect future unwanted changes in real time.
Some problems are encountered with this approach. For example, a real-time system monitor normally will not inspect the contents of a file that was changed. If someone changes the file httpd.conf, the system-level IDS does not scan the contents to see whether the change was unsafe. You will not detect a configuration problem resulting from this change until you run the scanner again. Obviously, the ideal choice is for the system-level IDS is to invoke the scan routine on the file when the change event is detected in the audit log. Many scanners can be invoked from the command line with an optional parameter specifying the items to scan (or a file containing the list). Note how well these two strategies fit together when combined.
Products that monitor the audit logs or syslog detect attacks at the system level. Instead of inspecting network packets or scanning configurations, system-level IDSs sort through the massive amounts of data provided by system logs. Any information not available through these logs determines whether an attack will be missed by a system monitor. Network packet content or low-level attacks, such as SYN Flood, are not seen in the audit logs despite the large number of network events that do appear in the logs. On the other hand, privilege transitions that occur as a result of buffer overflow attacks do uniquely appear in the audit logs.
Challenges for system-level IDSs include the overhead associated with gathering the data, sufficiency of the data, scalability, and the fact that each node must have a sensor. Two types of system-level tools have appeared in the marketplace. Overlap exists in the set of attacks these two types of tools can detect. In some cases, such as looking for N events of some type in sequence, the approach taken by the tools is identical. Nonetheless, a definite theoretical distinction exists in the approaches.
Pattern Matchers
Pattern-matching IDSs work by filtering data through a set of attack signatures. When a signature is recognized in the data, an event is generated. The challenge for these IDS vendors is building general and specific signatures to catch attacks. Some exception case always seems to exist which makes building signatures difficult. Much theoretical work has been done in this area, given that pattern matching is a relatively mature area of computer science and mathematics. Models, such as finite state machines, seem to have the best performance, although concerns have been expressed about the success of their detection rates. Stalker is a well-known system-level IDS in use at a number of sites.
| Previous | Table of Contents | Next |