Как настроить WAF и сохранить работу сайта

Чтобы WAF не ломал формы WordPress, сначала включите доступный в вашем решении режим обнаружения, разберите события и исключайте только конкретное правило или поле запроса. Затем проверьте заказ, оплату, вход и API. Я покажу порядок работ и объясню, почему исключение для всего сайта — плохой короткий путь.

Почему включение WAF «в лоб» ломает бизнес-процессы

WAF проверяет HTTP-запросы по набору правил и может остановить запрос, который похож на атаку. Иногда под подозрение попадает обычный комментарий, поле поиска или JSON от приложения. Пользователь видит отказ, а владелец сайта — не всегда понимает, почему пропал заказ. Для WordPress это обычно проявляется на формах, авторизации, загрузке файлов и запросах REST API. Настройка защиты сайта начинается с того, чтобы выяснить, какой компонент принял решение и что именно он записал в событие.

Я видел, как после включения новых правил переставала проходить интеграция с платежным сервисом или CRM. Само совпадение с правилом ещё не доказывает атаку: нужно сопоставить событие с URI, временем, действием WAF и ожидаемым сценарием приложения. При этом WAF не заменяет обновления CMS, безопасный код и резервное копирование. Это дополнительный слой, который может снизить часть риска, но неверное исключение ослабляет его именно там, где оно действует. База знаний фиксирует обе стороны: WAF способен ошибочно среагировать на легитимный трафик, а чрезмерно широкая настройка может пропустить вредоносный запрос.

Представим наш условный магазин настольных игр «Ход конём» с 22 рабочими местами, формой заказа, загрузкой фотографий и обменом данными с 1С. Здесь задача не в том, чтобы объявить каждое срабатывание атакой, а в том, чтобы сопоставить наблюдения с реальной работой сайта и аккуратно включить защиту. Коробка с игрой — не оружие; но если фильтр её остановил, сначала выясняю, что именно он увидел.

Этап первый: режим наблюдения и инвентаризация

Я не перевожу новый набор правил сразу в режим блокировки. Сначала выясняю, какие режимы предлагает конкретный WAF: у ModSecurity есть SecRuleEngine DetectionOnly, у облачного сервиса могут быть собственные режимы обнаружения или журналирования. Названия и поведение зависят от продукта. В режиме обнаружения ModSecurity обрабатывает правила, но не выполняет disruptive-действия вроде блокировки; это не значит, что каждый WAF ведёт себя так же. Документация ModSecurity советует начать с обнаружения и изучить события до включения защиты.

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

Не включайте бездумно запись полного тела каждого запроса и всех заголовков. В логах могут оказаться персональные данные, токены и содержимое форм; кроме того, формат и объём записи зависят от продукта и настроек. Сначала включите штатный журнал событий WAF и нужные поля для диагностики, ограничьте доступ и срок хранения. Документация Microsoft рекомендует искать совпавший запрос в WAF-логах по URI, времени и идентификатору события; эти данные помогают сузить причину без сбора лишнего содержимого. Мониторинг полезен, когда он отвечает на вопрос, а не превращает журнал в склад секретов.

Анализ ложных срабатываний: что искать в логах

В журнале я ищу конкретное событие: путь, метод, время, действие WAF, идентификатор правила и ту часть запроса, которую правило отметило. Затем сверяю событие с журналом веб-сервера и действиями пользователя. Сам по себе код HTTP 403 не объясняет причину: отказ мог вернуть WAF, веб-сервер, плагин или приложение. Если доступен идентификатор транзакции, используйте его для сопоставления записей. База знаний отдельно подтверждает практический шаг: для разбора ложного срабатывания нужно найти в логах конкретный Rule ID.

В форме обратной связи строка вроде 1=1 или текст с угловыми скобками может совпасть с сигнатурой SQL-инъекции или XSS. Совпадение — повод проверить контекст, а не автоматически пропустить запрос. Посмотрите, какое поле отмечено, к какому адресу относится запрос и повторяется ли поведение в штатном сценарии. Не публикуйте в тикетах и примерах реальные токены, персональные данные или полный запрос, если для диагностики достаточно названия поля и идентификатора правила.

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

Тюнинг правил: как сделать исключения безопасно

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

В ModSecurity директива SecRuleRemoveById удаляет соответствующее правило в заданном контексте конфигурации; механизмы исключений OWASP CRS позволяют ограничивать проверку определённых целей правила. Это не то же самое, что выдуманная конструкция с SecAction: она не является способом отключить Rule ID. Конкретный синтаксис зависит от версии ModSecurity, CRS и порядка подключения файлов. Сначала проверьте конфигурацию на тестовом окружении и убедитесь, что исключение загружается после нужного правила, если этого требует выбранный механизм.

В нашем примере с «Ходом конём» нельзя честно заявить, что мы разрешили платежи по IP шлюза: список адресов и схема доставки зависят от поставщика, а в статье нет проверенных реквизитов. Рабочая процедура другая: находим реальное событие, сверяем URI и поле, применяем узкое исключение по поддерживаемому механизмом признаку, а затем повторяем штатный и негативный сценарии. Для форм это часто означает исключить значение конкретного параметра из конкретной проверки, а не разрешить любые данные на всём сайте. OWASP CRS документирует отдельные механизмы исключения целей; Azure WAF также позволяет исключать конкретные параметры и поля.

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

Проверка функционала: формы, API и админка

После изменения правил прохожу весь список сценариев, а не только форму, на которой заметил проблему. Проверяю отправку обращения, корзину, тестовый заказ, возврат с платёжной страницы, вход в админку, загрузку файла и API. Для каждого шага записываю ожидаемый результат, фактический ответ и запись WAF. Если сайт связан с CRM, доставкой или 1С, проверяю и эти обмены. Проверка должна подтвердить сразу две вещи: нужная операция работает, а исключение не стало шире задуманного.

На условном магазине настольных игр это означает оформить тестовый заказ, проверить промокод, загрузить тестовое изображение и выполнить синхронизацию с 1С. Мы не можем по одной зелёной галочке заключить, что WAF ловит все атаки: нужна проверка выбранных контрольных сценариев и журналов. Если после включения блокировки потерялся доступ к админке, заранее подготовьте понятный путь отката конфигурации и контакт того, кто может его выполнить. Это план восстановления, а не повод постоянно держать защиту выключенной.

Проверьте сайт с обычным браузером и мобильного устройства, а также убедитесь, что CDN и кэш не показывают старый результат. Если запрос не прошёл, снимите время, URL и идентификатор события, проверьте действие WAF и сопоставьте его с серверным журналом. Не добавляйте исключение, пока не выяснили, какой компонент ответил отказом. Так мы не маскируем ошибку плагина под проблему WAF и не лечим 403 отключением защиты наугад.

Поддержка и мониторинг: безопасность не заканчивается на настройке

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

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

Я не обещаю «полную защиту» и отсутствие простоев: такого результата нельзя гарантировать одним фильтром. Я обещаю понятный процесс — найти источник отказа, проверить конкретное правило, сузить исключение и пройти основные сценарии до и после изменения. Для этого WAF должен работать вместе с обновлённой CMS, резервными копиями и контролем ошибок приложения. А журналы нужно хранить так, чтобы они помогали разбору и не собирали лишние данные.

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