I've installed mod_security and I'm currently running in DetectionOnly mode as I monitor logs and configure to suit my servers needs.

I've set it up for anomaly scoring and tweaked my scores accordingly to reduce false positives.

In the Apache2 error_log I'm receiving log events like so:

[Fri May 01 14:48:48 2015] [error] [client] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/apache2/modsecurity-crs/activated_rules/modsecurity_crs_60_correlation.conf"] [line "33"] [id "981203"] [msg "Inbound Anomaly Score (Total Inbound Score: 13, SQLi=11, XSS=): Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] [hostname "www.domain.co.uk"] [uri "/wp-admin/admin-ajax.php"] [unique_id "VUOEQNRurOYAABA-HZEAAAAA"]

These events do not exceed my configured inbound anomaly score which is currently set to 20. I can get these kind events logged around 25 times in a single page load, bloating my Apache2 error_log.

Is there anyway to limit what is sent to the error_log so that only anomalies that exceed my limit are logged?

The aim

I'm trying to achieve two things here. I want to keep the error_log as clean as possible so that it does not become inflated and use excessive space.

I also want to be able to review and monitor these logs to continue my ongoing configuration of mod_security. Ideally, it would just show events that have exceeded the anomaly limit, so I can see if they are false positives or not.


  • there is nolog clause you can use in your rule if you don't want anything to be logged upon successful rule match – Hrvoje Špoljar May 1 '15 at 14:07
  • Thanks, I'm aware of nolog but I would like them logged, ideally just anomalies exceeded rather than any anomaly. – AJReading May 1 '15 at 14:16
  • There are different rules for exceeded (981204 or 981205). So nolog would work but waste of processing to run this rule and not log it. So better to just remove it completely and let the other two run. – Barry Pollard May 2 '15 at 9:12

The rule is as follows:

    "chain,phase:5,id:'981203',t:none,log,noauditlog,pass,skipAfter:END_CORRELATION,msg:'Inbound Anomaly Score (Total Inbound Score: %{TX.INBOUND_ANOMALY_SCORE}, SQLi=%{TX.SQL_INJECTION_SCORE}, XSS=%{TX.XSS_SCORE}): %{tx.inbound_tx_msg}'"
    SecRule TX:INBOUND_ANOMALY_SCORE "@lt %{tx.inbound_anomaly_score_level}"

which basically says if the score is above 0 but below tx.inbound_anomaly_score_level then log it. Presumably so you can review rules that fired but not enough to block.

If this rule isn't very useful for you then maybe better to just remove it completely so you don't waste time testing whether to run it or not:

SecRuleRemoveById 981203

Note this must be specified AFTER the rule is defined.

Removing rules this way is usually better than actually editting the CRS files to make future upgrades easier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.