24.0052 FLOODER.614 > SERVER.LOGIN
14:18:24.0052 flooder.614 > server.login: S 1382726974:1382726974(0) win 4096
IDIC - SANS GIAC LevelTwo
©2000, 20019
The trace above is a valid SYN flood; in fact, it is “the” SYN flood that we learned about in the Mitnick attack. On the next slide we morph the trace a bit to illustrate a point. From our earlier studies on the “elegant” SYN flood, we learned that through a design flaw, it was possible to execute a denial of service attack against a server with 6 – 10 packets per minute. You can imagine that system designers have been trying to get this fixed ever since. Most modern operating systems are not vulnerable to this particular SYN flood. However, we keep hearing about SYN floods and not in ancient literature either; do they still work?Certainly, just not at a packet rate of 6 – 10 per minute. Modern SYN floods exhaust resources by sending a much larger number of SYN packets and though there are countermeasures, there comes a point where there isn’t much you can do, just too many packets flying around.One last point before we go to the next slide: just how do intrusion detection systems report a SYN flood? Essentially, you would count the number of SYNs over a time period like 5 seconds. If the IDS had no notion of state, that would be the end of it. If you had too many SYNs, raise an alarm. If you have a more sophisticated system, you can decrement the counter when you get lone ACKs completing the 3-way handshake and possibly on RST as well.[Narrator – historical information, do not read.]Source: [email protected] (Tsutomu Shimomura), comp.security.misc Date: 25 Jan 1995“About six minutes later, we see a flurry of TCP SYNs (initial connection requests) from 130.92.6.97 to port 513 (login) on server. The purpose of these SYNs is to fill the connection queue for port 513 on server with "half-open" connections so it will not respond to any new connection requests. In particular, it will not generate TCP RSTs in response to unexpected SYN-ACKs.”