Re: Mitigating the Slowloris DoS attack
* Joe Orton [2009-06-24 11:20]: Meh. There will always be a maximum to the number of concurrent connections a server can handle - be that hardware, kernel, or server design. If you allow a single client to establish that number of connections it will deny service to other clients. That is all that "slowloris" does, and you will always have to mitigate that kind of attack at network/router/firewall level. It can be done today on Linux with a single trivial iptables rule, I'm sure the same is true of other kernels. I think you confuse the PoC tool with the fundamental problem. You can't fend off this kind of attack at TCP level, at least not in cases where the n connections that block Apache are made by not 1 but n hosts. Regards, Andreas
Re: Mitigating the Slowloris DoS attack
* Guenter Knauf [2009-06-22 04:30]: wouldnt limiting the number of simultanous connections from one IP already help? F.e. something like: http://gpl.net.ua/modipcount/downloads.html Not only would this be futile against the Slowloris attack (imagine n connections from n hosts instead of n connections from 1 host), it would also potentially lock out groups of people behind the same NAT gateway. Regards, Andreas
Mitigating the Slowloris DoS attack
Hello everyone, Previously, I had contacted the Apache Security Team about a possible mitigation of the Slowloris DoS attack. I was referred to this mailing list to discuss non-private security issues. For those who are still unaware of the Slowloris attack, it's a denial-of-service attack that consumes Apache's resources by opening up a great number of parallel connections and slowly sending partial requests, never completing them. Since Apache limits the number of parallel clients it serves (the MaxClients setting), this blocks further requests from being completed. Unlike other "traditional" TCP DoS attacks, this HTTP-based DoS attack requires only very little network traffic in order to be effective. Information about the Slowloris attack including a PoC tool was published here: http://ha.ckers.org/slowloris/ I thought for some time about the whole issue, and then I developed a proof-of-concept patch for Apache 2.2.11 (currently only touches the prefork MPM), which you can download here: http://synflood.at/tmp/anti-slowloris.diff The basic principle is that the timeout for new connections is adjusted according to the current load on the Apache instance: a load percentage is computed in the perform_idle_server_maintenance() routine and made available through the global scoreboard. Whenever the timeout is set, the current load percentage is taken into account. The result is that slowly sending connections are dropped due to a timeout, while legitimate, fast-sending connections are still being served. While this approach doesn't completely fix the issue, it mitigates the negative impact of the Slowloris attack. Even under heavy load, legitimate requests are still being served, even though it - in my tests - in took a bit longer than usual. And the kind of heavy load that I needed to slow down Apache was already quite traffic-intensive, i.e. it defeated one of Slowloris' goals, namely having a low "traffic footprint" that would make the attack hard to detect. Please be aware that the patch mentioned above is of proof-of-concept quality: the numbers in the adjust_timeout() function were chosen more or less arbitrarily, just tuned well enough to successfully mitigate the impact of a Slowloris attack in my testing environment. Regards, Andreas
htpasswd salt generation weakness in MD5 mode
Hello,
I noticed a salt generation weakness when using htpasswd in MD5 mode on
platforms where rand() returns only a 32 bit value: since the MD5 salt
is 48 bits wide, the last 2 or 3 characters are always filled with '.'.
$ htpasswd -m -c /tmp/htpasswdtest a
New password:
Re-type new password:
Adding password for user a
$ cat /tmp/htpasswdtest
a:$apr1$sTQf/...$v6RZCfMprmLq5vMTzpwH2/
$
IMHO, this should not be, and therefore I propose the following fix:
--- htpasswd.c~ 2004-09-26 20:01:11.927886608 +0200
+++ htpasswd.c 2004-09-26 20:05:04.213573816 +0200
@@ -112,6 +112,18 @@
}
}
+static void generate_salt(char *s, size_t size)
+{
+ static unsigned char tbl[] =
+"./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
+size_t i;
+for (i = 0; i < size; ++i) {
+int idx = (int) (64.0 * rand() / (RAND_MAX + 1.0));
+s[i] = tbl[idx];
+ }
+}
+
+
static void putline(apr_file_t *f, const char *l)
{
apr_file_puts(l, f);
@@ -160,7 +172,7 @@
case ALG_APMD5:
(void) srand((int) time((time_t *) NULL));
-to64(&salt[0], rand(), 8);
+generate_salt(&salt[0], 8);
salt[8] = '\0';
apr_md5_encode((const char *)pw, (const char *)salt,
This above patch would lead to a more random MD5 salt:
$ ./htpasswd -m -c /tmp/htpasswdtest2 b
New password:
Re-type new password:
Adding password for user b
$ cat /tmp/htpasswdtest2
b:$apr1$iOJN8Jax$rQLDvG0ALByOBtHgN2wk7/
$
Regards,
Andreas Krennmair
