3 ms·
Original paper: http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf (well, slide deck) § Summary ➊ The slowlor
by jws 16y ago
Original paper: http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf (well, slide deck)
§ Summary
➊ The slowloris attacks of last year consumed all of a host's available HTTP server connections with minimal bandwidth by trickling out HTTP headers forever at a slow pace. Countermeasures were developed and applied.
➋ This exploit consumes connections similarly, but does so by trickling out data in the content section of a POST request. Countermeasures targeting slowloris are ineffective.
➌ Countermeasures for this will include HTTP request timeouts, but to support distant users operating over potentially saturated links you will have to set the timeout high enough that any well connected attacker will still be able to kill your server. (That has some extrapolation from me.)
§ Discussion
The real solution will be to not consume a process or other expensive resource until the entire POST request has been received by the server. (Expand to PUT and any other method with content in the request.)
This becomes difficult in HTTP/1.1. To really support 1.1 you have to give the request the option to reject before the content is sent. (Yes you other old farts, the client doesn't necessarily blindly send the content, but waits for your server to say "ok, the method, resource, and headers look good, send me the content".) I suppose you could force all those decisions to be made by the HTTP server, but that would be sad.
- moe 16y agoTo really support 1.1 you have to give the request the option to reject before the content is sent. This is actually already specified, at least for PUT (see 100-continue).
- pyre 16y agoThis seems easy to defend against for sites that don't accept a lot of POST data. You could set a really low threshold for content-length. You could maybe even get fancy and only allow large POST data on certain URLs (e.g. low POST content-length threshold on www.example.com, but a higher threshold on admin.example.com; assuming that you can reject the connection as unauthenticated before receiving the data).
- andrewmccall 16y agoThis makes perfect sense. If for example you're accepting 140 characters there is no reason you should have an excessive content-length for that URL.