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