How to best defend against a “slowloris” DOS attack against an Apache web server?

Question

Recently a script called "slowloris" has gained attention. The basic concept of what slowloris does is not a new attack but given the recent attention I have seen a small increase in attacks against some of our Apache websites.

At the moment there does not appear to be any 100% defence against this.

The best solution we have determined (so far) is to increase MaxClients.

This of course does nothing more than increase the requirements for the attacker's computer and does not actually protect the server 100%.

One other report indicates that using a reverse proxy (such as Perlbal) in front of the Apache server can help prevent the attack.

Using mod_evasive to limit the number of connections from one host and use mod_security to deny requests that look like they were issued by slowloris seem to be the best defence so far.

Has anyone on ServerFault been experiencing attacks such as this? If so, what measures did you implement to defend/prevent it?

NOTE: This question is for Apache servers as it is my understanding that Windows IIS servers are not affected.

Answer 1

I experienced such attack ... at middle of midsummer (23th of June), where you are supposed to be at countryside and drink beer :> I put my apache behind [http://varnish.projects.linpro.no/], which not only protected from slowloris, but also accelerated web requests quite a bit. also, iptables helped me :> iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 40 -j DROP It just limits one host to 20 connections to 80 port, which should not affect non-malicious user, but would render slowloris unusable from one host.

Answer 2

We have a working defense on a slowloris attack via botnet by using mod_qos (http://mod-qos.sourceforge.net/) online in production. Configuration:

## QoS Settings
# handles connections from up to 100000 different IPs
QS_ClientEntries 100000

# will allow only 50 connections per IP
QS_SrvMaxConnPerIP 50

# maximum number of active TCP connections is limited to 256
MaxClients              256 

# disables keep-alive when 70% of the TCP connections are occupied:
QS_SrvMaxConnClose      180

# minimum request/response speed (deny slow clients blocking the server):
QS_SrvMinDataRate       150 1200

# and limit request header and body:
LimitRequestFields      30
QS_LimitRequestBody     102400

All-though the attack is still lasting apache is serving normal (user/browser) requests at almost normal speed.

Answer 3

mod_antiloris, simple as that.

Answer 4

Looking at your mod_qos configuration, it seems that there is still the possibility for this attack to eat up connections. Here's why:

Only 256 clients are allowed. Each client can connect 50 times. Only 6 unique IPs are needed to bring down the server. If an attacker throttled the attack to 30 bytes per second and increased the request size to 102400 bytes, each connection can last a full 56 minutes.

An additional question: Does mod_qos kill all connections if the connection limit is breached? If not, this configuration does little to prevent an attack like Slowloris.

All someone needs to do is fire up a Slowloris variant, configure a moderate bandwidth and large request size, route it through TOR, and your mitigation with mod_qos has been completely circumvented.

Answer 5

If all your apache modules are thread safe, slowloris can be defeated simply by switching to event or worker MPMs. ref: here

Answer 6

Right now it seems that there's nothing more to do that limiting the max concurrent connexions per ip on the server.

Answer 7

There's a user patch you can try. It modifies the timeout based on the load the server is under, but considering its status, you might not want to use it on a production machine, without some serious testing. Take a look here.

Answer 8

iptable based firewall should protect you from multiple connections from 1 ip.

Answer 9

Kristaps: Does Varnish still work if you use the -httpready flag in SlowLoris? Most load balancers will hold on to requests until they are complete, but leave exception for POSTs because they can get very large. It would be interesting to see if Varnish does the same thing.

Answer 10

Cian,

Not exactly: link

"Once we set Slowloris to -timeout 10 -num 7000 the test site went up and down frequently."

In my own tests with the Slowloris style attack, the only mitigation that the Event MPM added was reducing CPU and memory strain on the server. Still, I was easily able to generate more connections than Apache could handle; I have yet to find a decent solution that mitigates the attack without sacrificing users with slow connections or enterprises behind NAT.

In addition to being experimental, the Event MPM does not support mod_ssl, and therefore is unacceptable to use in a production environment.

Answer 11

of course one can still attack a server despite these settings. I provide these here just as a starting point and as my result after mangling around with all mod_qos settings. I had to keep up an apache during a long lasting slowloris attack beeing performed from a botnet.

My first approach to work with mod_antiloris had the only effect that the number of "attackers" increased each of them taking 50 connections... so no help at all.

Together with a QS_SrvMinDataRate setting apache started to answer "normal" requests again. Of course that is nothing static and definitive not the only way but saved my weekend.

In fact the use of:

# disables keep-alive when 70% of the TCP connections are occupied:
QS_SrvMaxConnClose      180

kicks "unused" open connections.

@Pankaj: I'm sorry, but I don't have any experience with win-servers. My small howto to linux can be found here: http://www.howtoforge.com/node/4644

@Motoma: Do you get better results by using nginx for example? Just becouse I'd also like to test nginx...

Answer 12

Marcus,

I have yet to make a successful attack against a properly configured nginx server; however, I have been able to get PyLoris to use up over 1000 simultaneous connections from one computer by routing connections through TOR and changing identities periodically.

I do feel, however, that a combination of low timeouts, IP connection limits, minimum data transfer rates, maximum connection time limits, and maximum request sizes can provide adequate protection from this form of attack.

I say this all with the disclaimer that there is no way to prevent this form of attack, and that these configurations should be thought through thoroughly to gauge their impact on a per-server basis.

I would be happy to discuss my findings with you further. If you would like to contact me directly, my email address is my motoma at gmail.

Cheers,

Motoma