Summary

When doing a post mortem on a successful system compromise or attack, you can often determine that the attack was preceded by intelligence gathering "recon" probes. The harder issue is to detect recon probes, take them seriously, and increase the defensive posture of a facility or system. Many times these recon probes are used to locate and investigate trust relationships between computer systems.

Attackers often exploit a trust relationship between two computers. Many times, system administrators use such relationships as a convenience for themselves, even though they are aware that this is a "chink in the armor" for the system.

The Mitnick attack deliberately did not complete the TCP three-way handshake to SYN flood one side of the trust relationship. Many attacks and probes intentionally do not complete the threeway handshake.

Crafted packets include packets with deliberately false source addresses. These often have a signature that allows intrusion detection to detect their use.

Checking things only once is a general problem in computer security. When designing software or systems, build in the capability to check and then recheck.

The signature of TCP hijacking is that the IP addresses change during a TCP session, while the sequence numbers remain correct for the connection. Reliable detection of TCP hijacking is still beyond the reach of single-tool systems in real-world environments.

Intrusion detection is best thought of as a capability, not a single tool. The Mitnick attack serves as an excellent test case. Intrusion-detection systems that cannot detect this attack on a realworld network with a real-world load (such as a busy T-1 or higher), just mislead their users into thinking they are performing intrusion detection when in fact they are blind. Even the best intrusion-detection system will be blind to an attack that it is not programmed to detect. Many intrusion-detection analysts prefer to use systems that enable them to craft user-defined filters to detect new or unusual attacks. The next chapter presents examples of user-defined filters.

Chapter 16. Architectural Issues

This chapter considers some of the tradeoffs, capabilities, and issues facing intrusion-detection system users and builders. This is a bit more theoretical than some parts of the book, but I use real-world examples to try to keep the material useful and pragmatic. We invest some time talking about events of interest (EOI). This is an important concept because an analyst gets better results from an intrusion-detection system if she understands what she is searching for and tunes the IDS to find it, as opposed to letting the IDS tell the analyst what to look for. We also discuss severity. All incidents are not created equal and should not be treated so. There is a great debate, a religious war in intrusion detection, about whether the sensor should be

placed inside or outside the firewall. This chapter covers this and other sensor-placement issues as well.

One of the great myths that have occurred in the industry is the need to work in real-time. I have even seen this specified in procurement documents. What marketers mean by real-time is that intrusion-detection analysts are supposed to respond to beeps and alarms. Real-time, of course, is almost impossible, at least for human reaction, because the packet is traveling at the speed of light. Figure 16.1 shows the detect occurring just after real-time. The illustration was added to the book in case you ever need to point this out to your management because they are overemphasizing response time. In fact, UNIX and Windows NT computer systems do not support either real-time or even deterministic delay. We discuss these issues in push versus pull architectures, which leads into a section on the analyst console. Moreover, as we will shortly discuss, the intrusion analyst will run filters through second and even third passes over the data looking for EOI.

Figure 16.1. Time and ID response.

Every intrusion-detection maker falls short in providing a really great analyst interface. This is currently the primary thrust of development of course, so we will take some time to discuss the interface. What exactly does an analyst need?

The next section discusses some of the tradeoffs, or "tuning knobs," that should be considered as you design or enhance your intrusion-detection capability. These include false positives and negatives and sensor focus.

Events of Interest

Chapters 13, "Introduction to Snort and Snort Rules," and 14, "Snort Rules Part II," introduced events of interest in the sense that when you write a filter, you design it to find something you are interested in. For instance, if you are using the Snort rule content option to find the hex pattern 0xdead or 0xbeef, a pattern that has its roots as a test pattern but is sometimes used by attackers in their code, and you come across a packet with this pattern, this is potentially an EOI. There are three main issues surrounding the subject of EOI in intrusion detection:

●The balance between false positives and false negatives

●Targeting or focusing the sensor to ensure we detect EOI

●The effects of the limits of our system on our capability to detect

The false negative/false positive problem is a serious one in intrusion detection and a lot of our

energy is invested in customizing filters to detect EOI and not to generate false alarms or false positives. On the other hand, false negatives would mean missing something we would have wanted to detect. I would like to illustrate what an analyst might do with a simple example. Attackers are known to use certain strings, numbers, and hex patterns in the software they create to do reconnaissance, denial of service, or direct exploits. Some of the classics are:

● The decimal patterns 31337 and 666 ● The ASCII string, skillz

● The hex patterns 0xdead and 0xbeef

