Настройка WAF на open-source: как защитить веб-приложения без иллюзий и лишней магии

Содержание

1. Краткое содержание
2. Введение: почему WAF снова стал важной темой
3. Что такое WAF простыми словами
4. Основные понятия: что нужно знать перед настройкой WAF
5. Как работает WAF: логика обработки запроса
6. Архитектура внедрения WAF
7. Open-source WAF: что выбрать
8. Практическая настройка WAF: безопасный алгоритм внедрения
9. Пример настройки под Nginx + ModSecurity + CRS
10. WAF для Bitrix: что учитывать
11. Типичные ошибки при настройке WAF
12. Лучшие практики настройки WAF
13. Open-source или коммерческий WAF: сравнение подходов
14. Российский контекст: когда open-source недостаточно
15. Практические сценарии
16. Чек-лист внедрения WAF
17. FAQ
18. Основные выводы
19. Источники

Краткое содержание

WAF (Web Application Firewall) — это межсетевой экран уровня веб-приложений, который анализирует HTTP/HTTPS-запросы и помогает обнаруживать или блокировать атаки на веб-сервисы: SQL-инъекции, XSS, path traversal, атаки на API, подозрительные загрузки файлов и другие сценарии из OWASP Top 10. OWASP описывает WAF как firewall для HTTP-приложений, который применяет набор правил к HTTP-диалогу и защищает серверы, а не клиентов.

Для open-source внедрения чаще всего используют связку ModSecurity + OWASP Core Rule Set (CRS), а также Coraza WAF и NAXSI. OWASP CRS — это набор универсальных правил обнаружения атак для ModSecurity, Coraza и совместимых WAF; он ориентирован на защиту от широкого набора атак, включая OWASP Top 10, с минимизацией ложных срабатываний.

Главное правило внедрения: не включайте WAF сразу в блокирующий режим на production без этапа обучения и тюнинга. Сначала запускайте DetectionOnly, собирайте аудит-логи, разбирайте ложные срабатывания, настраивайте исключения и только после этого переводите отдельные зоны в blocking mode. Зрелые компании рассматривают WAF не как замену безопасной разработке, а как дополнительный защитный слой рядом с SAST/DAST, безопасной аутентификацией, обновлениями, мониторингом и процессом реагирования.

Введение: почему WAF снова стал важной темой

Веб-приложения остаются одним из самых удобных входов в корпоративную инфраструктуру. У них публичный адрес, понятный протокол, множество параметров, API, формы авторизации, личные кабинеты, загрузки файлов, интеграции с внешними сервисами. Для бизнеса это нормально: веб-сервис должен быть доступен. Для злоумышленника это тоже удобно: не нужно физически находиться в сети компании, достаточно найти слабое место в приложении, API или конфигурации.

WAF появляется именно на этом стыке. Он не знает бизнес-логику приложения так глубоко, как разработчик. Но он видит HTTP-запросы и может заметить то, что обычно не должно попадать в нормальный пользовательский трафик: подозрительные конструкции, попытки обращения к системным файлам, скриптовые вставки, необычные заголовки, массовый перебор путей, признаки эксплуатации известных классов уязвимостей.

Здесь важно не впасть в две крайности. Первая — считать WAF «серебряной пулей», которая закроет плохой код. Не закроет. OWASP прямо подчёркивает, что для инъекций лучшим методом выявления остаётся анализ исходного кода, а автоматизированное тестирование параметров, заголовков, URL, cookies, JSON, SOAP и XML должно быть частью CI/CD.[4] Вторая крайность — считать WAF бесполезным. Это тоже неверно. Хорошо настроенный WAF даёт время: помогает снизить риск эксплуатации известной уязвимости, обнаруживает подозрительные запросы, формирует доказательную базу для расследования и иногда останавливает атаку до приложения.

Почему это важно: веб-приложение редко живёт в идеальной среде. Есть legacy-код, CMS, плагины, сторонние модули, временные интеграции, срочные релизы. WAF нужен как компенсирующий контроль и как источник видимости.

