There’s a bit of buzz around slowloris, which aims to take down webservers via resource starvation via a low-bandwidth DoS attack. It’s actually somewhat like a SYN flood, but it targets HTTP servers specifically, not TCP. Basically, it opens many HTTP connections and “stutters” requests, forcing the server to handle a number of concurrent requests. What’s interesting is that the apparent “defense,” limiting the maximum number of threads the webserver can have, actually makes the attack even easier: if you configure Apache to not serve more than 150 concurrent connections, an attacker just needs to get 150 concurrent connections and send data just slowly enough not to time out.

FreeBSD has accf_http (possibly sometimes known as HTTPReady?) that will “proxy” connections by buffering the request until the full one comes in. It doesn’t seem like it was meant for security per se, so much as to help cut down the load on webservers. As is pointed out elsewhere, accf_http doesn’t handle POST requests. Even though 95% (made-up stat) of new UNIX-ish server tools are aimed at Linux users, I sometimes feel like BSD gets all the really cool ones like accf_http and spamd and OpenBGPD and so on. We Linux people get good virtualization support, though. 🙂

IIS and lighttpd aren’t affected; squid, Apache, and a few I haven’t heard of are. Of note, squid is a proxy server, not a webserver, but it’s sometimes used as a “reverse proxy” in front of webservers. From its description, varnish seems as if it may be vulnerable, too. I’m curious about why IIS and lighttpd aren’t affected. lighttpd is meant to be super-fast and pretty small, so I wonder if it just doesn’t launch new threads to handle connections. I don’t know about IIS.

What seems to kill Apache is that it’s configured to start refusing incoming connections after a set limit (150 is a common default), which is meant to keep it from dying under heavy load. I have a hunch that removing this limit would make things worse, though, since you’d then be able to exhaust “real” resources (e.g., drive the machine into swap).

As a cheap, temporary hack, you can probably get creative with firewall rules and limit the number of concurrent connections any one IP can have open with you. This makes good sense to do anyway, but it won’t stop someone with access to many machines from doing this. Actually, at a glance, haproxy looks to buffer incoming connections. Might be interesting to let it sit in front of a single Apache box (which seemingly makes no sense: “load balancing” across one server?) and see how it performs.