Denial Of Service Attacks (Pt 1)

I was kicking around some ideas the other day with a buddy, trying to figure out what would be a good topic to kick this thing off with. We mentioned things like BGP hijacking, malware analysis and CC fraud, and then he offhandedly mentioned a pretty banal DDoS attack that his network had seen recently. Luckily his network has an absolutely stupid amount capacity, so it ended up being pretty insignificant. But it got me thinking; DDoS attacks are where most script kiddies get their starts and it accounts for a fairly large amount of of news headlines throughout the year. So with that in mind, it kind of seems like a natural place to start.

DoS vs DDoS

While the idea is similar for both of these, the execution is where they differ. For a basic Denial of Service (DoS), it’s typically one connection being used to down a service (in most cases a webserver or something, but it’s not limited to that by any means). A Distributed Denial of Service (DDoS) attack takes the same idea and just multiplies it by many connections. The overall idea here is for you to throw enough of something at a service in order to overwhelm it to the point where it quits functioning properly (hence “denial of service”).

I’ll use this first image to describe a DoS attack. Think about that single connection I talked about and think about this single stream these dudes are sitting in. You should get the idea by watching it…


So now take that idea and multiply it across multiple hosts…


You can see very clearly how that could tank a box pretty quickly! This is also a huge part  (but not all) of the reason why botnets are a thing. Infecting thousands of computers and weaponizing them can generate devastating amounts of traffic if your bot-farm is big enough.

OSI Layers

DoS/DDos attacks typically happen in two different layers of the OSI model: the Transport Layer and the Application Layer.

*I say typically because you can cause DoS conditions in other ways. For example say you throw some exploit code at a box and things just don’t jive well; you could still down the service but it may not be in the same way.*

Let’s take a look at the OSI stack real fast…


The Transport Layer is where we would find our TCP and UDP connections, whereas Layer 7 (Application) is where we see our user interface and application based protocols like HTTP, FTP, etc. Abuse of these protocols and how machines handle them are what let us conduct these types of attacks.

TCP/UDP Floods

To better understand how TCP based attacks work, you need a basic understanding of how TCP works. Below is a quick example; it’s what we call the “Three-Way Handshake”.


Seems all nice and orderly doesn’t it? As with most attack techniques, the fun begins when we start messing with what’s “expected” and start doing our own thing.

Sure, that model works fine if Bill is only sending the amount of requests that he needs to get the services he requires from Sheela’s machine; but what happens if Bill were to send that request an additional 10,000 times? If Sheela didn’t have any defenses to help her out then her machine would most likely crater under the weight of trying to meet all of these requests. Her machine would continually try to meet the massive amount of requests, which means if anyone else were to try and connect, it’s either going to be incredibly slow or not work altogether.

tcp flood

In the above example a SYN flood is being utilized, but this style of attack isn’t limited to just the SYN flag. Again, a lot of attack vectors are born out of using devices or features in ways they weren’t designed to be used. So take that principal and imagine what a FIN flood might look like, or maybe sending thousands of RST packets. Sending a machine something different than what it’s expecting is a great way to break things, but sometimes that’s what we’re trying to do…

Redirection Attacks

Knowing what we now know about how basic TCP/IP connections works, let’s take a look at redirection attacks.

When you send a packet to a host it will obviously include the source IP of who sent it. But what happens if we changed that source IP that the host would look to respond back to? What if we bombarded a server with queries and changed the source IP that those packets supposedly came from to the actual target of our attack? The server in middle would see all of our incoming packets, but instead of sending the responses back to us, it would funnel them back to the spoofed source IP that it thinks the requests are coming from. We can weaponize this by spoofing the source IP to be that of our target, finding a server who will respond to requests without question, bombarding that server with requests, and tank the victim host with all the responses the recursive server will send back in response to our queries.


This style of attack is pretty common with DNS queries, but I’ve also seen UPnP requests and also UDP floods conducted this way. It takes a bit of work finding a quality middle man that will unquestioningly pass on random requests like that, but when you do that server can be weaponize in the manner described above.

For DNS recursion I always liked to use as a quick test to see if a certain server or router is vulnerable to being used in such a way. I’ve seen plenty of end user devices get harnessed into large scale attacks because they were misconfigured by the vendor, which allowed them to be recruited in this kind of attack.

What’s Next?

In part two, I’ll dive into Layer 7/Application Layer attacks! Stay tuned ^_^