Какие риски возникают: ложные блокировки, просадка производительности, чувство ложной безопасности, неправильные исключения, отсутствие мониторинга логов.

Частая ошибка: поставить ModSecurity с CRS, включить блокировку и забыть. Через неделю бизнес жалуется, что не работает корзина, форма заявки или выгрузка отчёта.

Как избежать: внедрять WAF этапами: инвентаризация, тестовый режим, обучение, tuning, пилотная блокировка, интеграция с SIEM/SOC.

Как поступают зрелые компании: используют WAF как часть Application Security: рядом с secure SDLC, DAST, SAST, pentest, patch management и incident response.

Что такое WAF простыми словами

WAF — это фильтр между пользователем и веб-приложением. Он получает HTTP/HTTPS-запрос, анализирует его по правилам, политике, сигнатурам, поведенческим признакам или модели допустимого поведения и принимает решение: пропустить, залогировать, изменить, заблокировать или отправить событие в систему мониторинга.

OWASP WAFEC рассматривает Web Application Firewall как отдельный класс решений и предлагает критерии оценки WAF под конкретные задачи, сценарии и окружения.[2] Это важно, потому что WAF бывает разным: open-source модуль для Nginx, облачный сервис, аппаратно-программный комплекс, managed WAF от провайдера, WAF в составе CDN, WAF для Kubernetes Ingress, API Gateway с функциями WAAP.

Что WAF обычно умеет

• проверять URL, query string, headers, cookies, body;
• выявлять признаки SQL injection, XSS, path traversal, command injection, RFI/LFI;
• ограничивать подозрительные методы HTTP;
• контролировать размер тела запроса и загрузку файлов;
• учитывать IP, географию, User-Agent, частоту запросов;
• логировать вредоносные или подозрительные события;
• работать в режиме обнаружения или блокировки;
• передавать события в SIEM, SOC или log pipeline;
• применять исключения под конкретные URL, параметры и приложения.

Чего WAF не должен обещать

WAF не исправляет уязвимый код. Он не заменяет контроль доступа, не решает проблему слабых паролей, не защищает от всех логических ошибок и не гарантирует защиту от zero-day. Он может снизить риск, но только если его правила актуальны, режимы настроены, логи анализируются, а исключения не превращены в «разрешить всё».

Основные понятия: что нужно знать перед настройкой WAF

Reverse proxy

Частый вариант размещения WAF — перед приложением в режиме reverse proxy. Пользователь обращается к WAF, WAF анализирует запрос и передаёт его дальше на backend. Для Nginx это естественная схема: Nginx принимает HTTP/HTTPS, а WAF-модуль анализирует транзакции.

Embedded WAF

ModSecurity — пример встраиваемого WAF. Его можно развернуть как часть Apache, IIS или Nginx-инфраструктуры. В документации ModSecurity v3 прямо описан embedded-mode deployment: WAF разворачивается внутри существующего веб-сервера и анализирует HTTP-транзакции.[7]

Rule set

Rule set — набор правил обнаружения. Самый известный open-source набор — OWASP CRS. Он покрывает широкий круг атак и работает с ModSecurity, Coraza и совместимыми WAF.[5]

DetectionOnly

Режим, при котором WAF анализирует запросы и пишет события, но не блокирует пользователя. Это лучший старт для production-внедрения: сначала смотрим, что сломается, потом блокируем.

Anomaly scoring

OWASP CRS использует модель «накопления баллов». Каждое правило добавляет определённый score, а итоговый inbound/outbound score сравнивается с порогом блокировки. Документация CRS описывает, что индивидуальные оценки по paranoia level складываются перед каждой оценкой блокировки.[6]

Paranoia Level

Paranoia Level — уровень строгости правил CRS. Чем выше уровень, тем больше правил и тем выше шанс обнаружить сложные атаки, но тем выше риск false positive. Начинать обычно безопаснее с PL1, а затем повышать точечно.

False positive

