Skip to content
← Все статьи

Правила 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 не блокирует легитимный трафик.

Проверьте ваш сайт прямо сейчас

Проверить безопасность сайта →
Другие статьи: Безопасность
Безопасность
Content Security Policy (CSP) — полное руководство по настройке
12.03.2026 · 134 просм.
Безопасность
Руководство по двухфакторной аутентификации: TOTP, SMS и аппаратные ключи
16.03.2026 · 153 просм.
Безопасность
Стратегии ограничения частоты запросов для веб-API
16.03.2026 · 131 просм.
Безопасность
CORS: руководство по Cross-Origin Resource Sharing
16.03.2026 · 138 просм.