Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Someone recently decided to show me a POC of a new Denial of Service method using SYN/TCP he's figured out. I thought it was complete nonsense, but after explaining to him about SYN-SYN/ACK-RST, he left me speechless. He told me "what if the server you're using to trick into sending the SYN/ACK packets can't receive the RST packet?"

I have no idea. He claims that the server will continue trying to send SYN/ACK packets, and that the packetrate will continue to build up.

Is there any truth to this? Can anyone elaborate?

Apparently, the way it works is this:

He spoofs the IP of the SYN packet to the target's IP. He then sends the SYN packet to a handful of random servers
They all reply with their SYN/ACK packet to the target IP, of course
The target responds with RST, as we know
BUT somehow he keeps the target from sending the RST or keeps the random servers from processing it
With this, apparently the servers will continue trying to send the SYN/ACK packets, thus producing a somewhat of a "snowball" effect.

share|improve this question
Could you rough out what he thinks the packet-flow is for this attack? I'm having trouble visualizing it. – sysadmin1138 Sep 3 '12 at 2:28
@sysadmin1138 Edited. Hopefully that helps – Rob Sep 3 '12 at 2:31
Just what I needed, thanks. – sysadmin1138 Sep 3 '12 at 2:34
up vote 8 down vote accepted

As you know, the "attempting to open a port" packet-flow is supposed to work like this:

  1. SYN ->
  2. <- SYN/ACK
  3. ACK ->

The 'closed port' version is simple:

  1. SYN ->
  2. <- RST

And if the far end doesn't return RST packets, which is an extremely common firewall configuration:

  1. SYN ->
  2. [time passes]
  3. SYN ->
  4. [time passes]
  5. SYN ->
  6. [time passes]

And by extremely common I mean extremely common. All TCP stacks have to handle this case since it's so common.

The variant your someone proposed:

  1. [Spoofed source] SYN ->
  2. <- SYN/ACK
  3. [time passes]
  4. <- SYN/ACK
  5. [time passes]
  6. <- SYN/ACK

The 'attack' he's cleverly discovered is the SYN Flood attack, and has been known since the early 1990's. Thanks to firewalls blocking RST packets these servers won't know to close the connection, so they'll indeed retransmit the SYN/ACK packet based on the normal TCP retry timings. However, all modern TCP stacks do include some configurable measure of SYN-flood protection built into them.

This is still a somewhat effective method of attack, though the main harm it's caused is through overwhelming the perimeter security device with too many packets to keep track of. SYN/ACKs without a SYN should be dropped on the floor very cheaply, but if they come in enough numbers it can overwhelm a firewall.

share|improve this answer
Oh right. I suppose it would just be a standard SYN flood. And there goes my bewilderment. Thanks. – Rob Sep 3 '12 at 3:29

Syn Cookies effectively stop this attack. The server responds with a SYN/ACK, and forgets about it. If an ACK is received it then reinitialises the stream based on the TCP sequence number. On linux it's enabled by adding:

net.ipv4.tcp_syncookies = 1

to /etc/sysctl.conf

But when when being hammered by 10k+ machines, the server will still be taken down I reckon.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.