Может ли mod_security регистрировать только триггерные правила, если запрос был заблокирован?

Question

Может ли mod_security регистрировать только триггерные правила, если запрос был заблокирован?

Я установил mod_security и сейчас работаю в DetectionOnly режим, так как я отслеживаю логи и настраиваю их под свои нужды.

Я настроил его на оценку аномалий и соответственно подправил свои оценки, чтобы уменьшить количество ложных срабатываний.

В Apache2 error_log Я получаю журнал событий, например, так:

[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"]

Эти события не превышают мою настроенную оценку входящих аномалий, которая в настоящее время установлена на 20. Я могу получить такие события, регистрируемые около 25 раз, за одну загрузку страницы, вздувая мой Apache2 error_log,

Есть ли в любом случае, чтобы ограничить то, что отправляется на error_log чтобы регистрировались только аномалии, превышающие мой лимит?

Цель

Я пытаюсь достичь двух вещей здесь. Я хочу сохранить error_log настолько чистым, насколько это возможно, чтобы он не стал раздутым и занимал слишком много места.

Я также хочу иметь возможность просматривать и отслеживать эти журналы, чтобы продолжить мою текущую конфигурацию mod_security. В идеале это просто показывало бы события, которые превысили предел аномалии, поэтому я могу видеть, являются ли они ложными срабатываниями или нет.

Благодарю.

3

apache-2.2 mod-security

Источник

AJReading 01 май '15 в 14:01

1 ответ

Решение

Другие вопросы по тегам apache-2.2 mod-security

Barry Pollard 02 май '15 в 09:02 2015-05-02 09:02 · Accepted Answer · 2015-05-02 09:02

Правило следующее:

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}"

который в основном говорит, что если оценка выше 0, но ниже tx.inbound_anomaly_score_level, то зарегистрируйте его. Предположительно, так что вы можете просмотреть правила, которые сработали, но не достаточно, чтобы заблокировать.

Если это правило не очень полезно для вас, возможно, лучше просто полностью удалить его, чтобы не тратить время на тестирование: запускать его или нет:

SecRuleRemoveById 981203

Обратите внимание, что это должно быть указано ПОСЛЕ определения правила.

Удаление правил таким способом обычно лучше, чем редактирование файлов CRS, чтобы облегчить будущие обновления.