Мелкомодульное управление входом 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 во-первых.
Я пропускаю что-то? Независимо от того, что я пробую, появляется, как будто я могу только управлять объемом входа к контрольному журналу, не имея никакого контроля над объемом входа к журналу ошибок.
После обширных проб и ошибок у меня все еще нет полностью удовлетворяющего меня решения, но, по крайней мере, обходного пути. Добавление SecRemoveRuleById внутри <Каталог>-Blocks предотвращает появление записей в журнале ошибок - но, похоже, это работает не для всех правил, а только для некоторых из них (например, деактивация правила id 960010 работает, но 960243 & 960257 не работает). Конечно, это сработает только в том случае, если Apache смог определить путь к каталогу - для многих некорректных запросов и запросов, в которых отсутствует критичная информация, Apache не знает этот путь.
Деактивация правил путём определения новых правил формы SecRule SERVER_NAME "^домен. tld$" "nolog,phase:1,t:none,id:100,ctl:ruleRemoveById=960010" тоже работает, но они должны быть определены до всех остальных правил (и, следовательно, до включения CRS-правил), чтобы надежно деактивировать существующие правила. Насколько я знаю, mod_security применяет правила в порядке их определения, поэтому деактивация фазы:1-правила после выстрела, очевидно, не предотвратит записи в журнале, которые уже произошли (деактивация фазы:2-правила в фазе 1, кажется, всегда срабатывает, чего и следовало ожидать). Несколько неудобно, что я не могу повлиять на порядок применения, не изменив порядок определения.
Конечно, решение, которое я действительно искал, это деактивация записей лога ошибок в целом. Это требует слишком много усилий, чтобы найти часто запускаемые идентификаторы правил для каждого VHost и деактивировать их по отдельности. 10000 VHosts á 10 минут конфигурации -> Почти год, чтобы заставить его работать на каждом VHost.
.