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