Ложное срабатывание: нормальный бизнес-запрос WAF принял за атаку. Например, форма поиска содержит слово select, CMS отправляет длинный JSON, Bitrix использует специфичный AJAX, а WAF считает это подозрительным.

Exclusion / allowlist

Исключение из правила. Хорошее исключение точное: конкретный rule ID + конкретный URL/параметр. Плохое исключение отключает весь WAF для /bitrix/, /api/ или /upload/.

Как работает WAF: логика обработки запроса

Упрощённая схема:

1. Клиент отправляет запрос.
2. WAF получает HTTP-транзакцию.
3. Движок WAF нормализует данные: URL decoding, обработка заголовков, тела запроса, cookies.
4. Запрос проверяется по правилам.
5. Срабатывания получают оценку, severity, tags.
6. WAF принимает решение: логировать, пропустить, заблокировать, изменить ответ.
7. Событие отправляется в audit log, SIEM или SOC.
8. Аналитик разбирает событие, уточняет правила или создаёт исключение.

На практике вся ценность WAF появляется не в момент установки, а после настройки. Два сервера с одинаковым ModSecurity и OWASP CRS могут работать совершенно по-разному: один будет тихо помогать SOC, другой — ломать формы заявки и бесить бизнес. Разница почти всегда в тюнинге.

Архитектура внедрения WAF

Вариант 1. WAF на веб-сервере

Например, Nginx + ModSecurity v3 + OWASP CRS. Это популярная схема для небольших и средних проектов, где инфраструктура управляется самостоятельно.

Плюсы: доступно, гибко, open-source, можно быстро внедрить.

Минусы: нужны компетенции, тюнинг, контроль производительности и логов.

Вариант 2. WAF как reverse proxy перед приложением

Отдельный узел принимает трафик, анализирует и проксирует дальше.

Плюсы: проще отделить WAF от приложения, масштабировать, логировать.

Минусы: нужно аккуратно настроить TLS, заголовки, реальные IP, отказоустойчивость.

Вариант 3. WAF на edge/CDN

Подходит для публичных сервисов и проектов с географически распределённой аудиторией.

Плюсы: удобно для DDoS/WAF вместе, быстрое подключение.

Минусы: ограниченный контроль, вопросы хранения логов и регуляторики.

Вариант 4. WAF в Kubernetes

WAF подключается через Ingress Controller, sidecar, API Gateway или сервисную сетку. Для Kubernetes часто интересны Coraza, Envoy-based связки, Nginx Ingress с ModSecurity.

Плюсы: ближе к cloud-native архитектуре.

Минусы: нужно учитывать производительность, CI/CD, GitOps, централизованную поставку правил.

Вариант 5. Сертифицированный российский WAF

Для регулируемых контуров, ГИС, КИИ, ИСПДн и организаций с формальными требованиями к СЗИ open-source WAF не всегда допустим как основной защитный механизм. В России есть коммерческие и сертифицированные решения: PT Application Firewall, Континент Web/Континент TLS-сервер, Solar WAF, SolidWall WAF, UserGate WAF и другие. Например, PT Application Firewall имеет материалы по сертификации ФСТЭК на официальном сайте вендора.[13] «Континент TLS-сервер» получил сертификат ФСТЭК по требованиям к WAF; производитель указывает, что набор сертификатов позволяет легитимно использовать продукт для защиты веб-приложений, включая анализ трафика с алгоритмами ГОСТ.[14]

Практический вывод: open-source WAF можно использовать как дополнительный технический слой, для пилотов, лабораторий, DevSecOps и нерегулируемых контуров. Но если WAF заявляется как СЗИ в аттестуемой системе, нужно отдельно проверять требования регулятора, модель угроз, класс/тип межсетевого экрана и наличие действующего сертификата.

Open-source WAF: что выбрать

