This article applies to:
Question:
- How can I address false positives?
- How do I set up exception handling?
Procedure:
There are many methods of implementing Exception Handling in ModSecurity to address false positive alerts. This article outlines an approach which will conditionally disable a problematic rule ID (based on the URL) by using the ctl:ruleRemoveById action.
For example, consider the following ModSecurity alert message (formatted for readability):
[Sun Jun 30 13:45:43 2013] [error] [client 192.168.11.143] ModSecurity: Access denied with code 403
(phase 2). Pattern match "(^[\"'\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98;]+|[\\"'\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+$)" at ARGS:DocCopyList.
[file "/etc/modsecurity/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "66"] [id "981318"] [rev "2"]
[msg "SQL Injection Attack: Common Injection Testing Detected"]
[data "Matched Data: \xb4 found within ARGS:DocCopyList: \xd9\x8a\xd8\xb4\xd9\x8a\xd8\xb4\xd8\xb3\xd9\x8a\xd8\xb4"]
[severity "CRITICAL"] [ver "OWASP_CRS/2.2.7"] [maturity "9"] [accuracy "8"]
[tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]
[tag "WASCTC/WASC-19"]
[tag "OWASP_TOP_10/A1"]
[tag "OWASP_AppSensor/CIE1"]
[tag "PCI/6.5.2"]
[hostname "192.168.11.60"]
[uri "/DMS-V2/doc_out/doc_out_new.php"]
[unique_id "UdAMV8CoCzwAAHRHMhYAAAAB"]
If rule ID 981318 is causing many issues on the /DMS-V2/doc_out/doc_out_new.php page, you can add the following new rule to a modsecurity_crs_00_custom.conf file:
SecRule REQUEST_FILENAME "@streq /DMS-V2/doc_out/doc_out_new.php" "id:1,phase:1,t:none,nolog,pass,ctl:ruleRemoveById=981318"
This rule would conditionally disable rule ID 981318 for the current transaction if the client was requesting that webpage.
Make sure that the modsecurity_crs_00_custom.conf file is activated in the web server configurations so that it is called up BEFORE the normal ModSecurity rules.
Notes:
For general information about ModSecurity see the Reference Manual (one source for this manual is in the Related Links section below).