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 <[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 <[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 > > _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
