Правила WAF: написание эффективных политик веб-файрвола
Что такое правила WAF?
Web Application Firewall (WAF) инспектирует HTTP/SSL/TLS проверку-трафик между пользователями и вашим веб-приложением, блокируя вредоносные запросы на основе набора правил. Правила WAF определяют, какие паттерны искать и какое действие предпринять — пропустить, заблокировать, залогировать или отправить на CAPTCHA.
В отличие от сетевых файрволов (Layer 3/4), WAF работает на прикладном уровне (Layer 7). Он может инспектировать URL-пути, параметры запроса, тела POST-запросов, заголовки, cookies и даже JSON/XML-пейлоады. Это делает его эффективным против прикладных атак, которые сетевой файрвол не обнаружит.
Типы правил WAF
Управляемые наборы правил
Готовые правила от вендоров безопасности или сообщества:
- OWASP Core Rule Set (CRS) — самый распространённый open-source набор, покрывающий SQL injection, XSS, command injection, path traversal. Используется ModSecurity, AWS WAF, Cloudflare
- Вендорские правила — Cloudflare Managed Rules, AWS Managed Rules — постоянно обновляются командами безопасности
- Правила управления ботами — идентификация и блокировка автоматизированного трафика, скраперов, credential stuffing
Пользовательские правила
Правила для вашего конкретного приложения. Более точные, так как учитывают ожидаемое поведение:
# ModSecurity: блокировка доступа к админке с не-белых IP
SecRule REMOTE_ADDR "!@ipMatch 10.0.0.0/8,203.0.113.50" \
"id:1001,phase:1,deny,status:403,chain"
SecRule REQUEST_URI "@beginsWith /admin" \
"msg:'Admin access from non-whitelisted IP'"
# Блокировка SQL injection в параметрах запроса
SecRule ARGS "@detectSQLi" \
"id:1002,phase:2,deny,status:403,\
msg:'SQL Injection attempt detected'"
Правила на основе частоты (Rate-Based)
Ограничение запросов от одного источника за период:
# Пример rate limiting
Если: запросы от одного IP к /api/login > 10 в минуту
Тогда: блокировка на 600 секунд
Типичные атаки и правила защиты
SQL Injection (SQLi)
Атаки внедряют SQL-код через пользовательский ввод:
# Блокировка паттернов SQL injection
SecRule ARGS|ARGS_NAMES|REQUEST_COOKIES \
"@detectSQLi" \
"id:2001,phase:2,deny,status:403,\
msg:'SQL Injection detected'"
# Типичные паттерны:
# ' OR 1=1 --
# UNION SELECT
# ; DROP TABLE
Cross-Site Scripting (XSS)
# Блокировка XSS в параметрах и заголовках
SecRule ARGS|REQUEST_HEADERS \
"@detectXSS" \
"id:2002,phase:2,deny,status:403,\
msg:'XSS attack detected'"
# Паттерны: <script>, javascript:, onerror=, onload=
Path Traversal
# Блокировка обхода каталогов
SecRule REQUEST_URI|ARGS "@contains ../" \
"id:2003,phase:1,deny,status:403,\
msg:'Path traversal attempt'"
Принципы написания эффективных правил
- Начинайте в режиме обнаружения — логируйте совпадения без блокировки. Анализируйте логи на ложные срабатывания перед включением блокировки
- Ограничивайте область действия — применяйте правила только к релевантным параметрам. SQLi-правило на поле поиска — разумно; на поле редактора — ложные срабатывания
- Используйте anomaly scoring — вместо блокировки по одному совпадению накапливайте баллы. Блокируйте при превышении порога. OWASP CRS использует этот подход
- Белый список важнее чёрного — определяйте, как выглядят валидные запросы, а не перечисляйте все атаки
- Тестируйте на реальном трафике — воспроизводите продакшен-трафик на новых правилах перед деплоем
Борьба с ложными срабатываниями
Ложные срабатывания — легитимные запросы, заблокированные WAF — главная операционная проблема. Стратегии:
- Исключения правил — отключение конкретных правил для конкретных параметров. Пример: отключить SQLi-детектирование для поля
contentна/api/articles - Настройка порога anomaly — повысить порог, требуя больше совпадений для блокировки
- Белые списки — разрешить известным IP, user agent или паттернам обходить определённые правила
- Поэтапное включение — от логирования через CAPTCHA к блокировке по мере роста уверенности
# Исключение SQLi-правила для полей контента CMS
SecRule REQUEST_URI "@beginsWith /api/articles" \
"id:3001,phase:1,nolog,pass,\
ctl:ruleRemoveTargetById=942100;ARGS:content"
Модели развёртывания WAF
| Модель | Плюсы | Минусы |
|---|---|---|
| Облачный WAF (Cloudflare, AWS) | Простая настройка, DDoS-защита, авто-обновление правил | Добавляет задержку, меньше кастомизации |
| Локальный (ModSecurity) | Полный контроль, глубокая кастомизация | Нагрузка на поддержку, нет DDoS-защиты |
| Гибридный | Облако для DDoS + базовые правила, локальный для кастомных | Сложность управления двумя системами |
Мониторинг работы WAF
- Частота блокировок — резкие скачки указывают на атаки или новые ложные срабатывания
- Частота ложных срабатываний — отслеживайте жалобы клиентов, коррелирующие с блокировками
- Частота срабатывания правил — правила, срабатывающие слишком часто, нуждаются в настройке
- Влияние на задержку — инспекция WAF добавляет время обработки. Мониторьте P95 с WAF и без
Заключение
Правила WAF — первая линия защиты вашего приложения от веб-атак. Начните с управляемых наборов (OWASP CRS), затем добавляйте пользовательские правила. Тестируйте в режиме обнаружения, систематически обрабатывайте ложные срабатывания и непрерывно мониторьте эффективность. Хорошо настроенный WAF блокирует тысячи атак ежедневно, оставаясь невидимым для легитимных пользователей. Комбинируйте с мониторинг сайтов через Enterno.io для проверки, что WAF не блокирует легитимный трафик.
Проверьте ваш сайт прямо сейчас
Проверить →