Can mod_security only log triggered rules if the request was blocked

apache-2.2mod-security

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 81.138.5.14] 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.

Thanks.

Best Answer

The rule is as follows:

SecRule TX:INBOUND_ANOMALY_SCORE "@gt 0" \
    "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.

Related Topic