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]>> Date: Thu, 14 Apr 2011 12:33:52 -0500 To: "[email protected]<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 [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
