- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 20 Jun 2011 18:38:13 +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 04:21:55PM +0000, Poul-Henning Kamp wrote: > In message <BANLkTik1rT_Z69xE7YenpB9GPbbxFmKLfg@mail.gmail.com>, Jan Starke wri > tes: > > >A possible mitigation would be to require SSL or TLS, [...] > > Economically impossible at the bandwidths many sites run. > > >Another (not very mighty) mitigation could be to provide an > >intermediate layer between TCP and HTTP to handle meta information. > > This is what FreeBSD's "accept-filters" do. None of the presently > implemented filters catch this particular case though. Not really > sure it is a feasible way to deal with POST bodies though. > > >I have no idea how to really prevent this kind of attack, maybe > >someone in this mailing-list knows how... > > There is no way to prevent it, it is a direct consequence of the > protocols, at best you can mitigate it. > > The best mitigation is to have high-level detection software that > says "Funny, we've seen a lot of those, lets just summarily > close all unauthenticated POST attempts until they get bored" and > similar. > > The second best mitigation is to write your code to spend as few > resources as possible, until you can commit to the request. 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. Quite honnestly, I see nothing new here, it been abused for at least a decade by DDoSers and I'm not sure there are not that many servers which are *that* sensible. In fact, if the slowloris attack was playing on headers, it precisely is because playing on data us much less effective with servers, but the principle is the same (ie: maintain a server state for a long time). Regards, Willy
Received on Monday, 20 June 2011 16:38:45 UTC