- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 20 Jun 2011 23:19:11 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Jan Starke <jan.starke@outofbed.org>, ietf-http-wg@w3.org
On Mon, Jun 20, 2011 at 05:03:32PM +0000, Poul-Henning Kamp wrote: > In message <20110620163813.GA12762@1wt.eu>, Willy Tarreau writes: > > >I would add that the *first* protection obviously is to have the > >server correctly implement timeouts, because if it is sensible to > >this attack, it's also sensible to simple client failure. > > There is no possible timeout value which will both serve slow clients > in bad connectivity (iPhone4 ?) and prevent DoS attacks. Yes in practice you can because even with bad connectivity you're generally interested by covering holes as large as 30-60 seconds, not much more. After that, many other stateful components between the client and the server will have cut the connection anyway. For instance, most haproxy setups use between 20 and 30 seconds and don't report any particular issue. Those using larger values generally try to cover long application response times and make use of the same timeout for all values to keep their configs simple. And with a 30 seconds timeout, even if you're able to send 1000 connections per second, which is quite not possible with a simple xDSL line, that's still only 30k concurrent connections, which is quite small to medium for todays gateways. Clearly I'm not speaking about DDoSes here, botnets have virtually unlimited bandwidth, and they don't care about doing anything smart such as trying to fool your content-length. I'm just talking about the "easy DoS" that any joe user might ignite from his own access. Slowloris typically was such one. A variant can be made to work with POST requests by sending one byte at a time before the idle timeout strikes, unless the server supports a total transfer timeout too. Cheers, Willy
Received on Monday, 20 June 2011 21:22:05 UTC