Как разобрать ложное срабатывание ModSecurity

Сначала найдите запись транзакции в журнале ModSecurity, затем сопоставьте ID правила, URI и хост и проверьте, что именно вызвало срабатывание. Только после этого выбирайте узкое исключение. Ни статус 403, ни догадка по одному сообщению не объясняют причину блокировки.

Почему WAF блокирует обычный запрос

ModSecurity сам по себе не знает, какой запрос полезен бизнесу. Он применяет подключённые правила к HTTP-транзакции; часто это OWASP Core Rule Set (CRS), но состав зависит от установки. Форма может передавать текст с кавычками, HTML или фрагментом SQL, а правило отметит совпадение как подозрительное. Это сигнал для проверки, а не доказательство атаки и не автоматический диагноз «сломался сайт».

Я сначала выясняю, где именно возник отказ: адрес страницы, действие пользователя, метод запроса, время и ответ приложения. Ошибка 403 может быть результатом блокирующего правила, а похожее сообщение в браузере может прийти от приложения, прокси или другого фильтра. Ищите корреляцию в журнале ModSecurity и в логах веб-сервера. Уточните, включён ли режим блокировки: при DetectionOnly правило регистрирует совпадение, но не должно прерывать транзакцию. Само наличие записи ещё не говорит, что WAF её остановил.

Перед правкой я проверяю границы наблюдаемого: URL в логе может быть нормализован, а тело запроса может отсутствовать в аудите, если его запись или обработка не настроены. Лимит тела запроса — отдельная настройка; нельзя объяснять им любую ошибку загрузки и тем более обещать один универсальный код ответа. Сравните время события, URI, метод и сообщение правила, затем воспроизведите действие в тестовой среде. Если работаете с защитой сайта, настройка информационной безопасности должна начинаться с журналов и оценки риска, а не с массового отключения правил.

• Проверьте метод, URI и время запроса
• Сопоставьте ответ WAF с логом веб-сервера
• Отличайте режим обнаружения от блокировки

Как найти ID правила в журнале

Путь к журналу задаётся конфигурацией и способом установки; файла /var/log/modsec_audit.log может не быть. В конфигурации найдите директиву SecAuditLog и проверьте фактический журнал. ModSecurity может писать события в последовательный файл или в отдельные файлы с индексом. Формат и набор частей тоже настраиваются, поэтому не рассчитывайте, что в каждой записи будут все заголовки и тело запроса.

В записи ищите поля [id "…"] и [msg "…"], затем сопоставьте их с URI и хостом запроса. В ModSecurity 2 записи аудита разбиты на секции: совпавшие правила обычно перечисляются в части H, а часть K может содержать matched rules, если включена соответствующая запись. Формат зависит от версии и конфигурации; поэтому сначала найдите границы одной транзакции и её уникальный идентификатор, а уже потом читайте сообщения. Поиск по строке URI может вывести соседние транзакции или несколько попаданий — один grep не устанавливает причинную связь.

Когда журнал большой, сужайте выборку по временному окну и URI, а найденную транзакцию читайте целиком. Проверьте, что ID относится к тому же событию, а не просто встретился рядом в файле. Зафиксируйте хост, URI, метод, ID и сообщение правила. Именно такой набор база знаний рекомендует сохранить при разборе ошибки. Если поле с телом запроса не записано, не включайте подробное логирование вслепую: тело может содержать пароли, персональные данные и содержимое форм. Сначала проверьте действующие правила хранения и доступа к журналам.

Полезная привычка — сохранить исходную запись до настройки исключения, вместе со временем и идентификатором транзакции. Тогда можно сравнить поведение после изменения и откатить его, если эффект не тот. Не копируйте целиком чувствительные данные в тикет или чат: достаточно безопасно замаскированного фрагмента с нужными полями. В аудите безопасности сайта полезен тот же принцип: вывод должен опираться на воспроизводимое событие и конкретный журнал, а не на предположение.

• Путь журнала — из активной конфигурации
• Найдите ID и сообщение правила
• Сверьте хост, URI, метод и время

Как выбрать узкое исключение

Не пишите директиву, пока не проверили точное правило и совпавший параметр. Для полного удаления правила по ID в конфигурации ModSecurity существует SecRuleRemoveById; директива должна обрабатываться после самого правила, которое она удаляет. Поэтому локальные настройки исключений подключают после CRS. Положение имеет значение: файл, прочитанный раньше набора правил, не может удалить ещё не загруженное правило. Порядок включения проверьте для своей сборки и версии.

Полное исключение ID ослабляет проверку этим правилом для всех запросов в соответствующем контексте. Если ложное срабатывание касается только одного поля, предпочтительнее исключить конкретную цель правила, используя механизм CRS вроде SecRuleUpdateTargetById для настройки на этапе конфигурации или ctl:ruleRemoveTargetById для узкого исключения во время обработки запроса. Если нужно ограничить исключение URI или методом, условие должно стоять перед целевым правилом и точно описывать нужный запрос. Синтаксис и порядок директив зависят от версии ModSecurity и CRS; переносить случайный сниппет из чужой конфигурации без сверки нельзя.

