|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Pattern matching odd HTTP request
Noah([email protected])@2001.09.20 10:36:17 +0000: > On Thu, 20 Sep 2001, Bill McGonigle wrote: > > > > > Thanks for all your work on this one, Karsten, and I hope you had a good > > nap. :) > > > > mod_throttle looks like it will stop a DOS from one client effectively, > > though the configuration is a bit complex for just that use of it. I > > plan to implement it for that. It doesn't appear to be useful though > > for the type of DDOS that seems to be brewing (which I hope fizzles and > > dies). > > I haven't tried it myself (yet... it's on the plate), but mod_tsunami > (http://bert.tuxfamily.org/mod_tsunami/) may work better. It limits the > number of connections on a per-directory basis, using the apache > scoreboard. The primary issue I had with mod_throttle when I was looking > at it (a few months back) was that it was fairly CPU intensive. This may > or may not be an issue depending on how much traffic you push on a > "normal" day (whatever that is). ALL modules that use directory/location base config for resource limiting won't work, because they start processing the reuqets after the request is in. to be more verbose: 1 client connects to server 2 when socket is connected, client send http headers (accept/host/...) 3 client issues a request (see rfc2616 for that) like GET / HTTP/1.1 followed by two carriage returns 4 server starts processing the request (filtering headers and uri information through the stack of configured modules) richt after step 2, there is no per-directory/per-location handler trigger, since the request has not yest triggered the corresponding handler because it was not issued by the client. the malicious client would just open a lot of sockets and wait. mod_throttle is the only implementation that could process those connections because it has an additional 'fixup' handler that gets called _before_ request processing has begun. the ideal location for some logic limiting incoming dead connections is in the core itself, because the api is somewhat limited in what you can do before the request processing an a module. i hope this shed a little light on the issue. take care, /k -- > Q: What do you get when you cross Dracula with a used car dealer? > A: autoexec.bat KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [email protected] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x Attachment:
pgp00019.pgp
|