Reflected SYN Floods

Spoofed SYN Flooding – A closer look at Amplification and Reflection.

In the First Part of this series on Denial of Service attacks, I explained how Spoofed SYN Floods worked. I also briefly mentioned in the SYN flood part, how the server replies with *more* data than you sent it.

In most cases anyway, this is true. If I send ONE SYN packet to a server, it normally sends 5-7 SYN-ACK packets back at me, just in case some get lost along the way.

So, for every packet I send, I get several packets back… Bear this in mind as we continue.

The Spoofed SYN flood script shown, spoofs its SOURCE IP as that of a random host. So our victim will be sending this random host a SYN-ACK packet, that the random host never knew was coming. In fact, it will be sending it *several* SYN-ACK packets…
So what does the random-host do about this?

Well, if you receive an erroneous SYN-ACK packet that you never requested, you simply reply with an RST, or RESET packet. This is the cyber-equivalent of “Bugger off”. And you don’t just send one either… You send between five and seven of them…
Now before you start thinking you could kick off some kind of endless loop here, no. If you get a RST you do not reply. Simple as that.

So, are we getting the picture here? We can have an amplification factor of (theoretically) between 25 and 49 times the amount of packets we are flooding with. IN THEORY. Accounting for massive packet losses that tend to happen in flood conditions, we are looking at a more modest 5-6 times amplification… Which is still not bad! Not bad at all! We MAY even get a 10x amplification if we are very lucky…

So, that simple Spoofed SYN Flood script I posted… A lot more lethal now, no?

AS an aside, What if you never bother sending packets to the victim host at all? What if you spoof yourself AS the victim, and spam the entire internet? This is going to give you a 3-4 times amplification, and is the implementation most spoofed-syn-flood users use. I have NO idea why, as it is less efficient. However, it does bypass rate limiting,, so it has its place. I will post up some example code that does this next time I find it…

References/fact checking:
RFC 793
RFC 4987
CERT Advisory 1996-21
Arbor Networks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>