Suppose we create a filter looking for hex 0xdead as shown below:
alert icmp any any -> 192.168.5.0/24 any	\
(msg: "0xdead hex pattern seen";	\
content: "|DE AD|";)

Would such a rule create false positives? Certainly it would. If the content of an ICMP packet happened to have these hex characters in this order, these simple content filters would alert. Would I want to run this rule in real-time? No, probably not. On the other hand, if we started seeing a lot of 0xdead 0xbeef, that could be significant. One of the lessons from the Shadow project was secondary analysis. Keep a couple of days of data and run programs to scrub the data looking for interesting events. I probably wouldn't even bother manually examining a single occurrence of 0xdead or 666 in a couple of day's worth of data, but if I saw a dozen, I would certainly think about pulling those connections and examining them.

The stories you learned about in Chapters 10, "Real-World Analysis," and 11, "Mystery Traffic," almost all have the same root. An analyst, looking at the data, saw something odd and said, "That's funny." When Judy and I were working together as active analysts for the Army and Navy respectively, we discovered a number of attacks for the first time. People would ask how we did it. I used to answer, "Pure, dumb luck." Now you know better. We would write scripts to slice and dice that data looking for those events of interest.

Another great classic script is to take a week or so of data and search for odd protocol activity

as shown in the following .bpf filter:

not tcp and not udp and not icmp and not igrp and not igmp

You certainly would not want to run this in real-time; but, as a way to run through your data looking for events of interest that you might otherwise miss, this is obviously attractive. After you know your network and get your filter optimized, most likely you will rarely detect anything with this filter. I don't recommend that you run it interactively and watch the results, because you might get bored and quit running it. However, if you schedule the job to run once a week and only design the system to alert you if it finds results, you have a tool that might strike pay dirt one fine day. If you are shopping for these new correlation consoles or enterprise security managers, one feature you might want to look for is the capability to schedule and run scripts to examine your data.

Now we complete our study of EOI with a consideration of overall system limitations on the lower detect limit. Let's start with the bottom line: It is important to have a fairly clear understanding of what you are looking for and what events you are interested in, because you cannot collect or detect everything. Figure 16.2 shows both the data actually observable by your

intrusion-detection system and the data you cannot observe.

Figure 16.2. Sources of data.

Limits to Observation

As shown in Figure 16.2, the sensor or event generator might not be able to observe all events. This is often quite a surprise for folks who pay good money for an intrusion-detection system, and they slowly find out just how limited it is in practice. What kinds of things can't we observe?

∙Events on a different network. Unauthorized "backdoor" connections into a network are very common; every machine with a modem has the potential to permit a backdoor. This issue shows up prominently in advertisements for host-based intrusiondetection systems because they can make the "we're here, we're there, we're everywhere" claim.

∙Sensor is not functioning. Events that happen right in front of the IDS, but they are not observed because the IDS is brain dead. By brain dead, I mean anywhere between hard crashed like the blue screen of death, to pingable while not functioning. A good measure of IDS reliability might mean time between having to reboot the system, because that seems to be the fix for both Windows NTand UNIX-based systems. I have personally experienced this joy multiple times with Shadow, NFR, NID, Snort, and RealSecure. Naturally, you only discover these systems need rebooting on rainy days when they are in a different building from your analyst console. Some systems are more robust than others, of course. What is the most effective Windows NT remote management tool? A car. If the sensor's disk fills up, this will also prevent collection.

∙No habla SNA or SS7. Events in a protocol that the intrusion-detection system cannot decode are not observable. What if you need an intrusion-detection system that can decode Signaling System 7 or IBM's SNA? Is there a need for such a thing? For most of us, the answer is no; however, one fairly common event is when we detect a protocol we don't know. For instance, I know a number of people who have detected IP Protocol 54, NHRP (Next Hop Resolution Protocol), at their DMZs and have never seen

an IDS decode this.

∙ Exceeding bandwidth limit. Events that occur above the sensor's maximum bandwidth-handling capability cannot be observed. At some point, the sensor has to start dropping packets and we enter what analysts euphemistically call statistical sampling. If you ask network-based IDS vendors what their upper limits of speed are, you get a lot of curious answers ranging from "80Mbps" to "it depends." Hint: Trust the person who says "it depends" more than the one who gives you a fixed number, especially a fixed number above T-3 speeds (45Mbps). The number of rules a sensor has to process is one primary factor in the sensor's upper detection limit for many systems, however the primary factor is the critical path. This is the longest execution path a given packet might cause the sensor to take. If a sensor is still processing one packet when another arrives, the packet will be dropped.

To recap what was just covered, intrusion-detection systems cannot look at every possible event. The reasons for this include the following:

