We're using an Apache 2.2.17 that was built from scratch on a Solaris box. On Sat, Apr 16, 2011 at 9:44 AM, Ryan Barnett <[email protected]>wrote:
> What apache version are you using? > > On Apr 16, 2011, at 9:43 AM, "Guillaume Bilodeau" < > [email protected]<mailto:[email protected]>> wrote: > > A little more information on the 200 return code: > > It seems that mod_reqtimeout is not closing the connection after the 20 > seconds, but rather truncating the request and letting it go through. So > the request is actually processed, and since the URL is referring to an > actual resource, a 200 code is returned. > > Surely there must be a problem with our configuration? Or maybe our Apache > build? > > Cheers, > GB > > On Sat, Apr 16, 2011 at 12:55 AM, Brian Rectanus <<mailto: > [email protected]>[email protected]<mailto:[email protected]>> wrote: > Probably not "disastrous" :) You have the overhead of the TCP 3-way > handshake and also the shutdown, but the browsers should be using SSL > session resumption, which is not connection based. It uses cached SSL > session IDs and should be reused on each connection up to the timeout > - just make sure this is enabled in the Apache config. Personally, I > find that about 3 second timeouts w/low request limit works well for > keepalives, so it may be enough to just limit the keepalive timeout > and number of requests (say 3 second timeout w/9 requests limit > instead of completely disabling them). It really depends on your > latency requirements for your site. > > -B > > On Thu, Apr 14, 2011 at 2:37 PM, Guillaume Bilodeau > <<mailto:[email protected]>[email protected]<mailto: > [email protected]>> wrote: > > We will try turning off connection keep-alive to see how Apache will > react. > > However, isn't turning this off going to have a disastrous impact on > > connection performance, especially since all traffic will be SSL? > > > > On Thu, Apr 14, 2011 at 3:19 PM, Ivan Ristic <<mailto: > [email protected]>[email protected]<mailto:[email protected]>> > wrote: > >> > >> Yes, it's probably because of keep-alives. Sounds like a bug in the > >> reqtimeout module, because, if the connection stays open, the module > >> isn't achieving much. > >> > >> IIRC, ModSecurity will turn off keep-alives on a connection on which it > >> blocks. > >> > >> > >> On Thu, Apr 14, 2011 at 8:11 PM, Guillaume Bilodeau > >> <<mailto:[email protected]>[email protected] > <mailto:[email protected]>> wrote: > >> > Hi Ryan, > >> > We installed WireShark and started sniffing on all traffic. It seems > >> > that > >> > Apache is returning a 200 status code instead of a 408 when the > request > >> > reaches 30 seconds, so from what I understand ModSecurity can't do > much > >> > about that. The funny thing is, if we follow one of the TCP streams, > we > >> > see > >> > that http_dos_cli keeps sending data even after receiving the 200 > code. > >> > Maybe something to do with keep-alive connections? > >> > Cheers, > >> > GB > >> > On Thu, Apr 14, 2011 at 2:12 PM, Ryan Barnett <<mailto: > [email protected]>[email protected]<mailto: > [email protected]>> > >> > wrote: > >> >> > >> >> OK, if mod_reqtimeout is installed and that directive is working, > then > >> >> after 30 sec if Apache has not received the entire request body then > it > >> >> should terminate the request with a 408 status code. The ModSecurity > >> >> CRS > >> >> rules are simply monitoring if/how many 408 alerts are generated by > >> >> Apache > >> >> per client. After a certain amount, then ModSecurity will step in on > >> >> subsequent requests in phase:1 and do drop actions. > >> >> > >> >> So, by monitoring your Apache error log while you are running your > >> >> http_dos_cli tool, does Apache generate 408 alerts after 30 secs? If > >> >> not, > >> >> then I don't think that the mod_reqtimeout module or directive is > >> >> working. > >> >> > >> >> -Ryan > >> >> > >> >> > >> >> From: Guillaume Bilodeau > >> >> <<mailto:[email protected]>[email protected] > <mailto:[email protected]><mailto:<mailto: > [email protected]>[email protected]<mailto: > [email protected]>>> > >> >> Date: Thu, 14 Apr 2011 13:07:41 -0500 > >> >> To: Ryan Barnett > >> >> <<mailto:[email protected]>[email protected]<mailto: > [email protected]><mailto:<mailto:[email protected]> > [email protected]<mailto:[email protected]>>> > >> >> Cc: > >> >> > >> >> "<mailto:[email protected]> > [email protected]<mailto: > [email protected]><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]>>" > >> >> > >> >> <<mailto:[email protected]> > [email protected]<mailto: > [email protected]><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]>>> > >> >> Subject: Re: [Owasp-modsecurity-core-rule-set] Slow HTTP DOS > protection > >> >> not behaving as expected > >> >> > >> >> Hi Ryan, > >> >> > >> >> I'm no Apache expert, but AFAICT the req_timeout module is installed. > >> >> A > >> >> /server-info shows the req_timeout.c module with the > RequestReadTimeout > >> >> parameter. > >> >> > >> >> Thanks, > >> >> GB > >> >> > >> >> On Thu, Apr 14, 2011 at 1:56 PM, Ryan Barnett > >> >> <<mailto:[email protected]>[email protected]<mailto: > [email protected]><mailto:<mailto:[email protected]> > [email protected]<mailto:[email protected]>>> wrote: > >> >> Did you install the reqtimeout module? > >> >> > >> >> # > >> >> # Mitigate Slow HTTP POST attacks > >> >> # > >> >> # Must have the mod_reqtimeout module installed > >> >> # You should adjust the RequestReadTimeout body directive setting to > a > >> >> limit > >> >> # that will allow any legitimate slow clients or large file uplaods. > >> >> # > >> >> <IfModule reqtimeout_module> > >> >> RequestReadTimeout body=30 > >> >> </IfModule> > >> >> > >> >> -Ryan > >> >> > >> >> > >> >> > >> >> From: Guillaume Bilodeau > >> >> > >> >> <<mailto:[email protected]>[email protected] > <mailto:[email protected]><mailto:<mailto: > [email protected]>[email protected]<mailto: > [email protected]>><mailto:<mailto:[email protected] > >[email protected]<mailto:[email protected]><mailto: > <mailto:[email protected]>[email protected]<mailto: > [email protected]>>>> > >> >> Date: Thu, 14 Apr 2011 12:33:52 -0500 > >> >> To: > >> >> > >> >> "<mailto:[email protected]> > [email protected]<mailto: > [email protected]><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]>><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]>>>" > >> >> > >> >> <<mailto:[email protected]> > [email protected]<mailto: > [email protected]><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]>><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]><mailto:<mailto: > [email protected]> > [email protected]<mailto: > [email protected]>>>> > >> >> Subject: [Owasp-modsecurity-core-rule-set] Slow HTTP DOS protection > not > >> >> behaving as expected > >> >> > >> >> Hi all, > >> >> > >> >> We are trying to setup the OWASP Core Rule Set to protect our > >> >> application > >> >> from Slow HTTP DOS attacks. > >> >> > >> >> We have setup ModSecurity 2.5.13 on our Apache 2.2.17 instance, > loaded > >> >> the > >> >> module, and included all CRS base rules plus > >> >> modsecurity_crs_11_slow_dos_protection.conf. We didn't change the > >> >> settings > >> >> defined in the conf file, so SecReadStateLimit is set to 5 and > >> >> RequestReadTimeout is set to body=30. We are using the http_dos_cli > >> >> command > >> >> line tool to do our tests, with the connection parameter set to 500. > >> >> > >> >> When running the slow-headers test, ModSecurity seems to be > protecting > >> >> the > >> >> application correctly, dropping most (all?) requests from the > tester's > >> >> IP > >> >> and allowing requests from a different IP to be served. However, > when > >> >> running the slow-post test, ModSecurity doesn't seem to be doing > >> >> anything. > >> >> From what I understand, the test successfully creates the 500 > >> >> connections > >> >> and keeps them open; none of them are dropped. Requests coming from > a > >> >> different IP are not served and eventually time out. A tail -f > >> >> error_log > >> >> shows nothing except the eventual message on MaxClients (set to 300 > >> >> now) > >> >> being reached. Interestingly, when we kill the http_dos_cli process, > >> >> the > >> >> error_log is then flooded with hundreds of entries such as this: > >> >> > >> >> > >> >> [Mon Nov 22 17:44:46 2010] [warn] ModSecurity: Access denied with > code > >> >> 400. > >> >> Too many connections [6] of 5 allowed in READ state from > 211.144.112.20 > >> >> - > >> >> Possible DoS Consumption Attack [Rejected] > >> >> > >> >> (this has been taken from the SpiderLabs blog entry, dates and IPs > are > >> >> obviously different) > >> >> > >> >> Any idea on why this isn't behaving like we're expecting it to be? > >> >> > >> >> Thanks! > >> >> GB > >> >> > >> >> > >> >> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Owasp-modsecurity-core-rule-set mailing list > >> > <mailto:[email protected]> > [email protected]<mailto: > [email protected]> > >> > < > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > >> > > >> > > >> > >> > >> > >> -- > >> Ivan Ristić > > > > > > _______________________________________________ > > Owasp-modsecurity-core-rule-set mailing list > > <mailto:[email protected]> > [email protected]<mailto: > [email protected]> > > < > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > > > > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > [email protected]<mailto: > [email protected]> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > ________________________________ > This transmission may contain information that is privileged, confidential, > and/or exempt from disclosure under applicable law. If you are not the > intended recipient, you are hereby notified that any disclosure, copying, > distribution, or use of the information contained herein (including any > reliance thereon) is STRICTLY PROHIBITED. If you received this transmission > in error, please immediately contact the sender and destroy the material in > its entirety, whether in electronic or hard copy format. >
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
