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 10.0.0.5 on your private >>> NAT backed becomes the same 10.0.0.5 within the apache server's DMZ, the >>> issues like Allow from 10.0.0.0/8 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 :(
