When using ModSecurity the system will trigger any sort of exception, giving false positives in many kind of situations. This article enumerates those exceptions we have found useful in every day’s life.
All these rules must be put in a specific file:
vi /etc/httpd/modsecurity-crs/activated_rules/modsecurity_crs_48_local_exceptions.conf
Add the following lines:
#Avoid Google Analytics false positives: SecRuleUpdateTargetById 981172 !REQUEST_COOKIES:'/^__utm/' SecRuleUpdateTargetById 950901 !REQUEST_COOKIES:'/^__utm/' #Avoid 127.0.0.1 SecRule REMOTE_ADDR "^127.0.0.1$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999" #Request Missing an Accept Header - Allow for Google Reader SecRuleRemoveById 960015 #Avoid checks on some wordpress related posted arguments: SecRuleUpdateTargetById 981173 "!ARGS:_wp_http_referer" SecRuleUpdateTargetById 981173 "!ARGS:_wp_original_http_referer" SecRuleUpdateTargetById 981173 "!ARGS:referredby" #Avoid special encoding chars false positives SecRuleRemoveById 960024
Another good way to avoid false positives is to set thresholds in the proper way: you have to edit the config file and set the score levels.
vi /etc/httpd/modsecurity-crs/modsecurity_crs_10_config.conf
than look at the lines
SecAction \ "id:'900003', \ phase:1, \ t:none, \ setvar:tx.inbound_anomaly_score_level=5, \ setvar:tx.outbound_anomaly_score_level=4, \ nolog, \ pass"
You have to put something different into the tx.inbound_anomaly_score_level and tx.outbound_anomaly_score_level: values of 15 and 12 are ok!
SecAction \ "id:'900003', \ phase:1, \ t:none, \ setvar:tx.inbound_anomaly_score_level=15, \ setvar:tx.outbound_anomaly_score_level=12, \ nolog, \ pass"
Then a restart…. and it’s up and running!
/etc/init.d/httpd restart