Решение	Где уместно	Сильные стороны	Ограничения
ModSecurity + OWASP CRS	Nginx, Apache, reverse proxy	зрелая экосистема, много документации, совместимость с CRS	требует тюнинга, производительность зависит от конфигурации
Coraza WAF	Go-сервисы, Envoy/Traefik, cloud-native	современный движок, поддержка SecLang, совместимость с OWASP CRS	меньше эксплуатационной истории, чем у ModSecurity
NAXSI	Nginx-проекты с моделью whitelist	простой подход, высокая производительность	требует аккуратного whitelist; может давать false positive
BunkerWeb	быстрый старт WAF вокруг Nginx	удобная обвязка и автоматизация	нужно оценивать под промышленную эксплуатацию
open-appsec	open-source/managed подход для web/API	современный подход к web/API security	зависит от архитектуры и поддержки проекта

ModSecurity + OWASP CRS

Это самая известная open-source связка. ModSecurity даёт движок анализа HTTP-транзакций, OWASP CRS — набор правил. Nginx-коннектор передаёт HTTP-транзакции в libmodsecurity; документация ModSecurity-nginx указывает, что перед сборкой коннектора нужно иметь установленную libmodsecurity.[8]

OWASP CRS особенно ценен тем, что покрывает широкий набор распространённых атак и регулярно развивается. Его не стоит воспринимать как «готовую магическую защиту». Это скорее базовая экспертиза, которую нужно подстроить под конкретное приложение.

Coraza

OWASP Coraza — open-source WAF на Go. Проект описывает Coraza как enterprise-grade WAF для API и веб-приложений.[9] OWASP отмечает, что Coraza поддерживает язык правил ModSecurity SecLang и совместим с OWASP Core Rule Set.[10] Это делает Coraza интересным выбором для современных Go/cloud-native стеков и интеграций с прокси нового поколения.

NAXSI

NAXSI — Nginx Anti XSS & SQL Injection. В репозитории проекта указано, что это сторонний модуль Nginx, который использует небольшой набор простых правил для поиска известных паттернов веб-уязвимостей.[11] NAXSI также поддерживает whitelist-подход, когда неизвестный трафик по умолчанию считается подозрительным, а разрешения задаются через правила.[12]

NAXSI хорош там, где команда готова вдумчиво строить allowlist. Но для динамичных CMS и сложных API потребуется много работы с исключениями.

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

Этап 1. Инвентаризация

Перед настройкой WAF надо понять, что именно защищаем:

• домены и поддомены;
• backend-сервисы;
• API;
• CMS и фреймворки;
• формы авторизации;
• загрузки файлов;
• вебхуки;
• интеграции с платёжными системами;
• административные панели;
• легитимные нестандартные запросы.

Без этого WAF будет настраиваться вслепую.

Этап 2. Запуск в DetectionOnly

Первый запуск лучше делать без блокировки. В ModSecurity это обычно означает включить режим DetectionOnly. В этом режиме WAF анализирует HTTP-трафик и пишет срабатывания, но не применяет disruptive actions.

Пример фрагмента конфигурации:

SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.log

Здесь важно не просто включить логирование, а заранее настроить ротацию логов, права доступа, хранение и передачу событий в SIEM. Audit log может содержать чувствительные данные, поэтому к нему нельзя относиться как к обычному техническому файлу.

Этап 3. Подключение OWASP CRS

Типовая логика:

1. Установить движок WAF.
2. Подключить CRS.
3. Скопировать crs-setup.conf.example в рабочий crs-setup.conf.
4. Выбрать начальные значения paranoia level и anomaly threshold.
5. Проверить порядок подключения правил.
6. Запустить тестовый трафик.

OWASP CRS рекомендует внимательно изучить пример конфигурации перед внедрением, потому что настройки по умолчанию — это стартовая точка, а не универсальный ответ для всех приложений.[5]

Этап 4. Сбор логов и разбор false positive

На этом этапе команда смотрит:

• какие правила срабатывают чаще всего;
• на каких URL;
• какие параметры вызывают проблемы;
• есть ли реальные атаки;
• какие запросы бизнес считает нормальными;
• где приложение действительно принимает рискованный ввод.

Не стоит отключать правило глобально, если проблема в одном параметре. Лучше создать точечное исключение: rule ID + URL + параметр.

