Layer 4 Denial of Service: SYN/Spoofed SYN Flooding.
Introduction:
Denial of Service attacks are still among the most prevalent online attacks. At first they were seen as a way for IRC users to settle disputes (ok, I put that FAR too nicely. Really a way for pissed off people to piss off other people on IRC…), and eventually they ended up being used for extortion (gief money or we blast ur site offa the internetz!!). However, these days it is not too uncommon to see DoS/DDoS attacks being used either by unscrupulous businesspeople to take out their competitors, or, in recent years, as the primary weapon of hacktivists – for example the “Anonymous” group.
In this, I intend to briefly cover the topic of SYN/Spoofed SYN (and, of course, simple connect()) flooding. Later I will cover UDP flooding and “evil TCP Packets”, etc. The diagrams are courtesy of Encyclopedia Dramatica and Wikipedia, as I saw no real reason to draw my own, what with decent ones already in existence.
Please note, this article assumes you understand the basics of TCP (3 way handshake, flags), however, I will cover those in a later article.
The SYN Flood.
The common, or garden, SYN flood effectively functions by sending many “SYN”, or “Hello” packets to the victim server. What happens then, is the server sends back SYN-ACK packets, and awaits the sender to reply with an ACK, opening a new full-connection. In a SYN flood, you do not reply with an ACK, instead just vomiting more SYN packets at the server, causing its state-table of pending connections to fill up. If you succeed in filling it up, the server cannot accept legitimate connections, causing a denial of service to legitimate clients.
Good ole SYN flood... Exhausting the sockets
In some cases the server may have “SYN Cookies” enabled, which migitates this effect. (I will write about these in another article.) In this case, the SYN flood MAY STILL SUCCEED, by simply blasting the server with so much data that it’s bandwidth is exceeded. This is as simple as basic physics – the guy with the bigger pipe wins.
Often scrubs and lamers attempt to SYN flood large servers with their home connection, occasionally they succeed (if the server is not implementing SYN cookies or other mitigation). However, if they must rely on pure bandwidth, they are destined to fail. Epically. This results in both embarrassment, and, in either case, a knock on the door from men in suits who are NOT the mailman
For this reason, most people use a botnet to SYN flood. More on this in later article on botnet powered DDoS, and why most botnets do not ACTUALLY SYN flood.
The following BASH script demonstrates a simple SYN flood using HPING3
== SNIP ==
#!/bin/bash
#flood.sh – SYN Flood Demo Script
echo “Launching SYN Flood against $1″
hping3 -S –flood -V $1
== SNIP ==
And here is an example of it being used to flood localhost for several seconds…
root@bt:~# ./flood localhost
Flooding localhost
using lo, addr: 127.0.0.1, MTU: 16436
HPING localhost (lo 127.0.0.1): SPU set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic —
170179 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@bt:~#
This was a mere 5 seconds of SYN flooding, and in theory, 170,179 connections would be “pending” on the target box. Likely a hell of a lot less – packet loss, etc, and the fact I was flooding myself, however, I am fairly sure most servers would die fairly fast if subjected to this kind of abuse from someone with a decent upspeed (1gb/s or so?).
Due to firewalls, SYN cookies, and such migitating against this, it would likely fail against most large targets who implement load balancing, etc. However, remember: An attacker can simply DoS your firewall or router… Effectively knocking you out anyway!
Oddly enough, the above also has a tendancy to turn off network capable Sony Bravia TV’s. Which are not renowned for having a hardened TCP stack.
The Spoofed SYN Flood.
The main issue with “vanilla” SYN flooding is that every packet you send at the victim has your IP address stamped on it. Which is how the men in suits know where to come looking for you. Also, the fact of the matter is, their box is spamming packets back at you (and, due to how TCP/IP works, is spamming MORE packets back than you send at it – retransmissions for redundancy), making it not only easy to find you, but also kind of hozing your own connection as well. This is why I consider SYN flooding to be the equivalent of a kamikaze attack of sorts…
So, what do we do about this? Well, you can always spoof the IP address of the sender… Making it non traceable back to you (in theory – some ISP’s “fix” spoofed packets), and also making sure more of your pipe is free for the spamming.
Another point to note: Some DDoS migitation solutions block an IP that they detect is flooding it. Spoofed floods actually can get around some of these “solutions”.
The following BASH script demonstrates this quite well I think…
== SNIP ==
#!/bin/bash
# spoofed.sh – Spoofed SYN Flooding Demonstration Script
echo “Flooding $1 with randomly spoofed SYN packets”
hping3 -S -P -U –flood -V –rand-source $1
== SNIP ==
As you can see, we added the –rand-source operator to hping, making it randomize the packet-sources. This means that they (Theoretically) have no way of tracking us…
And here is an example of it being used to flood localhost for a few seconds…
root@bt:~# ./spoofed localhost
Flooding localhost with randomly spoofed SYN packets
using lo, addr: 127.0.0.1, MTU: 16436
HPING localhost (lo 127.0.0.1): SPU set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic —
230989 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@bt:~#
See? A literal shitload of “untraceable” packets have been sent to the target in about 5 seconds, now imagine if this was left running, from a high bandwidth server, for several hours? Or days even?
Your mileage may vary with this – some providers DO “fix” or simply drop spoofed packets, however in a later article I will show you how to test does your provider allow spoofed packets. I just have to find the research some university in America did first… I know I have it saved, but, you know how these things are!
TCP Connect() Flooding.
Now before I get started, connect() flooding is fucking stupid. Seriously. It is inefficent, leaves MASSIVE amounts of logs (you establish a full connection), and generally… Yeah. Sadly, this is incredibly common – in fact – it is the default attack-mode of things like LOIC, etc. Essentially you just establish a whole bunch of connections to the victim server and hope to god you either exceed its connection-limit, or its bandwidth.
Again, horribly inefficient, but that is just the start: It also is damn near GUARENTEED to get you a visit from the “Men in Black” – see the poor LOIC using scrubs who got caught – and it is just… Silly.
The only reason this seems to be so common is because Windows does not easily allow messing with raw sockets/packets, unless you happen to load the winpcap driver. The “Syn Flood” and “SSYN flood” in EVERY Windows bot/flooder/RAT/whatever is really just a TCP CONNECT() flood with LOTS of threads, and closing/opening connections really fast. Unless, of course, the malware author hops into Ring 0 or gets SYSTEM privs and loads the WinPCap or similar driver.
NOTE: Older versions of Windows (XP prior to SP2?) allowed raw sockets!
Now, for this demo script I ended up using nping from the nmap suite, as I wanted to get to grips with it. See it as an upgraded hping. You should try it – I am still experimenting with it, and it looks REALLY cool! Still in development…
== SNIP ==
#!/bin/bash
# tcpconnect.sh – lame tcp connect() flooder
# as you can see, I simply set –rate and -c (count) to big numbers.
echo “TCP Connect flooding $1″
nping –tcp-connect –rate=90000 -c 900000 -q $1
== SNIP ==
So, as you can see, it is a very simple script. Nothing fancy, and now for the demo…
root@bt:~# ./tcpconnect localhost
TCP Connect flooding localhost
Starting Nping 0.5.61TEST5 ( http://nmap.org/nping ) at 2012-05-23 05:40 IST
^CTCP connection attempts: 10965 | Successful connections: 3256 | Failed: 7709 (70.31%)
Tx time: 6.23043s | Tx bytes/s: 140792.96 | Tx pkts/s: 1759.91
Rx time: 6.23043s | Rx bytes/s: 20903.87 | Rx pkts/s: 522.60
Nping done: 1 IP address pinged in 6.23 seconds
root@bt:~#
The output says it all really… How many connections succeeded, how many failed. I had to set the -q arguement lest I be blasted with verbose output – it is INCREDIBLY LOUD about what it is doing!
The main problems with TCP Connect flooding are… EVERYTHING! You cannot spoof your packets, you make a giant bloody mess of the logs, it is horribly inefficient, and it is almost guarenteed to get your ass caught. HOWEVER, it has one simple redeeming feature: It weeds out the idiots from the rest of us
Conclusion.
In this article, we briefly went over some of the basic methods of executing Denial of Service attacks, and how they work. Hopefully this will serve to de-mystify these attacks for most of you, and if you understand them, you can maybe migitate against them better.
We also learned that 2 of the three ways discussed will likely get you arrested for various crimes (Denial of Service attacks ARE ILLEGAL!), and that Windows malware has the lamest TCP flooding style ever.
We also have now a decent basis for further articles discussing more advanced techniques!
![[IMG]](https://lh4.googleusercontent.com/-_HP1SXDqFQg/UJPsWErsODI/AAAAAAAAAHU/Qe97rL9DffQ/s800/175690_451848391520365_562643282_o.jpg)
