What causes a TCP SYN-attack?
I have a server and an application that communicate via TCP. At times the server side stops updating the application fully. In other words, not all parameters of the application are updated. The only way to correct the problem at the moment is by resetting the server. I used a network analyzer to attempt to get to the bottom of the problem. Based on the captured trace and research, I believe the problem to be a TCP SYN-attack. My question is what causes a TCP SYN-attack and are the symptoms that I described consistent with this type of attack?
A TCP SYN-attack refers to a commonly-seen denial of service attack that may be perpetrated against a host to prevent it from handling connections. By way of explanation, TCP stands for Transmission Control Protocol
and is the primary transport for most of the data on the Internet. In order to open a connection to a host on the internet using TCP, a "3-way handshake" takes place between the client and the server. The first part of this handshake involves the client sending a TCP "SYN" ("Synchronize") packet, which is then acknowledged by the server.
The problem is that servers generally either have a resource limit on the number of outstanding connections they can have in this handshake pending-completion state, and may refuse to service further connections until these resources are available. This corresponds to the symptoms you have described. Since the overhead with sending a SYN packet is small, even a client on a relatively low-bandwidth link may be able to launch a significantly damaging attack. The problem is further exacerbated by network providers who do not perform source address filtering, allowing the attacker to effectively hide their identities.
Common solutions involve using servers that are resilient to such attacks. Of course, this is often easier said than done, so the preferred method of protection for many sites generally involves deploying a traffic management device that can block such attacks from ever reaching their servers. When deploying such a device, one should evaluate that the device not only blocks these attacks, but does not impose any penalty to the overall user experience.
This was first published in November 2005