Contact:http://www.packetnexus.com
Fun with Packets: Designing a Stick By Coretez Giovanni This paper outlines a denial-of-service attack against not the computer network, but the human processes that support intrusion detection. This attack is a resource exhaustion attack as outlined in the previous paper "Topology of denial of service". It is informally written to express my opinion by which the tool "stick" was written to exploit. Hopefully this tool clearly shows some IDS flaws that will soon be remedied by better IDS products. Arthur Money spoke at Blackhat '00 about quality. Too bad there must not have been any software developers there to listen. I use Stick and other self-developed tools for evaluating stress capability of IDS and firewalls. At this time I do not have comprehensive listing of IDS that are unaffected by the preceding methodology that can be implemented using the Stick code. I am not endorsing any products in this paper. This paper and tool are opinion and should be treated as such. There are two IDS that I found checked the state before payload alarm which is essential for defending against Stick, but these systems did not detected other header attacks nor were they robust enough to detect a good deal of other attacks. If my home lab ever gets big enough I might be able to give a fair unbiased opinion. Until then, you should evaluate and consider this opinion with your own opinion and testing (as you always should do). Designing of the Attack People are the essential element in intrusion detection. Automated responses are rare due to self induced denial-of-service . Alarms are sorted in priority and are reviewed and summarized for response. Organizations hire just enough, people as to accomplish handling a normal load of alarms. Therefore, when a high number of false alarms are produced, finding the actual attack becomes impossible due to the lack of resources to investigate actual from spoofed attacks. When a high number of false alarms occur, the shear number of alarms makes the alarm data useless in informing the decision makers of the real status of the network. This is a form of information overload. The key of course is to create a high number of alarms that will trigger the system/network intrusion logs. Create An Alarm The easiest system to create alarms on is signature based intrusion detection systems (IDS). I will refer to IDS, in particular I mean network based IDS. Signature based IDS use a predetermined criteria in order to determine bad from good. The three most common attributes in signatures are IP packet header fields, transport layer header fields and packet data payload. If the attributes to set off the criteria for these three sections are known, a trigger packet can be created. Stateless Analysis For reasons of speed and processing power, a packet is often evaluated on its own individual merit regardless of other packets on the network. This is seen in many early detectors like "Shadow" and exists in most commercial detectors. It is a primary concern to most IDS companies and a common measure of quality when evaluated by the media. A design based on speed most likely means that a trigger packet needs no precursor event or post event in order for the trigger packet to set off an alarm. Triggering an alarm purposefully is not something the designers think about much. Designers do care about false-positives (bad alarms), but false-positives are considered in the context of normal traffic, and that these alarms can be filtered out in time. Validity The first weakness that an