I believe most of us heard about DoS or DDoS attacks. If not, let me offer a little recap — A Denial Of Service is a type of attack on your servers that causes real users to be unable to receive any response. That happens because the attacker sends many requests to your server, suffocating it, and there is no computational power left to serve real clients.
An easy ‘fix’ for this vulnerability would be blocking a certain IP address or user based on the velocity of requests/amount of requests/ amount of 4XX/5XX/2XX status codes returned.
Then comes the smarter, Distributed Denial Of Service (DDoS) attack. It is a bit more difficult to treat this one, since the attacker uses many different machines located all around the world, so blocking a specific IP won’t really help to protect your servers. Instead, a certain pattern must be found, and more complex rules should be implemented to locate & block the vicious attackers.
You could try to implement your own rules via platforms like fail2ban, though that can quickly grow and become very complicated and out of scope.
Different cloud providers offer different out-of-the-box solutions for DoS and DDoS. For example, AWS offers Amazon Shield.
DoS and DDoS are well known threats, and there are many solutions and services to mitigate these threats.
In 2009, a new and more intelligent variation of the DoS attack was introduced: The Slow Loris attack.
The Idea of Slow Loris
Your server must support clients with poor internet connection, right? You might have clients all around the world, not necessarily with great 4G coverage. Some companies, like Avante.com.vc for example, are targeting only this type of clients; located in developing countries, with low-end devices and limited connectivity.
Or maybe your client has great coverage, but the connection is often interrupted because the client is just entering the tube station.
Right, so your server must support clients with poor connectivity and poor performance. That is exactly the behaviour that the Slow Loris attack is simulating. A lot of poor and extremely slow connections. To the server — it seems like a lot of unfortunate clients connecting, nothing unusual, nothing to be worried about. The thing is that the SlowLoris attack eats up the server’s resources by sending all of these slow connections. Sockets aren’t freed, handlers are all busy waiting for the communication to be finally completed, but it just keeps going, never finishing to receive the packets.
And so your fancy app sits there waiting for the requests like-
and nothing happens. It never ends. And that’s when your server is suffocating — many SlowLoris connections are open, none of them are finished, and your server can’t serve real clients.
How it works
Every HTTP request ends with certain characters, that are parsed and understood by the server as “here is the end of our communication for this time”. Once the server parses these characters — it understands that the packet was received (doesn’t matter the content, and whether it is corrupted) — and that is it.
SlowLoris requests simply never send these characters, so the server never stops proceeding each message. It sends the packet’s content very slowly, and never sends the strings that indicate ‘that’s the end’.
You might say “But what about timeouts?” — You would be right, but the thing is that the SlowLoris initiator sends a byte every X seconds to keep the connection alive. “Yeah, I am extremely slow, but I am still here, here’s another byte for you”. So a timeout (unless configured otherwise) — would not help here.
First of all, the good news is that the most vulnerable platform for this attack is Apache servers. So other servers like nginx and IIS are less likely to suffer from this attack (Though would be best to check by yourself, this information might be outdated, never trust Medium writers 😉).
The bad news — the majority of servers today are Apache servers.
The good news #2 — mitigation is pretty straightforward.
One just needs to reconfigure the timeouts in the server, and that is it.
i.e — add this to your Apache server configuration:
<IfModule mod_reqtimeout.c> RequestReadTimeout header=20,MinRate=500 body=20,MinRate=500 </IfModule>
This configuration will kill the connection if the client fails to send the header or body data within 20 seconds each.
The bad news #2 — You must find the balance in your configuration in order to not block good clients that were unfortunate to have a bad connection, poor network coverage or a very low end device.
Mitigating risks is always a question of balance. “How many good users will be blocked by the actions I am taking in order to prevent bad users from misusing or hurting the platform?”. There is no simple answer to that. Researches and due-diligence are to be made by each company for each solution. Value-at-risk is a number you must have before implementing any anti-fraud and anti-hackers rules.
Be safe, do your research, always learn and protect yourself. Good luck!