∙The event happened on another network.

∙The IDS is dead.

∙The IDS has no understanding of the protocol.

∙The IDS has reached its maximum bandwidth limit, or has hit critical path on a given packet and has dropped packets that came later.

The bad news is there are events we can't even observe. The good news is that we find there are events that we can capture. Of all the packets that we can capture, some will match our filters in some way, and they are represented by the space of the inner circle. Finally, some of the total number of detects in the inner circle are valid and have value. We can refer to these as the EOI, the genuine, no-false-positive-about-it detects. They are the reason we go through all the trouble of deploying and operating intrusion-detection systems. Detecting an attack, especially a clever attack, is a lot of fun.

Low-Hanging Fruit Paradigm

Today, the primary standard in intrusion detection is the Snort ruleset. There used to be two major rulesets, but with the present legal troubles of Max Vision, his ruleset is no longer available. It has been inspiring to watch the community come and work together to build the rules, improve the port list, and explain the vulnerabilities. In some sense, I feel like a heel saying a single word against this worthy effort, but there is a risk to us that we at least need to be aware of. We have already discussed the basic issues of false positives and negatives when we covered signatures and filters to detect signatures. Now we need to consider the effect of the low-hanging fruit paradigm on false negatives. What do we mean by the low hanging fruit?

I live on the island of Kauai. Many things are in short supply, but we certainly have enough

banana trees and free range chickens. After a hurricane seven years ago, many of the chicken coops were blown apart freeing the chickens. There are no natural predators, so now the island is overrun by chickens. My neighbor recently had a bumper crop of bananas in his garden. I have never stopped to think about just how many bananas can grow on one of these trees, but it can be more than one hundred pounds. As the tree began to bend a bit with the weight of the bananas, they came in range of the chickens, at least the lower ones. They would line up under the banana tree and jump/partially fly and nip at the exposed bananas. It was quite a sight to watch and many a banana was ruined as its bottom was nipped off. So, the low hanging fruit is the easily harvested, vulnerable fruit that any one or any thing can reach.

Suppose a number of intrusion-detection vendors were secretly downloading the Snort ruleset and using this as a foundation for their own rules. What if their other major process was to go to a couple of well known sites for attack code to download the exploits to their labs, run the exploits, determine their signatures, build effective filters to detect these exploits, and then load these filters in the intrusion-detection systems we all use? If this were to happen, we would begin to establish a lowest common denominator. At first blush, that sounds like a good thing; as a consumer, you could expect any IDS to meet at least a minimum standard defined by the Snort ruleset and the most available attacks (most of which are covered in the Snort ruleset, of course). The problem is that an attacker can then analyze the Snort ruleset and craft small changes to her attacks to make them evade the IDS. If a number of commercial vendors copy these rules, this becomes an interesting problem. It allows them to treat the ruleset, a tremendous asset to the community, as low hanging fruit.

Although the preceding paragraph is partially true, there are lots of ways to mitigate the problem. Many intrusion-detection vendors and researchers culti-vate contacts with the computing underground and have access to a larger library of attacks than those commonly published. Several research efforts attempt to collect attacks and exploits and to define vulnerabilities. The problem is they use different names and descriptions. Mitre (http://cve.mitre.org) manages a project called the Computer Vulnerabilities and Exposures (CVE), which enjoys broad industry support. Their goal is to develop a common nam-ing system, primarily to serve as a thesaurus for vulnerability descriptions, but also to support IDS development.

Also, it is sometimes possible to write a general filter to detect a family of exploits. We have already examined a general filter to detect web server attacks. During the discussion of that filter, you learned about a number of CGI-BIN attacks against web servers that attempt to acquire the system's password file for offline decryption. The most famous is the phf attack. Several hundred others exist, however, including php and aglimpse. In the past, each of these had cgi-bin and /etc/passwd files somewhere in the packet, so it was possible to write a general filter to detect each of these and their cousins as well. Today, with the advent of shadow password files, we do not see many attacks against /etc/passwd; however we commonly see the following string:

id;uname –a; w

The command id gives you your effective userID; the semicolon delimits different commands; uname –a gives the exact operating system and patch level; and finally w tells you who is logged on to the system. It is also possible (and very advisable) to write general filters that detect odd events (things that just shouldn't happen) and to report them. A TCP packet with all flags set, or no flags set, and packets with unknown IP protocols are examples of these kinds of filters. Although you can increase the sensor-detection capability in many ways, the bottom line should be somewhat sobering: If an IDS depends on signatures and doesn't have a filter to look for that signature, how will it make a detect?