Настройка WAF: пошаговое руководство для сайта
Настройка WAF — это запуск в режиме обнаружения, разбор ложных срабатываний, точечные исключения и только затем включение блокировки.
Настройка WAF: как защитить сайт и не заблокировать клиентов
Правильная настройка WAF — это поэтапный процесс: разместить фильтр перед приложением, запустить его в режиме обнаружения, разобрать ложные срабатывания, добавить точечные исключения и только потом включить блокировку.
Веб-приложение на любом современном стеке постоянно сканируют боты: они перебирают пути, подставляют SQL-фрагменты в параметры, ищут забытые админки и уязвимые плагины. WAF (Web Application Firewall) встаёт на пути этих запросов и отсеивает опасные. Но у него есть обратная сторона: слишком строгие правила блокируют покупателей, формы заявок и интеграции. В статье разберём архитектуру, режимы работы, порядок настройки, исключения и типичные ошибки на примерах ModSecurity с набором правил OWASP Core Rule Set, а также облачных решений.
Что делает WAF и чего он не делает
WAF работает на седьмом уровне модели OSI и анализирует HTTP- и HTTPS-трафик: метод, адрес, заголовки, cookie, параметры запроса и тело. Каждый запрос он сопоставляет с набором правил и либо пропускает, либо блокирует, либо записывает в журнал. Так закрываются атаки из списка OWASP Top 10: SQL-инъекции, межсайтовый скриптинг (XSS), удалённое выполнение кода, обход каталогов, включение файлов, а также часть автоматизированных угроз — сканеры, подбор паролей, парсинг.
Существуют две модели. Негативная блокирует то, что похоже на известную атаку (сигнатуры, регулярные выражения, оценка аномальности). Она проще в запуске, но даёт ложные срабатывания. Позитивная разрешает только заведомо корректные запросы: допустимые URL, методы и форматы параметров. Она надёжнее, но требует глубокого знания приложения и дорого поддерживается. На практике почти везде начинают с негативной модели и добавляют позитивные правила для критичных точек: авторизации, оплаты, API.
Важно понимать границы. WAF не исправляет уязвимый код, не защищает от утечки учётных данных и не спасает, если злоумышленник обращается к серверу напрямую по IP в обход фильтра. Это уровень защиты в глубину, а не замена обновлениям.
Где WAF стоит в цепочке обработки запроса
- 01Клиент
Браузер, бот или сканер отправляет HTTP-запрос
- 02CDN или балансировщик
Завершает TLS и передаёт реальный IP в заголовке
- 03WAF
Проверяет URL, заголовки и тело по правилам, считает баллы аномальности
- 04Приложение
Получает только запросы, прошедшие проверку
- 05Журнал и оповещения
Хранит срабатывания для разбора и алертов
Выбор схемы размещения
Прежде чем писать правила, определите, где будет работать WAF. От этого зависят скорость запуска, контроль над правилами и нагрузка на сервер.
Облачный WAF подключается сменой DNS-записи или настройкой балансировщика: трафик идёт через провайдера защиты. Это быстрый старт и готовые профили правил, но меньше гибкости и зависимость от поставщика. В облаках встречаются Cloudflare WAF, AWS WAF и Yandex Cloud Smart Web Security. Собственный обратный прокси (например, Nginx с ModSecurity и OWASP CRS) даёт полный контроль и не отправляет трафик третьим лицам, но требует администрирования и обновления правил. Модуль на самом веб-сервере проще развернуть, но он потребляет ресурсы приложения и хуже масштабируется.
Для интернет-магазина или корпоративного сайта на российской инфраструктуре чаще выбирают облачный сервис в российском облаке либо собственный прокси перед группой серверов. Для небольшого проекта достаточно готового профиля в облаке с несколькими своими правилами.
| Модель | Где работает | Сильные стороны | Ограничения |
|---|---|---|---|
| Облачный WAF | На стороне провайдера, перед сайтом | Быстрый запуск, готовые профили, защита от DDoS на L7 | Меньше гибкости, зависимость от провайдера |
| Обратный прокси (Nginx + ModSecurity) | Перед группой серверов приложений | Полный контроль правил и логов, данные остаются у вас | Нужны компетенции и обновление наборов правил |
| Модуль на веб-сервере | Внутри Apache или Nginx на том же хосте | Минимум компонентов, простая установка | Нагрузка на тот же сервер, сложно масштабировать |
| Виртуальный или аппаратный шлюз | На границе сети предприятия | Высокая производительность, поддержка вендора | Высокая стоимость и сложная интеграция |
Режимы работы и оценка аномальности
У любого зрелого WAF есть как минимум два режима: обнаружение (запрос пропускается, срабатывание пишется в журнал) и блокировка (запрос отклоняется с кодом 403 или другим). В ModSecurity это директива `SecRuleEngine`: значение `DetectionOnly` включает наблюдение, `On` включает блокировку. Новый WAF всегда запускают в первом режиме.
Набор OWASP Core Rule Set работает по принципу оценки аномальности. Каждое сработавшее правило добавляет баллы к запросу: критичное совпадение даёт 5, ошибка — 4, предупреждение — 3, уведомление — 2. В конце проверки сумма сравнивается с порогом. По умолчанию порог входящих запросов равен 5, поэтому одно критичное срабатывание уже приводит к блокировке, а несколько мелких могут её накопить.
Второй ключевой параметр — уровень паранойи (paranoia level). Чем он выше, тем больше правил включено, тем лучше ловятся нестандартные атаки и тем больше ложных срабатываний вы получите. Начинайте с первого уровня и повышайте его только для самых чувствительных частей приложения.
Уровни паранойи: баланс защиты и ложных срабатываний
Минимум ложных срабатываний. Подходит как стартовая точка для любого сайта.
Больше правил для форм и API. Нужен для большинства интернет-магазинов и сервисов.
Для платёжных страниц и личных кабинетов. Потребует много исключений.
Для особо критичных систем. Без опытной команды использовать не стоит.
Пошаговый план настройки WAF
- 01
Составьте инвентаризацию: публичные адреса, формы, API, загрузка файлов, админка, вебхуки платёжных систем и сторонние интеграции. Отметьте, какие запросы могут выглядеть «подозрительно» из-за своей природы.
- 02
Выберите схему размещения (облако, прокси или модуль) и убедитесь, что приложение закрыто от прямого доступа: на сервере должны приниматься соединения только от WAF или балансировщика.
- 03
Настройте передачу реального IP клиента: заголовок X-Forwarded-For или PROXY protocol от доверенных адресов. Без этого все запросы будут приходить с адреса прокси, а лимиты и блокировки станут бесполезны.
- 04
Включите базовый набор правил на первом уровне паранойи в режиме обнаружения. Проверьте лимиты размера тела запроса, времени ожидания и обработки JSON и multipart, чтобы не ломать загрузки.
- 05
Собирайте журнал не менее 7–14 дней. Сгруппируйте срабатывания по идентификатору правила, URL и параметру, отделите реальные атаки от ложных срабатываний.
- 06
Добавьте исключения: для каждого ложного срабатывания отключайте правило только для конкретного адреса и параметра. Затем включайте лимиты частоты запросов, защиту от ботов и географические ограничения там, где они нужны бизнесу.
- 07
Переключитесь в режим блокировки сначала для одной части трафика или части страниц, наблюдайте метрики и конверсию. После стабилизации распространите блокировку на весь сайт и настройте оповещения.
Как разбирать ложные срабатывания
Самая трудоёмкая часть настройки — работа с журналом. Каждое срабатывание содержит идентификатор правила, проверяемую переменную (например, параметр запроса `ARGS:comment`), совпавший фрагмент и итоговую оценку. Задача — понять, что стоит за запросом: реальная атака, нормальное поведение пользователя или особенность вашей системы.
Типичные источники ложных срабатываний: текстовые редакторы с HTML в теле запроса, поисковые строки с кавычками и знаками SQL-подобного вида, JSON с вложенными структурами, подписи платёжных вебхуков, закодированные в Base64 параметры, длинные cookie авторизации. Для каждого случая делайте точечное исключение. Например, в ModSecurity можно отключить правило 942100 только для вебхука:
`SecRule REQUEST_URI "@beginsWith /api/webhook" "id:10001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"`
Не отключайте правило целиком и не поднимайте порог блокировки «на всякий случай»: так вы незаметно превратите WAF в декоративный элемент. Фиксируйте каждое исключение в документации с причиной, датой и ответственным, а также периодически пересматривайте список.
Что проверить перед включением блокировки
- Журнал собирался не менее 7–14 дней, включая пики нагрузки и релизы
- Разобраны срабатывания по оплате, поиску, API и админке
- Исключения привязаны к адресу и параметру, а не отключают правило глобально
- Реальный IP клиента определяется из доверенных прокси
- Роботы Яндекса и Google проверены по обратному DNS и не блокируются
- Лимиты размера запроса подходят для загрузки файлов и больших форм
- Есть план отката: возврат в режим обнаружения занимает минуты
WAF, поисковые роботы и аналитика
Одна из самых неприятных последствий неверной настройки — потеря органического трафика. Антибот-правила, лимиты частоты запросов и блокировка по User-Agent легко отсекают YandexBot и Googlebot, а те при повторяющихся ошибках сокращают обход и могут исключать страницы из индекса. Проверьте, что роботы получают код 200: в Яндекс Вебмастере посмотрите статистику обхода и ошибки сервера, в Google Search Console — отчёт о статистике сканирования и проверку URL.
Не доверяйте одному заголовку User-Agent: его легко подделать. Надёжный способ — обратный DNS-запрос по IP с последующей прямой проверкой имени. Адреса роботов Яндекса должны разрешаться в домены yandex.ru, yandex.net или yandex.com, адреса Googlebot — в googlebot.com или google.com. Настройте правило-исключение для подтверждённых роботов и сохраняйте для них отдельную статистику в журнале.
Контролируйте и бизнес-метрики. Резкий рост отказов, падение числа заявок или конверсии в Яндекс Метрике и Google Analytics после включения блокировки часто означает, что WAF отсекает часть реальных пользователей, например из-за ошибки в правиле для формы.
Типичные ошибки при настройке WAF
Как делают неправильно
- Сразу включают блокировку и узнают о проблемах из жалоб клиентов
- Отключают правило целиком, если оно мешает одной форме
- Не настраивают передачу реального IP, и все запросы видны с адреса прокси
- Оставляют сервер доступным напрямую по IP в обход WAF
- Блокируют роботов поисковых систем из-за антибот-правил и лимитов
- Один раз настраивают и не обновляют правила и не читают журнал
Как правильно
- 01
Запускать в режиме обнаружения и переходить к блокировке поэтапно
- 02
Делать исключения по адресу и параметру с описанием причины
- 03
Принимать IP клиента только из доверенных заголовков
- 04
Ограничить доступ к серверу списком адресов WAF или балансировщика
- 05
Проверять роботов по обратному DNS и следить за отчётами в Вебмастере и Search Console
- 06
Обновлять набор правил, раз в неделю разбирать срабатывания и настроить оповещения
Мониторинг и сопровождение
Настроенный WAF — это не разовый проект, а процесс. Приложение меняется: появляются новые формы, обновляются плагины, подключаются интеграции. Каждое такое изменение способно породить новые ложные срабатывания, а каждая новая уязвимость — потребовать виртуальный патч.
Отправляйте журналы в централизованную систему (ELK, Grafana Loki, SIEM) и стройте панели по числу блокировок, топу правил, адресам и странам источников, доле кодов 403. Настройте оповещения на всплески блокировок: резкий рост 403 на странице оплаты почти всегда означает неудачное обновление правил. Раз в квартал проверяйте защиту сканером (например, OWASP ZAP) и тестовыми запросами с типичными нагрузками SQL-инъекций и XSS, чтобы убедиться, что фильтр действительно ловит то, что должен.
Обновляйте набор правил по расписанию, но сначала проверяйте новую версию на тестовом стенде или в режиме обнаружения, так как крупные релизы CRS меняют идентификаторы правил и ломают старые исключения.
Что даёт грамотно настроенный WAF
- 01
Закрывает типовые атаки из OWASP Top 10, не дожидаясь исправления кода
- 02
Выигрывает время при обнаружении новой уязвимости за счёт виртуального патчинга
- 03
Снижает нагрузку на приложение, отсекая сканеры, парсеры и подбор паролей
- 04
Даёт прозрачный журнал инцидентов для расследований и аудита безопасности
- 05
Помогает соответствовать требованиям по защите персональных данных и платёжных реквизитов
- 06
Сохраняет позиции в Яндексе и Google, если роботы поисковиков не блокируются
Итоги: как настроить WAF безопасно
- 01
Выберите схему размещения и закройте прямой доступ к серверу
- 02
Начните с режима обнаружения и первого уровня паранойи
- 03
Разбирайте журнал и делайте точечные исключения вместо отключения правил
- 04
Проверьте доступность сайта для роботов Яндекса и Google и следите за метриками
- 05
Включайте блокировку поэтапно и поддерживайте правила в актуальном состоянии
Если у вас нет времени или опыта на тонкую настройку, доверьте первичный аудит и запуск специалистам: это дешевле, чем потеря заказов из-за ложных блокировок или последствий успешной атаки.
Часто задаваемые вопросы
Обычный сетевой экран фильтрует трафик по IP-адресам и портам, а WAF разбирает содержимое HTTP-запросов (URL, заголовки, параметры, тело) и ищет в нём признаки SQL-инъекций, XSS, подбора паролей и других атак на уровне приложения.
Обычно от 7 до 14 дней, чтобы в логи попали пиковая нагрузка, релизы, работа форм оплаты, поиска, API и админки. Для сложных проектов срок увеличивают до месяца.
Да, если правила или антибот-защита блокируют роботов поисковых систем. Проверяйте доступность страниц в Яндекс Вебмастере и Google Search Console и подтверждайте ботов по обратному DNS, а не только по User-Agent.
Нет. WAF снижает риск и даёт время на исправление уязвимостей (виртуальный патчинг), но не заменяет обновления, безопасную разработку и закрытие прямого доступа к серверу в обход фильтра.
Проверьте защиту сайта: настроим WAF без блокировки реальных клиентов
Проведём аудит правил, запустим фильтр в безопасном режиме и подготовим план перехода к блокировке
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
Настройка без простоев и потери трафика
