DoS/DDoS attacks are a nightmare to any server owner. The name DoS (Denial of Service) aptly summarizes this cyber attack aimed at web services which usually results in legitimate users being denied of server/network/resource by intelligent attackers. Here in this post, we get to analyze what goes on with a server which is under a DoS attack.
A D-DoS attack is when a huge number of people attack the same service at the same time (Distributed DOS). Such an attack is capable of bringing down even large organizations’ web services. D-DoS attacks are most often carried out by “bots” in a botnet. (Botnet is an army of infected computers and each computer in the pool is called a bot. These bots execute whatever they are told to do from a command and control ( C&C) center. This is controlled by the actual attacker.There are a gazillion types of DoS attacks attacking different layers/aspects of the service.
An analogy of a DoS attack:
Imagine a nice little famous fancy restaurant in town where hundreds of people come with their family and friends to have a nice meal. Let’s say there are 30 tables and 5 waiters in the restaurant. So, each waiter manages 6 tables. This is a busy day and all the tables are full. But the thing is, among the 30 tables, one table is occupied by some individuals who actually came just to annoy the restaurant owners and waiters. So, what they do is, they call upon a waiter to take the order, but ask him to wait a few minutes so they can decide on what to order, but they don’t order anything. Meanwhile, when the waiter offers to come after a few minutes, they say “no, please wait a few more minutes we will decide what to order in no time”. And this game goes on. Of course we don’t see this happen in real-life, but it is possible when you deal with a software. Why? Because the thinking of computers are limited to what exactly they’re directed to do. In this case, the waiters are “programmed” to serve the “clients” without any hesitation. So, what happens? Well, this waiter is stuck with this table and he cannot serve the actual legitimate users who are waiting on him. Now, that is denial of service.
Analyzing a DoS attack
To analyze a DOS attack, we have to face a DOS attack. But, when we are actually facing a DOS attack, we will be trying to mitigate it, not analyze it. So, we will attack ourselves and see what’s going on inside the server during the attack.
Let’s attack ourselves
Victim machine: Intel Core i3 Processor, 6GB RAM.
Attacker: The same machine.
I have Apache 2.4 running on my local machine, and I will be trying to DoS my own machine and see if I can access a website hosted in my local machine itself.
As mentioned before, there are a dozen different types of DoS attacks. Here, we will be using the good old “Slowloris attack”. Slowloris is a Perl script used for DoS attacks against HTTP servers. Slowloris is old. 6 years old, to be exact. But that doesn’t mean slowloris won’t work anymore. It will work, unless and until you decide to do something about it.
Now, how does Slowloris work?
It works exactly like the example I have explained before. We have the web server waiting for connections from legitimate users. An attacker comes to the scene and makes partial connections to the server. This does not mean that the attacker would create incomplete TCP connections. He would indeed create valid TCP connections, but the HTTP requests will be incomplete. Why does it matter? It matters because intrusion detection systems that rely on signatures can do nothing about this attack.
This is how slowloris works:
1. We have the web server ready to receive connections
2. An attacker sends a partial http request to the server
3. Server accepts the connection and waits for the request to complete. ( This was done to make sure that clients with slow internet connection do not get cut off in the middle of browsing )
4. The attacker will not complete the connection. Instead he opens new partial connections.
5. When a connection is about to timeout ( timeout is the maximum amount of time the server will wait for the client to complete the request ) the attacker will send some random data through that connection just to keep the connection alive. ( like asking the waiters about tonight’s special )
6. Gradually, the attacker opens a large number of incomplete connections to the server, and ultimately, the server is out of resources and it will fail to serve the website to the actual, legitimate users.
This is how Slowloris works. The thing about slowloris is that it is a small bandwidth attack. You don’t need a huge bandwidth to take down the server, you only create a large number of connections.
All right, let’s kill it
Disclaimer: You should not attack any machine or service you’re not authorized to do so. If you do, that’s a punishable offense and it’s entirely your responsibility only.
First, download the “slowloris.pl” script from https://github.com/llaera/slowloris.pl
Grant execute permission to the script
# chmod +x slowloris.pl
Now run the script against our local machine. Don’t worry, it will not crash the system. It will only affect the Apache server.
# ./slowloris.pl -dns localhost
The attack just started and let us take a look at our process list.
Apache is spawning more and more processes to handle all the connections
Let’s check how many Apache processes were spawn.
Yep, 152 Apache processes. Here, the site is a simple html page, and so the memory used by each process would be really small. But that’s not the case with a real website. You get the idea.
Now let’s check the number of connections per IP. Since we’re attacking ourselves, there is only one IP and that’s “127.0.0.1”
Did you notice one thing? Yeah, the number of connections is gradually increasing. At this point, let us check how’s our website is holding up.
Oops..!! The site is down, and did you notice the error message? “ERR_CONNECTION_RESET”. That’s right, apache is resetting any new connection and the legitimate client is denied from visiting the website.
Let us also take a look at the server load, and see if there is any abnormalities in there.
Don’t mind that single core hitting 100% CPU, that is caused by the attacking script. Other than that, there is absolutely no additional serverl load at all. And the memory usage also is normal. This is one characteristics of the slowloris attack. It will not affect other services, just the HTTP server ( Apache 1.x, 2.x etc ). Oh, btw, nginx is resistant to slowloris attacks 😉
Uhm, What do we do about it?
You saw how easy it is to take advantage of this and take down a website. But, fortunately, since there is only one IP involved in the attack, it is easy to mitigate these kinds of attacks. Let’s see how to mitigate the slowloris attack
1. Use a server (like nginx) that is not vulnerable to slowloris ( at least as the front end proxy )
2. Limit the number of connections per IP. This will work against small attacks, and will never works against large scale DDOS attacks ( Distributed denial of service attacks) . Add the following iptables rules
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j REJECT
What it does is simple, it will reject connections if the number of connections from a single host is more than 50.
3. Use mod_qos
mod_qos is an apache module which gives you full control over managing the number of connections to the server.
Well, that’s it for now. If you have any suggestions to mitigate slowloris attacks, feel free to leave a comment.
About the Author: