Home / server / Questions / 423740
Accepted
Rob
Asked: 2012-09-03 18:20:10 +0800 CST

What happens if a server never receives the RST packet?

  • 772

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.

tcp

2 Answers

  1. Best Answer

    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.

    • 8

  2. 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.

    • 0