Network Defense by Rik Farrow Intrusion Detection Systems can let you know about the bad things that are happening in your network--sometimes Like burglar alarms, ID systems let you know when something is wrong. And like burglar alarms, ID systems only let you know after the fact, when the window is broken, and perhaps your jewelry is gone. That is, if the attack has been detected at all. Speakers at a recent conference on networking and ID in Santa Clara did not waste time either praising or bashing vendors. They focused instead on coming to grips with failings of ID systems, and examining possible solutions. While ID systems should be an important part of any large organization's security framework, they are no more foolproof than the firewalls that they often augment. Let's examine how ID systems can fail. Misuse There are several types of ID systems available (for listings of vendors and products, refer to the April '99 article in Network by Anita Karve), and several ways to organize the different varieties. Some systems are host-based, and monitor system event logs watching for evidence of misuse. Network based systems sniff network segments also watching for misuse. What both systems have in common is that they can only detect misuse that appears in the products' databases of attack signatures. New attacks, as well as minor variations on attacks in the signature databases, will not be detected or reported. In this way, most ID systems are like virus scanning software, only as current as the most recent update. Most attacks are variations on past attacks. For example, the Teardrop denial of service attack was quickly followed by more than seven different variations, all different enough to foil IDS recognition, yet all potent enough to crash systems. More recent attacks, based on buffer overflows of FTP servers used in many different Linux systems (see CERT Advisory CA-99-03-FTP-Buffer-Overflows in resources), did not come in a single form, but rather in more than five different variations. As a part of this attack, the exploit program directs the targeted FTP server to make directories (the MKD command in the FTP protocol) with 256 character filenames. The last directory name created contains the actual exploit code. A networked based IDS would typically look for the pattern contained in the MKD command, the exploit code, and if this changes, the attack will not be detected. Four different attacks were published between February 9 and 11 on Rootshell, including a denial of service attack against IIS 4.0. The only thing these attacks had in common were the use of long directory names. A search of other exploit sites turned up two more versions targeted at different OS versions, including SCO. Flurries of attacks, all with slightly different signatures, is part of the problem for ID system vendors. No vendor puts out new attack databases everyday, or even every week. Yet new attacks appear within hours of the original exploit. Stealth To make matters worse, there is the potential for stealthy attacks. Near the end of 1997, Timothy Newsham and Thomas Ptacek, now with Network Associates, published a paper about avoiding detection by network-based ID systems. While some systems have been improved since then, most of the points made in that paper are still valid today. Newsham and Ptacek's paper goes into great detail about the workings of the TCP portion of some popular IP stacks. By reading the source code, they pinpointed potential areas for abuse and evasion, and built a scripting tool that made repeating different tests easy. Then they tried their techniques against several different products. They used the 'phf' attack against UNIX-based Web servers as the basis for tests. All the tested systems could detect the string 'GET /cgi-bin/phf' when it was directed to TCP port 80. Most ID systems assume that the appearance of 'phf' in an HTTP GET request is a valid indication of an attack, and sending this string, using telnet or netcat, would elicit an alarm or alert from each product. The authors then tried different means to evade detection. The simplest means was also the most successful. By fragmenting the packet containing the string 'GET /cgi-bin/phf', all the tested ID systems completely missed detecting the simulated attack. But on the target system, the fragments were correctly reassembled, and the attack would have been successful (if the target had been vulnerable to the 'phf' attack). The ID systems under test did not reassemble packets, but looked at each packet independently. Ordinary IP stack do not work this way--they reassemble fragmented packets before passing them to an application. In other words, ID systems do not duplicate the manner in which typical operating systems, such as UNIX and NT, function. The business of reassembling fragmented packets is even more difficult than it might seem. 4.4 BSD UNIX, Linux, HP-UX 9 and Silicon Graphic's IRIX all favored new data when they received overlapping packets. In other words, if the attacker sent one packet that contained "GET /cgi-bin/pod" and then sent a second that overlapped the first, and replaced the "od" with "hf", these systems would pass "GET /cgi-bin/phf" to the application. But Solaris and Windows NT would pass the original data, "GET /cgi-bin/pod". So even if an ID system does reassemble packets, it seems that it must choose one of these two behaviours--or attempt to determine the operating system of the host potentially under attack, and use the appropriate scheme. The paper includes a total of 27 tests, two for establishing a baseline, seven fragmentation tests, and eighteen other tests. Nine of the other tests attempt to foil the ID systems by sending individual packets, each containing one character from the test string, sending these packets out of order, and with one or more duplicates. While this might seem arbitrary, most telnet clients send each character you type as a TCP packet with one byte of data, and of course, the packets can arrive out of order or duplicated. The next set of tests include introducing deliberate mistakes in the data stream, such as changing sequence numbers, using invalid IP or TCP header checksums, or closing the connection prematurely (or simply disconnecting the target system so that it nevers responds). In some tests, the ID systems failed to detect the attack, and in others, the ID system 'detected' an attack when the target machine's IP stack would have discarded the packets because the connection had been closed or because of errors the packet headers. Of the systems tested, only Network Flight Recorder (www.nfr.net) has been written to correctly maintain TCP state and reassemble packets, so that it would now succeed in the tests. The remainder of the network-based ID systems still work much the way they did over two years ago. Trouble Even when an network-based ID system correctly handles IP and TCP state, attackers can still cause trouble. During the ID conference, David Marchette, of the Naval Surface Warfare Center, described coordinated attacks. In coordinated attacks, it appears as if many people may be attacking at once. ANd there is not sure way of knowing if simultaneous attacks are occurring, if some attacks come from spoofed source addresses, or the appearance of an attack is actually the result of an attack on another site which spoofed one of the Center's own addresses as the source of the attack. Attacks and scans can also be done very slowly. If an ID system is maintaining state information, the attacker can proceed by beginning many simultaneous TCP connections in an attempt to fill up the state tables in the system. Or, the scanning tool may send packets so infrequently that it falls outside the window used by the ID system to detect packets that are part of the same scan. Dr. Peter Neumann, of SRI, suggested that improving host-based security was the real goal, not simply detecting intrusions. He favors hardening of an open source operating system by improving cryptographic algorithms, stronger authentication, differential access controls, and in some cases, multilevel security. Vern Paxton, of Lawrence Berkeley National Labs, also spoke of the failure of network-based ID systems. Not that they are worthless, but doomed, in his words, to eventual failure. Part of the problem is "network crud", traffic that appears to be an attack but isn't. This has included storms of FIN or RST packets, fragmented packets with the don't fragment flag set (a logical impossiblity), legitimate tiny fragments, and data that is different when retransmitted. Paxton is the author of BRO, a network-based ID system (see Resources), and he made his gloomy predictions as he was describing his experiences with his own tool. As for gleams of hope, NFR was mentioned as the best network-based tool, and EMERALD for its ability to assimilate information from many remote sensors and correlate data. EMERALD is a project of SRI, the source of much of the early research in host-based intrusion detection. EMERALD includes both host and network-based sensors, and looks for commonalities among reports, as well as vulnerability interdependencies across physically distributed components. EMERALD can be extended, and seeks to follow the emerging IETF standard for reporting security events. The field of anomaly detection is still in its infancy (after over fifteen years). Anomaly detection ID systems learn what normal host or network behaviour looks like, so they can detect attacks as anomalous behaviour. Several people reported on anomaly-based schemes that had varying degrees of success. A different spin on the topic was provided by Edward Amoroso, who works on infrastructure security for AT&T Labs. He likened ID systems to the Star Wars project of the eighties, which would have provided a shield above the US by shooting down incoming missiles. Star Wars never succeeded, and even more recent attempts at shooting down single missiles at high altitude have failed. There is an interesting corrollary between missile defense, and network defense. If a missile is detected thirty seconds before it will impact on its target, the defensive systems have less than thirty seconds to react successfully. In intrusion detection systems, when a host or network based ID system has detected a real attack, it has already succeeded. In the host-based ID system, it detects the attack by viewing logfiles, audit trails, and other mechanisms that reveal that the attack has occurred. In network-based ID systems, the network sniffer collects the packet, analyses it, then sends an alert describing the attack to the console or over the same network--but only after the attack has succeeded. In other words, ID systems are a bit like the Star Wars shield-- something that does not work. For ID systems to function correctly, they must detect the attack before it impacts its target, and stop or deflect that attack. For network-based systems, this means having out-of-band communications between sensors, analysers, and reactive devices (like internal firewalls) that can stop the attack before it reaches its target. For host-based systems, this means hardened operating systems which will not permit the attack to succeed in the first place, but can signal that an attack has been attempted. ID systems are not worthless. They serve an important function in any organization's network that cares about security. But ID systems have a long way to go before they can live up to the hype that has been spred about them. Today's ID systems will report more false alarms than real attacks, unless you have tuned the policy of the system to the point that it starts rejecting real attacks (false negatives). Intrusion detection is rocket science, and perhaps the once mythical shield will really begin to work. Resources: CERT Advisory about FTP buffer overflow attacks (initially from Netect): http://www.cert.org/advisories/CA-99-03-FTP-Buffer-Overflows.html Network and Intrusion Detection conferences, April 1999: http://www.usenix.org/publications/library/proceedings/neta99/ Thomas Ptacek and Timothy Newsham "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" paper: http://www.nai.com/products/security/advisory/papers/ids-html/doc000.asp Network Flight Recorder has a free download for research and non-commercial purposes: http://www.nfr.net. Information about EMERALD, and other ID research done by Stanford Research Institute, International: http://www.csl.sri.com/intrusion/index.html Information about Bro, a realtime ID system, can be found at: http://www-nrg.ee.lbl.gov/bro-info.html