Детальный контроль над ведением журнала mod_security
Я установил mod_security2 на несколько десятков серверов (каждый с несколькими десятками VHosts), и у меня нет времени настраивать его для каждого VHost. В конфигурации по умолчанию он генерирует обильное количество ложных срабатываний в файлах журналов, поэтому я решил позволить ему работать в DetectionOnly-режим (ничего не блокирует, но я все еще получаю подробные журналы для большинства попыток взлома) для всех, кроме избранных VHosts.
Я был доволен этой настройкой, пока не обнаружил, что файлы журналов на некоторых серверах выросли до нескольких гигабайт менее чем за 3 недели. Я решил отключить ведение журнала для нескольких VHosts, которые производили львиную долю этих записей журнала. Есть несколько различных способов сделать это, я в конечном итоге остановился на создании новых правил с очень конкретными триггерами, которые все имеют "nolog,phase:1,t:none,ctl:secAuditEngine=Off" как действие. Это удается, поскольку количество записей в журнале аудита снижается до управляемых уровней.
Но я все еще получаю гигабайты логов, потому что не могу предотвратить запись mod_security2 в журнал ошибок. Я старался SecDebugLogLevel 0 поскольку это единственная директива конфигурации, связанная с регистрацией ошибок (которую я смог найти в любом случае), но безрезультатно. Единственное, что, кажется, помогает SecRuleEngine Off, который побеждает цель установки mod_security2 в первую очередь.
Я что-то пропустил? Неважно, что я пытаюсь сделать, похоже, что я могу контролировать только количество записей в журнале аудита, но не могу контролировать количество записей в журнал ошибок.
1 ответ
После долгих проб и ошибок у меня все еще нет идеального решения, но есть обходной путь. Добавление SecRemoveRuleById внутри <Directory>-Блокирование предотвращает записи в журнале ошибок - но, похоже, не работает для всех правил, только для некоторых из них (например, деактивация идентификатора правила 960010 работает, но 960243 и 960257 - нет). Это, конечно, будет работать только в том случае, если Apache сможет определить путь к каталогу - для многих неправильно сформированных запросов и запросов, пропускающих важную информацию, Apache не знает путь.
Деактивация правил путем определения новых правил формы SecRule SERVER_NAME "^domain.tld$" "nolog,phase:1,t:none,id:100,ctl:ruleRemoveById=960010" работает также, но они должны быть определены до всех других правил (и, следовательно, до включения CRS-правил), чтобы надежно деактивировать существующие правила. Насколько я знаю, mod_security применяет правила в том порядке, в котором они определены, поэтому деактивация правила фаза:1 после его запуска, очевидно, не предотвратит записи журнала, которые уже произошли (деактивация правила фаза 2 в фазе 1, кажется, всегда работа, чего и следовало ожидать). Несколько неудобно, что я не могу влиять на порядок применения без изменения порядка определения.
Конечно, решение, которое я действительно искал, - это деактивация записей журнала ошибок в целом. Требуется слишком много усилий, чтобы найти идентификаторы правил для каждого VHost и деактивировать их по отдельности. 10000 VHosts - 10 минут настройки -> Почти год, чтобы все работало на каждом VHost.