After the SYN flood

In last week's Gearhead about how ports work, our fingers got a little overzealous and we typed www.isi.edu/in-notes/iana/assignments/portnumbers when we meant ftp://www.isi.edu/in-notes /iana/assignments/portnumbers (thanks to Bill Verzal, who was the first to spot our faux pas.)

As we said last week, a computer responds with a SYN-ACK when it receives a SYN packet from another machine. The SYN request is the first part of the TCP three-way handshake we discussed, and the SYN-ACK response is the second. Most computers will generate the SYN-ACK response whether or not a service is available on the port.

The third part of the three-way handshake is an ACK from the original machine that first sent the SYN request.

Now one of the big problems with this protocol sequence is that in many implementations of the TCP/IP stack, the receiving machine will accept the SYN request for an "open" port, create a data structure to handle the attempted request, and reply with a SYN-ACK. If the machine that sent the original SYN request doesn't follow up with an ACK response, then the receiving machine has to timeout on waiting for a reply.

Once the timeout occurs, the receiving machine safely disposes of the data structure that was set up to handle the possible connection. But if multiple SYN requests are received within the timeout period, the TCP/IP stack must simultaneously create multiple data structures.

If enough SYN requests are received, the receiving machine can't accept new SYN requests due to a lack of data storage (that will be a limitation of the TCP/ IP stack or simply running out of local operating system resources). It may also be that the receiving machine becomes so busy servicing SYN requests that other TCP/IP activity is significantly decreased or stopped altogether.

This is the nature of your classic SYN flood attack, a technique favored by discerning hackers over the past few years. It is considered to be a denial-of-service attack and can effectively block even a large pipe to the Internet, not by exhausting the pipe's capacity but by exhausting the resources of the machines using the pipe.

A SYN flood attack is difficult to counter because the source of the attack may not be obvious. This is because software found on the 'Net can be run on a machine that creates SYN requests such that the source address is a fake and changes with each SYN request sent.

There are several approaches to defending against SYN flood attacks that involve filtering and patches to operating systems. A discussion of an interesting technique called GENESIS (Gibson's Encryption-Enhanced Spoofing Immunity System) can be found at http://grc.com/r&d/nomoredos.htm.

See the CERT Advisory (from 1996), "TCP SYN Flooding and IP Spoofing Attacks" (www.cert.org/advisories/CA-1996-21.html) and Microsoft article "Internet Server Unavailable Because of Malicious SYN Attacks" for more information.

Finally, check out the Hack FAQ "Denial of Service Basics", which discusses SYN flooding as well as smurf attacks and Ping o' Death.

Next week, sockets and hacking. Message on the sly to gearhead@gibbs.com.