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 <[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 <[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 >> <[email protected]<mailto:[email protected]>> >> Date: Thu, 14 Apr 2011 13:07:41 -0500 >> To: Ryan Barnett <[email protected]<mailto:[email protected]>> >> Cc: >> "[email protected]<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 >> <[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 >> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> Date: Thu, 14 Apr 2011 12:33:52 -0500 >> To: >> "[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>" >> <[email protected]<mailto:[email protected]><mailto:[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 > [email protected] > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > -- Ivan Ristić _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
