Internet Holes

The SYN Flood

Copyright (c), 1996, Fred Cohen

Series Introduction

The Internet is now the world's most popular network and it is full of potential vulnerabilities. In this series of articles, we have explored the vulnerabilities of the Internet and what you can do to mitigate them.

An Introduction TCP

This is an article that's been sitting on my desk for some time now, but for one reason or another, each month, I have decided to hold off on it. Unfortunately, the attackers beat me to the punch this time, and there is now a widely published program that implements the SYN flood at the press of a few keys. The effect, in case you haven't found out for yourself, is to deny service to your TCP ports, ... but I am getting ahead of myself.

The Internet's Transmission Control Protocol (TCP) protocol suite is one of the most commonly used protocols for communicating between Internet sites. (1) The Internet Protocol ( IP - see rfc791) by itself provides no reliability or sequencing in its service of datagram delivery. To quote from RFC791:

The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service.

The TCP protocol suite was created to provide reliable sequencial delivery of information in a method suitable for use in emulating terminal sessions. As a result of its utility for this purpose, many IP protocol elements have adopted TCP as their primary (or sole) method of communication.

TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi-network applications. The TCP provides for reliable inter-process communication between pairs of processes in host computers attached to distinct but interconnected computer communication networks. Very few assumptions are made as to the reliability of the communication protocols below the TCP layer. TCP assumes it can obtain a simple, potentially unreliable datagram service from the lower level protocols. In principle, the TCP should be able to operate above a wide spectrum of communication systems ranging from hard-wired connections to packet-switched or circuit-switched networks.

Sounds great! But there's a minor problem. The initialization of the TCP protocol involves an exchange of packets between the visitor and the host. The visitor starts the process by sending a SYN packet to synchronize communication. The host then sends one of two answers back to the visitor; a RST packet restes the connection, thus refusing the request for service, while an ACK packet acknowledges the request and awaits the vistor's first packet in the stream of packets that ultimately forms the virtual terminal connection.

When the TCP protocol was invented, this all seemed fine and dandy, but one day a few years back, someone asked the question: How long does it wait?...

How Long?


Any guesses yet? \dots

Still no guesses? \dots

That's right! It waits forever!

Once a TCP session begins (i.e., after the next packet comes in) each TCP packet has a timeout. If a packet doesn't arrive in time, it times out, and eventually, the connection itself will time out, but because of the way the state transition diagrahms were specified so many years ago, in this particular state, there are no timeouts.

Here's what the packet might look like (to a close approximation) for an attack on a Web server's port (80):


 0                   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
| Ver=4 | IHL=5 |Type of Service|        Total Length=10        |
|         Identification=0      |F=100|    Fragment Offset=0    |
|  Time to Live | Protocol=TCP  |         Header Checksum       |
|       Source Address (forged and changes each time)           |
|              Destination Address  (victim's IP)               |
|     Source Port=1025          |    Destination Port=80        |
|                      Sequence Number=0                        |
|                   Acknowledgment Number=0                     |
| Off=0 | Reserved=0|0|0|0|0|1|0|          Window=0             |
|           Checksum            |         Urgent Pointer=0      |

How Bad?

Pretty bad as it turns out. Although there is no explicit specification for the number of simultaneous channels permitted on a given port, the vast majority of systems in the Internet allow 1024 simultaneous sessions. This means that in order to completely deny services to a given port on your computer (port 80 for example is the port that supports http - the world wide web protocol) until the next system reboot, the attacker only needs to send 1024 packets to your computer with the SYN bit set and port 80 specified. Each packet is about 40 bytes long, so the total amount of traffic is only about 40,000 bytes, or less than 20 seconds of traffic over a 28,800 baud modem. At T1 speeds (1 million bits per second) the attack takes only 1/20 of a second, and therefore, the 20 most important ports on your machine can be disabled in about a second.

One second of packets results in a system reboot - that's a big advantage for the attacker. But don't worry. Many systems run out of internal space to store the uncompleted connections before the second passes and crash on their own.

At first thought, you might decide to counter the attack, once detected, by filtering all packets from the attacking host at your router, but don't hold your breath. The published code for attacks uses forged IP addresses so that each packet has a different source host number attached to it. If you have read my articles about IP forgery you will already know that we cannot stop this sort of forgery in the Internet without global community action, and to date, the global community hasn't rushed to embrace the techniques described in my earlier articles.

Now What?

Here's the really happy news. This is a bug you can't fix at the router or using some add-on product. The only real fix is to modify your operating system so that it times out on uncompleted TCP sessions.

Several ideas for how to timeout include; (1) timeout after 10 seconds (or some other similar constant), (2) timeout the least recently started session when you start to run out of available sessions, (3) timeout the least recently started session as you near the limit of available system resources, and (4) timeout all of the uncompleted connections when few connections are left available.

Regardless of the method, it looks like this time, you will have to get a vendor-supplied patch - unless you run linux or one of the other operating systems that come in source form. Then you can try to write one yourself.


There are other problems with TCP, but you are probably already on the phone to your vendor for a fix to this one and I have another 20 journal articles to read before tomorrow is out, so I'll let you go with this thought - and with a transition.

The infrastructure of the Internet is fundamentally flawed in so many ways that it is a constant source of amazement that it doesn't collapse under its own weight. But for those of us who depend on the Internet for the competitive advantages it brings, there is little choice but to live with it and struggle to recover from the constant curves it throws us.

Now, after a year of writing these monthly articles, it is time for me to move on to other subjects. But I'm not going away. Rather, the editors have (I hope) graciously agreed to allow me to move on to different, and perhaps more interesting subject matter. The next year's worth of articles will go under the new name: Managing Network Security and take a management view of protection as an organizational activity.

About The Author

Fred Cohen is a Senior Member of Technical Staff at Sandia National Laboratories and a Senior Partner of Fred Cohen and Associates in Livermore California, an executive consulting and education group specializing information protection. He can be reached by sending email to


  1. Request For Comments 793 (rfc793)