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 <[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 > <[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
