On Mon, Jun 22, 2009 at 9:07 PM, Graham
Dumpleton<graham.dumple...@gmail.com> wrote:
> 2009/6/23 Weibin Yao <nbubi...@gmail.com>:
>> William A. Rowe, Jr. at 2009-6-23 2:00 wrote:
>>> Andreas Krennmair wrote:
>>>> * Guenter Knauf <fua...@apache.org> [2009-06-22 04:30]:
>>>>> wouldnt limiting the number of simultanous connections from one IP
>>>>> already help? F.e. something like:
>>>>> http://gpl.net.ua/modipcount/downloads.html
>>>> Not only would this be futile against the Slowloris attack (imagine n
>>>> connections from n hosts instead of n connections from 1 host), it would
>>>> also potentially lock out groups of people behind the same NAT gateway.
>>> FWIW mod_remoteip can be used to partially mitigate the weakness of this
>>> class of solutions.
>>> However, it only works for known, trusted proxies, and can only be safely
>>> used for those with public IP's.  Where the same on your private
>>> NAT backed becomes the same within the apache server's DMZ, the
>>> issues like Allow from become painfully obvious.  I haven't
>>> found a good solution, but mod_remoteip still needs one, eventually.
>> I have an idea to mitigate the problem: put the Nginx as a reverse proxy
>> server in the front of apache.
> Although your comment is perhaps heresy here, it does highlight one of
> the things that nginx is good at, even if you don't use it to serve
> static files with Apache handling just the dynamic web application.
> That is, that it can isolate Apache from slow clients, whether that be
> an attack as in this case, or just normal users using slow networks.
> The proxy module of nginx in the way it will buffer up request content
> to disk before actually sending the request onto the backend also
> helps by not tying up Apache's limited request handler threads until
> the request content is completely available, although, nginx does have
> an upper limit on this at some point and will still stream when the
> post content is large enough.
> The nginx server works better at avoiding problems with slow clients
> because it is event driven rather than threaded and so can handle more
> connections without needing to tie up expensive threads.
> Unfortunately, trying to make socket accept handling in Apache be
> event driven and for requests to only be handed off to a thread for
> processing when ready can introduce its own problems. This is because
> an event driven system can tend to greedily accept new socket
> connections. In a multiprocess server configuration this can mean that
> a single process may accept more than its fair share of socket
> connections and by the time it has read the initial request headers,
> may not have enough available threads to handle the requests. In the
> mean time, another server process, which did not get in quick enough
> to accept some of the connections could be sitting their idle. How you
> mediate between multiple servers to avoid this sort of problem would
> be tricky if it can be done.
> Anyway, now for a hair brained suggestion that could bring some of
> this nginx goodness to Apache. Although no doubt it would have various
> limitations which to solve properly and be integrated seamlessly into
> Apache would require some changes in the core.
> The idea here is to have an Apache module which spawns off its own
> child process which implements a very small lightweight event driven
> proxy that listens on the real listener sockets you want to expose.
> This processes sole job would then be to handle reading in the request
> headers, and perhaps optionally buffering up request content, and then
> squirt it across to real Apache child server processes to be handled
> when it has all the information it needs. To that end, it wouldn't be
> a general purpose proxy but quite customised. As such, it could even
> perhaps be made more efficient than nginx in the way it is used to
> protect Apache from such things as slow clients.
> For HTTP at least, this probably wouldn't be too hard to do and
> wouldn't likely need any changes to the core. You could even have
> whether you use it be optional to the extent of it only applying to
> certain virtual hosts. Where it does though all get a lot harder is
> virtual hosts which use HTTPS.
> So, that is my crazy thought for the day and am sure that it will be
> derided for what is is worth.

Yes, I think the idea is a little crazy, we just need to fix the input
filters, encourage the use of the event mpm, along with FastCGI as a
connector.... then most of these problems go away :(

Reply via email to