| Previous | Table of Contents | Next |
A pattern-matching IDS can look at a sequence of events to detect a problem. For example, if someone is suddenly removing dozens or hundreds of files, you might be faced with a disgruntled employee about to leave a system in an irreparable state. If you wanted to detect such an attack, you could configure your monitor to look for a sequence of N file deletions in a row by the same user, and ask the system to alert you when this threshold is hit. The first challenge to your thinking is the interval problem.
Suppose someone has 100 sensitive source files that are not backed up on any other system. This practice is bad to begin with, but it really does happen. If this intruder knows you are looking for successive file deletes, one possible way to escape detection is to delete one file each day for the next 100 days (or any number of deletions per day less than N). If the scope of your detection pattern is a login session, or a day, or a week, the pattern will not detect the problem because the threshold is not hit before a new scope boundary is hit. The pattern must reset its counter when a scope begins. Within each scope there can be any number of intervening events between successive file deletes. This is not a problem for the signature because it is happily counting the events as they occur, regardless of whether each delete command is followed by ls or any other command.
Most IDSs do not enable you to define a scope for resetting thresholds. Instead, the simplifying assumption is that a login session defines the scope of interest. Thus, if the user deletes N files between login and logout events (in the same way that parenthesis bound a related comment), the pattern will fire. The problem with this approach is that it will not catch the trick mentioned previously.
An alternative approach would be to track N file deletes regardless of the number of intervening events. The problem here is still to define the scope. If the scope is defined broadly as “from the very first event for this user on this system” up until “now,” the pattern will be of little use. Over a period of years, an employee is sure to delete many files. The pattern would fire every day for some user. Defining scope as a week, or as a day, or some other calendar duration is a good idea, but IDSs do not provide this capability today.
A statistical anomaly detector suffers from the same dilemma. Usually, these tools take a per day approach to computing the baseline, giving the number of average file deletes by each user per day. To catch a tricky hacker, per week or per month metrics also would be needed. If the perpetrator is someone who deletes hundreds of files per week as normal behavior, catching the disgruntled employee described before will be tough.
Think about a single system for which you are responsible. One type of attack can originate from a user logged on to your system. Another possibility is that the crack is launched via a network connection to the system. For each of these two categories, different attack severities range from denial-of-service up through gaining superuser privileges.
A system with a network adapter thus faces threats from users who are logged in and running programs and from users who connect to this computer from other nodes in your network. The goal of a hacker who has a login account on the system is to gain superuser privileges to have complete control. The goal of a hacker who does not have an account on the system is usually to establish an account on the system. The usually is added in the last sentence because it is not necessary for a hacker to have an account on a system to wreck things. Network connections to programs with security weaknesses can be exploited by crackers to do things just as if they had a login account on the system. Getting a login account just makes it easier to explore or trash a system.
In these sections, the focus is on attacks that can occur when a user eventually has login access to your system. In the next chapter, you will see how some of these same kinds of attacks can occur when someone communicates with your system over the network. In the worst case, a remote user without an account is able to gain superuser privileges on your system. For the moment, though, you should focus first on how local login users can exploit your system’s weaknesses.
To recap the increasing severity of local problems, remember that the list goes as follows:
At this point, you should see a limitation of IDSs that is shared with other tools. If you do not configure the tool properly, it will not catch intrusions or misuse by insiders. You must specify what you want to monitor, unless you monitor everything. To use an IDS, you must state your monitoring policy, particularly if you want to monitor resources not predefined in the IDS, such as application binaries. As you can see, the IDS might make some assumptions that a knowledgeable hacker can use to avoid detection. This doesn’t mean that IDSs do not work, it just means that catching hackers is really hard and requires tuning of the tools.
| Previous | Table of Contents | Next |