System training with ModSecurity (avoiding false positives)

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