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

ModSecurity and Logrotate

As you may have read, we are using ModSecurity to filter out bad HTTP requests on our servers. In this little post you will learn how to integrate ModSecurity and Logrotate to work effectively together.

One of this technology’s fallback is that it logs an incredible amount of data to /var/log/modsec_audit.log (all this data is useful for debugging purposes, so we do not want to avoid logging at all)… The size of this file at the end of the day is HUGE…

To avoid this we have created a new logrotate script that handles all the work. To install it under CentOS type

vi /etc/logrotate.d/modsecurity

then insert the following lines:

/var/log/modsec_audit.log {
    rotate 1
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
}

No need to restart, it does everything when logrotate runs by itself…

To complete the scenario, let’s have a look to the lines we have written:

rotate 1

tells logrotate to keep ONLY 1 copy of the file. This means that today at 4 am logrotates deletes the file modsec_audit.log.1.gz and creates a new one starting from modsec_audit.log.

compress

means that we do want a compressed archive of the file

postrotate
    /sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript

forces a restart of Apache.