httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: svn commit: r916932 - /httpd/httpd/branches/2.2.x/STATUS
Date Sun, 28 Feb 2010 10:19:21 GMT
Hi Gregg,

On Sat, 27 Feb 2010, Gregg L. Smith wrote:
> May I request this be added to
> http://people.apache.org/~sf/mod_reqtimeout.2.2-windows-build.patch

Thanks. Commited to trunk as r917153 and added to the proposal in 
2.2.x/STATUS (people.apache.org seems to be down ATM).

> Since I have your ear I have a dumb question, could at least the first part 
> of this (header timeout) be considered a possible mitigation to slowloris?

All of it is intended to be mitigation against slowloris. Slowloris can 
trivially be changed to use request bodies instead of headers.

> Also, looking at the doc, I take it there is no default setting?

Correct, and I think this makes sense for 2.2.x. If mod_reqtimeout turns 
out to be stable, we could however add something to the default config 
file. For 2.4, there was the idea to move the functionality into the core. 
Then we could maybe also set some default values in httpd itself.

BTW, the move to the core, or at least some change to the core, is also 
necessary to remove one limitation: The request line for (non-ssl) http 
requests is read by a single call to apr_brigade_split_line(). At this 
point, mod_reqtimeout has no way to enforce the total time limit for 
reading the request. However, the socket timeout will be set to the 
initial value set be mod_reqtimeout. This should be much lower (e.g. 5s) 
than the normal TimeOut value (usually 300s). Therefore, with 
mod_reqtimeout an attack is much more difficult than without.

Cheers,
Stefan

Mime
View raw message