Today I came across this article, and I was surprised to never have heard about this type of attack…
The slow loris is a kind of slow and low attack invented by RSnake in 2009. Instead of sending requests as fast as possible, it sends requests as slow as possible. The attacker splits the HTTP GET request in as many packets as possible, and sends them as slow as possible.
Do you know it?
How you defend against it in the Beam?
Unfortunately you cannot really defend from slowloris. I mean, you can defend by asking clients to send data faster and refuting connections that send data too slow, but when you do that, you are also legitimately denying actual slow clients.
FWIW, plug+cowboy already ships with reasonable defaults for this.
Well if the to slow time is a reasonable limit, then you may not block legitimate clients, but you will limit the amount of damage a slow loris attack can do. Off course the slow time limit will be different from application to application.
Are this settings we can configure?
BEAM (from the developer viewpoint) is preemptive scheduler (in reality it is cooperative, but you do not “see” that), so slow loris will not kill whole application as in Cowboy (and I believe most other HTTP server implementations in Erlang) you have process per connection/client, that mean that you cannot starve server. In theory you could run to the BEAM process limit, but I think that earlier your OS would ran out of amount of allowed opened ports. 4 years ago in testing single node was able to handle 2 million simultaneous connections and the ulimit was only reason why it couldn’t go further. So I would say that BEAM is safe against such attack.
In a DDOS with slow loris the BEAM will not be safe, just much more resilient then an Apache or Nginx server, because exhausting the ulimit will take much more time then reaching the open connection limit in traditional servers.
Nginx is also pretty safe from Slow Lorris and is limited in exactly the same way as BEAM - by number of allowed opened connections.
In my opinion limiting the number of open connections doesn’t seem the best way to defend against the slow loris attack. In my point of view the best way is to first limit how slow a request can be made by the client, but I don’t know if it is possible at all in the BEAM. I will keep searching…
Thanks for the link.
I found this article by @alvises that seems to shed some light in the settings that we can tweak:
From the version 1.4, Phoenix uses Cowboy 2 which has a new set of timeout options:
request_timeout( default 5_000 milliseconds ), *Time in ms with no requests before Cowboy closes the connection.- This is the maximum time, in which the client has to send the HTTP request. We do not touch this.
inactivity_timeout( default 300_000 milliseconds ), Time in ms with nothing received at all before Cowboy closes the connection .idle_timeout( default 60_000 milliseconds ), Time in ms with no data received before Cowboy closes the connection .
HAProxy is also worth a look:
After thinking more on the slow loris attack and have discussed it at work, we cannot really completely defend against it, just as Jose have mentioned, even by playing with the inactivity_timeout and idle_timeout, because the attacker will enumerate this values and never let his attack trigger them.
So we may try to make it harder to perform a slow loris attack by employing some traffic analysis and try to find patterns and start blocking them, but it will be always a cat and mouse game.
Yup, this is a much better way to put what I originally said as “Unfortunately you cannot really defend from slowloris.” 
© Copyright Elixir Forum | Terms | Privacy & Cookies
