English | 
DeutschHow To Defend slowloris DDoS With mod_qos (Apache2 On Debian [Lenny])
Want to support HowtoForge? Become a subscriber!
|
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]](http://creativecommons.org/images/public/somerights20.gif "Creative Commons Attribution License")
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Recent comments
16 hours 8 min ago
16 hours 13 min ago
21 hours 12 min ago
1 day 3 hours ago
1 day 4 hours ago
1 day 5 hours ago
1 day 10 hours ago
1 day 16 hours ago
1 day 20 hours ago
1 day 22 hours ago