Intrusion Detection Systems

Date Entered: Wednesday, 23 February 2000   Author: David Brumley   Story: Methods of attack: Some common approaches 1. Probes - These are used to map the topology of the network. Ping scans, half open scans, etc. normally fall into this category. IP Fingerprinting is the Hot New Item.

2. Protocol attacks: These are attacks against weaknesses in the protocols themselves, most notably TCP/IP. Some examples are: a. Predicting sequence numbers (session hijacking) b. SYN storms c. ARP attacks d. DNS attacks

3. Programmatic Attacks: Attacking a host based on the service it provides. Common instances of this are: a. Buffer Overflows b. Race Conditions c. Password guessing

So, how do you detect these things? What we want is something that: a. Can distinguish from an attack and normal usage b. Gives zero false positives c. Gives zero false negatives

Items a and c are the most important. We don't want to miss any attacks, and we don't want to be overwhelmed with information on normal usage.

Detecting Probes: To detect Probes (1 above), we look for one to many relationships. There are two approaches to looking for the one to many relationships. Either we can set thresholds above which something is considered an attack or we can have an AI engine learn what "normal" network traffic is for a given host/IP range/etc and an attack is anything that deviates.

The fundamental problem associated with either approach is people "sneaking in under the radar". If we assume that the attack knows what the thresholds are (a reasonable thing to assume), he can simply sneak in underneath. Lowering the thresholds to make "sneaking in" harder gives more false positives. Raising them leads to more false negatives.

An interesting case is the fingerprinting probes. Here we're looking for one to many not necessarily in number of packets, but in number of "malformed" packets...packets with weird tcp/ip options. Although we can make a list of current fingerprinting packets (like what nmap produces), this list could be arbitrarily long.

Detecting Protocol Attacks: At this stage of the game an IDS has to have an understanding of the low level protocol used to communicate between machines. All attacks really focus around injecting unasked for packets. For instance: a. Predicting sequence numbers is an unknown host (b) trying to pretend to be IP (a) by using the correct sequence numbers. Often in the initial setup phase (b) tries sequence numbers that aren't quite correct (not in synch) and then slowly synchs in. b. SYN storms can be used to help predict sequence numbers (if there is regularity in the sequence numbers) or as a DoS. In any case, the pattern is a whole shlew of SYN's are sent out to (a). (a) responds with a ACK, but a SYN-ACK is never seen. Internally hosts take care of this with SYN cookies. I can't remember off the top of my head exactly how these work, but basically a cookie is made per host instead of per connection. c. ARP attacks are unsolicited or out-of-network ARP replies are made saving "Hey, I'm your router over here." When the hosts take on the new route, the malicious host can sniff packets to launch other attacks. Detection seems to only come from knowing that the route isn't appropriate, whatever that means. d. DNS attacks. The malicious host responds to a DNS query that was never made. (DNS servers will accept responses to queries never made then cache it as though true..so you can say IP address 36.0.0.1 really translates to "my.host.is.really.neat.com", which will be cached. Then when someone queries the name server for 36.0.0.1, the false name is returned.)

Detection really relies upon knowing that the interjected packet shouldn't be there and isn't appropriate. This is where heuristics come into play. Some are easy.....if a response is made without having a corresponding request, it's probably an attack. Others, like ARP, may be harder to detect.

Detecting Programmatic Problems: At this level the IDS needs to understand the client/server protocol. The IDS may need to go even further..it may need to understand the particular implementation of the client/server. For example, under some web servers the "../.." request will break out of the web server root. However, on others it will not. The big question is how to tell the difference between a valid URL request: "http://something/blah/blah/blah/../../file.html" and "http://something/blah/blah/../../../../etc/passwd"

Furthermore, how can you tell either string against just a random packet transferring data? Suppose I'm transferring a text file containing methods on how to hack. An alarm probably shouldn't go off just because the packet contains a malicious string....because the protocol isn't correct for the attack!

A system cracker is usually going to run a series of tools in order to break into a machine. First they may fingerprint a network. Then, after identifying redhat linux machines, they may try a port scan. After they've determined which redhat linux boxes have port 111 open, they may try a mountd exploit.

After the exploit, they may notice they're on a switched network and their sniffer isn't getting anything. So they send out a reply to requests never made offering itself as the best route anywhere....suddenly traffic that shouldn't' go through the switch goes through the switch.

If one alarm is set up, a conversation mode should be enabled on both the src and dst host. The reason is that often the mountd attack and the actual login may come from two different places. This is the only way I see to not only detect an intrusion, but help an administrator recover from an intrusion (this second part is really key if you think about it. Isn't an IDS more marketable if it lets you know exactly what happened?)

Errata (misc. wonderings): There is another type of attack being employed these days: fooling the user. It's possible for someone to register "Amazone.com", copy over all the web pages from "amazon.com", and simply use it to steal credit card numbers. Though interesting, I don't see this as something we can protect against. But, it's something to think about.

Another thing to think about is combining data from multiple sources. Suppose you had n gateways and there was an attack that came across both. Can you correlate the data *real time* and discover the attack?

If I were programming this, I would focus on a good scan detection interface. I would also start looking for evil packets..things that really stick out like packets with every option on earth set. I would use these to trigger conversation modes. Although you may miss the dictionary attack against the http port with this system, you will find the regular systematic attack. And on some level this is what you want...a network IDS should detect network attacks. A local IDS detects local attacks. Password guessing via HTTP seems to me to be local, i.e. it only uses the network incidently.