Этап 5. Постепенная блокировка

Начинайте не со всего сайта, а с зон с предсказуемым трафиком:

• /login;
• /api/auth;
• /admin с осторожностью;
• публичные формы;
• старые уязвимые endpoints;
• тестовые поддомены.

Дальше расширяйте блокировку. Важно держать rollback: если бизнес-процесс ломается, команда должна быстро вернуть участок в DetectionOnly.

Этап 6. Интеграция с SIEM/SOC

WAF без анализа логов — это дорогой генератор файлов. Подключите события в SIEM:

• критичные блокировки;
• повторяющиеся срабатывания;
• рост score по одному IP;
• атаки на административные страницы;
• попытки обхода загрузки файлов;
• корреляцию с EDR/NDR/Firewall.

Пример настройки под Nginx + ModSecurity + CRS

Ниже не инструкция «копируй и вставляй в production», а пример логики.

Nginx server/location

server {
    listen 443 ssl http2;
    server_name example.ru;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {
        proxy_pass http://backend_app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

main.conf

Include /etc/nginx/modsec/modsecurity.conf
Include /etc/crs4/crs-setup.conf
Include /etc/crs4/rules/*.conf

Исключение точечного false positive

SecRule REQUEST_URI "@beginsWith /api/search" \
    "id:100100,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:q"

Смысл: не отключать правило 942100 везде, а исключить конкретный параметр q только на /api/search, если бизнес действительно использует сложные поисковые запросы.

WAF для Bitrix: что учитывать

Bitrix часто создаёт больше ложных срабатываний, чем простое статичное приложение. Причины:

• активное использование AJAX;
• длинные параметры;
• административные формы;
• загрузка файлов;
• HTML в контенте;
• специфичные URL внутри /bitrix/;
• интеграции с CRM и платёжными системами.

Чего делать нельзя

Не отключайте WAF целиком для:

• /bitrix/;
• /bitrix/admin/;
• /upload/;
• /api/.

Это создаст дыру именно там, где часто находятся чувствительные функции.

Как делать правильно

• Запустить DetectionOnly.
• Собрать реальные бизнес-сценарии: заказ, форма, авторизация, загрузка, админка.
• Составить список ложных срабатываний.
• Делать исключения по rule ID, параметру и URI.
• Отдельно контролировать загрузку файлов.
• Запретить опасные расширения.
• Передавать события в SIEM.
• Проверять после каждого обновления CMS и модулей.

Типичные ошибки при настройке WAF

Ошибка	Почему опасно	Как правильно
Включить блокировку сразу	ломаются бизнес-процессы	сначала DetectionOnly
Отключить CRS целиком для API	атаки на API перестают контролироваться	точечные исключения
Не анализировать логи	WAF превращается в чёрный ящик	интеграция с SIEM/SOC
Игнорировать производительность	задержки и падение сервиса	нагрузочное тестирование
Не обновлять правила	ухудшается детект новых техник	регулярное обновление CRS
Хранить audit log без защиты	риск утечки ПДн и токенов	маскирование, права, ретеншн
Считать WAF заменой SDLC	уязвимости остаются в коде	WAF + secure coding + тестирование

Лучшие практики настройки WAF

Начинайте с видимости

Сначала нужно увидеть трафик и атаки. Блокировка без понимания — причина аварий.

Используйте anomaly scoring

Не каждое срабатывание должно блокировать пользователя. Накопительный score позволяет отличать единичный странный параметр от комплексной атаки.

Делайте исключения минимальными

Исключение должно отвечать на три вопроса:

• какое правило отключаем;
• где именно;
• для какого параметра.

Логируйте, но не собирайте лишнее

Audit log нужен для расследований, но он может содержать чувствительные данные. Настройте маскирование, ограничение доступа и срок хранения.

Интегрируйте WAF в процесс разработки

После релиза новой формы, API или платёжной интеграции WAF нужно проверять заново. Иначе либо появятся false positive, либо новая поверхность атаки останется без контроля.

Проверяйте WAF тестами

Используйте DAST, ручной pentest, тестовые наборы, replay логов. Но не тестируйте production опасными payload без согласования и ограничений.

Open-source или коммерческий WAF: сравнение подходов

Критерий	Open-source WAF	Коммерческий / сертифицированный WAF
Стоимость лицензии	обычно ниже	выше
Гибкость	высокая	зависит от продукта
Требования к экспертизе	высокие	ниже при наличии поддержки
Сертификация ФСТЭК	как правило, нет	может быть
Поддержка	сообщество / подрядчик	вендор / интегратор
Подходит для КИИ/ГИС/ИСПДн	зависит от требований и роли в системе	чаще подходит при наличии сертификата
Быстрый пилот	удобно	зависит от поставщика
SLA	нет по умолчанию	возможно

Экспертный вывод: open-source WAF хорош как инженерный инструмент и дополнительный слой защиты. Но для регулируемых отраслей, где важно формальное соответствие требованиям, сертифицированный российский WAF часто будет более корректным вариантом.

Российский контекст: когда open-source недостаточно

В российских проектах вопрос WAF почти всегда упирается не только в безопасность, но и в соответствие требованиям. Если компания защищает публичный сайт-визитку без обработки ПДн, open-source WAF может быть разумным вариантом. Если речь про ИСПДн, ГИС, КИИ или аттестуемую инфраструктуру, нужно смотреть:

• модель угроз;
• требования к классу межсетевого экрана;
• применимость сертифицированных средств;
• наличие ГОСТ-шифрования в контуре;
• границы контролируемой зоны;
• требования ФСТЭК/ФСБ;
• позицию аттестующей организации.

На российском рынке представлены сертифицированные WAF и сервисные модели: PT Application Firewall, Континент Web/Континент TLS-сервер, Solar WAF, SolidWall WAF, UserGate WAF. Solar отдельно указывает, что для защиты КИИ и персональных данных требуется сертифицированный ФСТЭК WAF в соответствующих сценариях применения.[15] Selectel описывает SolidWall WAF как сертифицированный инструмент с разными архитектурами развертывания, включая all-in-one и кластерное исполнение.[16]

Практические сценарии

Сценарий 1. Интернет-магазин на Bitrix

Задача: снизить риск атак на формы, корзину, личный кабинет.

Подход: Nginx + ModSecurity + CRS в DetectionOnly, tuning под Bitrix, точечные исключения, логирование в SIEM.

Что важно: не отключать /bitrix/admin/, следить за загрузкой файлов, проверять обновления модулей.

Сценарий 2. API для мобильного приложения

Задача: защитить REST API от массового перебора, подозрительных JSON payload, атак на авторизацию.

Подход: WAF + rate limiting + API Gateway + JWT validation + мониторинг.

Что важно: WAF не понимает бизнес-логику полностью; нужно дополнить его контролем авторизации и abuse detection.

Сценарий 3. Госсистема или ИСПДн

Задача: обеспечить защиту веб-приложений и соответствие требованиям.

Подход: оценить необходимость сертифицированного WAF, использовать open-source только как дополнительный слой, не заявлять его как сертифицированное СЗИ без оснований.

Что важно: требования подтверждаются не «удобством», а документами, сертификатами и моделью угроз.

Сценарий 4. Kubernetes и микросервисы

Задача: защитить ingress и внешние API.

Подход: Coraza/ModSecurity на ingress, API Gateway, централизованная поставка правил, GitOps, тесты правил в CI.

Что важно: WAF-конфигурации должны версионироваться, как код.

Чек-лист внедрения WAF

До внедрения

• Составлен список веб-приложений и API.
• Определены критичные бизнес-сценарии.
• Описаны формы, загрузки файлов, админки, интеграции.
• Понятно, требуется ли сертифицированный WAF.
• Определены владельцы приложения и ИБ.

На пилоте

• WAF запущен в DetectionOnly.
• Подключён OWASP CRS или выбран другой rule set.
• Логи собираются централизованно.
• Проверены основные пользовательские сценарии.
• Зафиксированы false positive.

Перед блокировкой

• Настроены точечные исключения.
• Проведено нагрузочное тестирование.
• Есть rollback-план.
• События уходят в SIEM/SOC.
• Ответственные знают, что делать при срабатываниях.

После внедрения

• Правила обновляются.
• Исключения пересматриваются.
• Логи анализируются.
• Новые релизы проходят WAF-проверку.
• Отчёты используются для улучшения AppSec.

FAQ

WAF защищает от всех атак на сайт?

Нет. WAF снижает риск эксплуатации распространённых классов уязвимостей, но не заменяет безопасную разработку, pentest, контроль доступа и обновления.

Можно ли использовать open-source WAF в бизнесе?

Да, если вы понимаете ограничения: нет стандартного SLA, нужны компетенции, tuning, мониторинг. В регулируемых контурах нужно отдельно проверять требования к сертификации.

Что лучше: ModSecurity или Coraza?

ModSecurity — более зрелая и распространённая связка, особенно с Nginx/Apache. Coraza интересен для Go/cloud-native окружений и поддерживает SecLang и OWASP CRS. Выбор зависит от архитектуры.

Нужно ли включать WAF сразу в blocking mode?

Нет. Начинайте с DetectionOnly, собирайте логи, настраивайте исключения, тестируйте и только потом включайте блокировку поэтапно.

Почему WAF даёт ложные срабатывания?

Потому что правила видят подозрительный паттерн, но не всегда знают бизнес-контекст. Например, CMS может легитимно передавать HTML или SQL-похожие фразы в параметрах.

Как часто обновлять правила?

Регулярно, но через тестирование. Обновление CRS без проверки может добавить новые false positive.

Основные выводы

1. WAF — полезный защитный слой для веб-приложений, но не замена secure SDLC.
2. Open-source связка ModSecurity + OWASP CRS остаётся одним из самых практичных вариантов старта.
3. Coraza и NAXSI подходят для отдельных архитектур и команд с нужной экспертизой.
4. Главный этап настройки WAF — разбор false positive и точечные исключения.
5. В российских регулируемых контурах важно учитывать требования к сертификации СЗИ.
6. WAF должен быть подключён к логированию, SIEM и процессу реагирования.
7. Для Bitrix и других CMS нельзя отключать WAF целыми директориями; нужны адресные правила.
8. Зрелая защита веб-приложений строится из нескольких слоёв: WAF, безопасная разработка, тестирование, мониторинг, обновления и расследование инцидентов.

Источники

1. OWASP Web Application Firewall — https://owasp.org/www-community/Web_Application_Firewall
2. OWASP WAF Evaluation Criteria — https://owasp.org/www-project-wafec/
3. OWASP Top 10 — https://owasp.org/www-project-top-ten/
4. OWASP A03 Injection — https://owasp.org/Top10/2021/A03_2021-Injection/
5. OWASP ModSecurity Core Rule Set — https://owasp.org/www-project-modsecurity-core-rule-set/
6. CRS Anomaly Scoring — https://coreruleset.org/docs/2-how-crs-works/2-1-anomaly_scoring/
7. ModSecurity Reference Manual v3 — https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-%28v3.x%29
8. ModSecurity-nginx connector — https://github.com/owasp-modsecurity/ModSecurity-nginx
9. OWASP Coraza Docs — https://www.coraza.io/docs/
10. OWASP Coraza project — https://owasp.org/www-project-coraza-web-application-firewall/
11. NAXSI GitHub — https://github.com/wargio/naxsi
12. NAXSI documentation — https://wargio.github.io/naxsi/
13. PT Application Firewall — https://ptsecurity.com/products/af/
14. Континент TLS-сервер / Континент Web, сертификат ФСТЭК — https://www.securitycode.ru/company/news/kontinent-tls-server-kontinent-web-poluchil-sertifikat-fste...
15. Solar WAF — https://rt-solar.ru/services/mss/blog/6568/
16. SolidWall WAF — https://selectel.ru/blog/solidwall-waf/