How To Defend slowloris DDoS With mod_qos (Apache2 On Debian [Lenny])
|
Submitted by MarcusSpiegel (Contact Author) (Forums) on Wed, 2009-07-15 19:06. :: Debian | Linux | Linux | Apache | Apache | Security | Security
How To Defend slowloris DDoS With mod_qos (Apache2 On Debian [Lenny])From the Slowloris description:
I recently had to defend a live attack with slowloris-dos from a botnet. The load-impact is very low but http quits serving very fast. A quick approach was to mangle with timeout settings, wich is fine to defend a single attacker but leads into new issues (ie. large NAT on client-side). mod_qos gives some fine-grained opportunities to scale the number of used connections and to defend an attack according to bandwidth limits. Unfortunately it is only available as source-package and there are many possible settings, wich might be hard to setup for this special case. So I provide the way that helped me.
1. Get the source, build & installmod_qos is available from sourceforge (http://sourceforge.net/projects/mod-qos/). You will find documentation here http://mod-qos.sourceforge.net/. cd /tmp/ You might want to copy & paste the direct link from sourceforge. As we want to compile mod_qos by use of apxs, we need to install the appropriate dev package and gcc of course, ie: apt-get install apache2-threaded-dev gcc Now build & install cd mod_qos-8.13/apache2/ If everything worked fine you'll get something like this: ----------------------------------------------------------------------
2. Now configure and activateGo to /etc/apache2/mods-available and add a qos.load and qos.conf file cd /etc/apache2/mods-available/ LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so vi qos.conf ## QoS Settings
<IfModule mod_qos.c>
# 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, ie. slowloris keeping connections open without requesting anything):
QS_SrvMinDataRate 150 1200
# and limit request header and body (carefull, that limits uploads and post requests too):
# LimitRequestFields 30
# QS_LimitRequestBody 102400
</IfModule>
Now you need to enable the module and restart apache: a2enmod qos If you are able to get the server-status by https://__yourserver__/server-status, you'll find mod_qos enabled and working by giving a statistical summary, like this: mod_qos 8.13
3. before & afterOn top of the server-status page you can see a summary of all apache workers. To see what happens before and whilst the attack, I used a local environment. So the results here show the basic principle not the real world example. Let's assume a normal server-load like this: 1 requests currently being processed, 5 idle workers While attacking this server with one single machine results to all workers being occupied: 102 requests currently being processed, 0 idle workers As you can see the attack took all available threads of the apache server wich itself stays in state "R" (Keepalive (read)). A normal apache will wait for 300 seconds to close such a connection and as the attacker doesn't send any real request and just keeps all open connections, No other requests will be served anymore. Now with the QoS-Module enabled, things look different. Although apache starts the maximum number auf child-workers, it is still able to serve "real-people-requests": 1 requests currently being processed, 97 idle workers We configured apache with mod_qos to handle a limited number of connections per IP and to prefer serving "fast" requests. The attack just opens a connection without sending a real http-reqeuest (like GET /index.html HTTP 1.1). So apache now classifies that as a "slow" request as it has to wait very long to get a request/response from the attacker. A real request sends the "GET" much faster together with additional http-headers. So in case that all workers are occupied by an attack whilst receiving a real request, apache just drops a stale connection and handles the new "serious" request at almost normal speed. On a real world server you will get pictures like these (reload... reload... reload): 166 requests currently being processed, 0 idle workers 97 requests currently being processed, 59 idle workers 51 requests currently being processed, 92 idle workers 126 requests currently being processed, 0 idle workers
4. Links, etc.I provide this howto as one possible way to solve this particular issue. There might be more ways (and hopefully will be), like using a proxy, loadbalancer, level-7-firewall, etc. In my case, we had to find a quick solution that is up and running in minutes. For further reading you might find these links helpful:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||



![Creative Commons Attribution License [Creative Commons Attribution License]](http://creativecommons.org/images/public/somerights20.gif)




Recent comments
11 hours 44 min ago
13 hours 45 min ago
16 hours 56 min ago
19 hours 15 min ago
20 hours 26 min ago
21 hours 44 min ago
1 day 1 hour ago
1 day 5 hours ago
1 day 5 hours ago
1 day 20 hours ago