Я не советую обходить проблему условием только по User-Agent: его легко подменить, и оно часто захватывает не тот трафик. И IP-исключение не универсальный ответ: адреса могут меняться или быть общими для многих пользователей. Подбирайте условие по конкретному URI и методу, а если возможно — уберите из проверки только тот параметр, который подтвердился в аудите. Если безопасно сузить исключение нельзя, оставьте правило включённым и исправьте формат входных данных или приложение.

Не путайте исключение цели с allow или полным отключением движка для запроса. Чем шире обход, тем больше запросов проходит без проверки; слово «временный» не уменьшает эту область. Зафиксируйте ID, причину, затронутый URI и владельца изменения в комментарии рядом с локальным правилом. В условном кейсе компании «Бриз» мы сначала сверили ID с конкретным запросом оформления заказа и лишь затем обсуждали исключение. Это пример процесса, а не универсальная директива для чужого сайта.

• Сначала подтвердите ID и цель совпадения
• Подключайте исключения после CRS
• Ограничьте исключение нужным URI и методом

Как применить изменение и проверить результат

Перед изменением сохраните копию конфигурации и проверьте синтаксис штатной командой веб-сервера. Для Apache apachectl -t выполняет проверку конфигурации; затем применяйте подходящий для вашей установки graceful reload или перезапуск. Не переносите команду Apache на NGINX: у него другой бинарный файл, способ установки и порядок загрузки модуля. Если проверка конфигурации сообщает ошибку, не применяйте изменение на рабочем сервере.

После загрузки конфигурации повторите тот же пользовательский сценарий с теми же методом, URI и параметрами, но без чувствительных данных. Убедитесь, что нужная функция приложения завершилась успешно: для оформления заказа это означает проверенный результат в приложении, а не только HTTP 200 от промежуточной страницы. Проверьте, что исходное правило больше не блокирует именно этот сценарий и что другие релевантные события продолжают попадать в журнал. Один успешный запрос не доказывает, что все варианты формы работают.

Повторно изучите запись транзакции и сравните её с исходной: какой ID сработал, был ли запрос пропущен или заблокирован, появились ли новые совпадения. При необходимости выполните контролируемую проверку в тестовой среде или согласованный скан безопасным инструментом. Не запускайте сканер по рабочему сайту без оценки нагрузки и разрешения владельца. Если после настройки меняется поведение других путей, немедленно откатите файл и разбирайте порядок загрузки или ширину условия.

После проверки оставьте заметку: что исправлено, почему исключение узкое, где оно подключено и как его удалить. Назначьте дату пересмотра, особенно если это временная мера. Обновление CRS может изменить ID, цели и порядок правил; после обновления снова проверьте локальные исключения и сценарий приложения. Локальная настройка, которую никто не помнит, — не стратегия. Это просто будущий инцидент с отложенным стартом.

• Сохраните исходную конфигурацию
• Проверьте синтаксис до reload
• Повторите сценарий и проверьте журнал
• Запишите причину и план пересмотра

DetectionOnly и постоянная настройка

Перед включением нового набора правил или крупным обновлением CRS полезен DetectionOnly: режим помогает увидеть совпадения, не превращая каждое из них в блокировку. Экспертная база рекомендует сначала наблюдать WAF на рабочей нагрузке, а потом включать блокирующее действие. Но это не замена проверке: анализируйте журнал и реальные сценарии сайта, иначе вы просто накопите большой список непонятных совпадений. И проверьте, что режим действительно действует на нужный виртуальный хост.

После наблюдения разбирайте не количество записей, а последствия конкретных правил для важных функций: входа, отправки формы, загрузки и оформления заказа. Подтверждённые ложные срабатывания закрывайте узкими исключениями и сохраняйте в локальном файле конфигурации под контролем версий. Шаблон для исключений должен загружаться после CRS, иначе конфигурация может не дать ожидаемого результата. Если одна и та же проблема возникает на нескольких URI, выясните, общий ли параметр её вызывает; не добавляйте исключение на все API только потому, что один запрос не прошёл.

Переход к блокировке делайте после просмотра журналов и функциональной проверки. Убедитесь, что правило срабатывает именно на нежелательном запросе, а легитимные сценарии проходят. Если включили блокировку и обнаружили ошибку, возвращайтесь к конкретной записи и меняйте минимальную область настройки. Полностью отключать ModSecurity из-за одного ID обычно избыточно: так вы убираете проверки, которые к инциденту отношения не имеют.

Я выбираю простое правило эксплуатации: каждое исключение должно отвечать на три вопроса — какое событие подтвердили, какой участок проверки ослабили и как проверить, что причина исчезла. Если ответов нет, изменение не готово. WAF не исправляет уязвимый код и не заменяет обновления приложения, но правильно настроенные журналы помогают увидеть, что именно он делает. В этом и состоит работа: сначала факт из транзакции, потом небольшое изменение, затем повторная проверка.

• Соберите реальные сценарии в DetectionOnly
• Разберите совпадения и исключите ложные
• Включайте блокировку после проверки

Частые вопросы