Re: Phase for controlling network input?
On Wednesday, September 26, 2001, at 11:58 , Simon Rosenthal wrote: > I'm not sure that any mod_perl handlers are dispatched until the whole > request is received, so you may have to deal with this at the core > Apache level. I was expecting as much, just hoping it wasn't true. ;) > > I think the following is your best bet (from > http://httpd.apache.org/docs/mod/core.html#timeout ) > >> TimeOut directive Yeah, the trick is I need to do a per-IP rule and not take out high-latency users. > We've experienced this kind of attack inadvertently (as the result of > a totally misconfigured HTTP client app which froze in the middle of > sending an HTTP request ;=) but I wasn't aware that there were known > attacks based on that. Known as in experienced in the wild, no, but folks on nanog are talking about strange log file entries. For instance I see blocks of 408's at very very regular intervals from the same clients, of unknown origin. I wrote a proof-of-concept exploit that takes out my (stock config) Apache server for 6 minutes (from one client), and the math says that 30-or-so machines in a DDOS would tie up my Apache indefinitely no matter how I configured it (anything that would reasonably allow normal users to connect successfully). I got a higher hit frequency from nimda than that, so everything is in place for it to happen. I'm attempting the ounce of prevention. I wrote to the apache security list about it, with a proposed fix, but have received no response, so I'm investigating doing it myself. I don't think I know apache internals well enough, though I'm not bad with mod_perl. If anyone good with apache c is interested I'm happy to share full details off-list. -Bill - Bill McGonigle Research & Development Medical Media Systems, Inc. http://www.medicalmedia.com +1.603.298.5509x329
Re: Phase for controlling network input?
I'm not sure that any mod_perl handlers are dispatched until the whole request is received, so you may have to deal with this at the core Apache level. I think the following is your best bet (from http://httpd.apache.org/docs/mod/core.html#timeout ) >TimeOut directive > >Syntax: TimeOut number >Default: TimeOut 300 >Context: server config >Status: core > >The TimeOut directive currently defines the amount of time Apache will >wait for three things: > >1.The total amount of time it takes to receive a GET request. >2.The amount of time between receipt of TCP packets on a POST or PUT > request. >3.The amount of time between ACKs on transmissions of TCP packets in > responses. > >We plan on making these separately configurable at some point down the >road. The timer used to default to 1200 before 1.2, but has been lowered >to 300 which is still far more than necessary in most situations. It is >not set any lower by default because there may still be odd places in the code >where the timer is not reset when a packet is sent. We've experienced this kind of attack inadvertently (as the result of a totally misconfigured HTTP client app which froze in the middle of sending an HTTP request ;=) but I wasn't aware that there were known attacks based on that. -Simon At 11:09 AM 9/26/2001, Bill McGonigle wrote: >I'm hoping this is possible with mod_perl, since I'm already familiar with >it and fairly allergic to c, but can't seem to figure out the right phase. > >I've been seeing log files recently that point to a certain DDOS attack >brewing on apache servers. I want to write a module that keeps a timer >for the interval from when the apache child gets a network connection to >when the client request has been sent. > >I need a trigger when a network connection is established and a trigger >when apache thinks it has received the request (before the response). > >PerlChildInitHandler seems too early, since the child may be a pre-forked >child without a connection. PerlPostReadRequest seems too late since I >can't be guaranteed of being called if the request isn't complete, which >is the problem I'm trying to solve. I could clear a flag in >PerlPostReadRequest, but that would imply something is persisting from >before that would be able to read the flag. > >Maybe I'm think about this all wrong. Any suggestions? > >Thanks, >-Bill - Simon Rosenthal ([EMAIL PROTECTED]) Web Systems Architect Northern Light Technology One Athenaeum Street. Suite 1700, Cambridge, MA 02142 Phone: (617)621-5296: URL: http://www.northernlight.com "Northern Light - Just what you've been searching for"
Phase for controlling network input?
I'm hoping this is possible with mod_perl, since I'm already familiar with it and fairly allergic to c, but can't seem to figure out the right phase. I've been seeing log files recently that point to a certain DDOS attack brewing on apache servers. I want to write a module that keeps a timer for the interval from when the apache child gets a network connection to when the client request has been sent. I need a trigger when a network connection is established and a trigger when apache thinks it has received the request (before the response). PerlChildInitHandler seems too early, since the child may be a pre-forked child without a connection. PerlPostReadRequest seems too late since I can't be guaranteed of being called if the request isn't complete, which is the problem I'm trying to solve. I could clear a flag in PerlPostReadRequest, but that would imply something is persisting from before that would be able to read the flag. Maybe I'm think about this all wrong. Any suggestions? Thanks, -Bill
