Настройка Web Application Firewall (WAF) для сайта
WAF анализирует HTTP-трафик и блокирует запросы, соответствующие паттернам известных атак: SQL-инъекции, XSS, LFI/RFI, SSRF, сканирование директорий. Работает на уровне L7, перед веб-сервером или приложением.
Варианты WAF
Облачные WAF:
- Cloudflare WAF — встроен в Cloudflare, правила OWASP CRS + кастомные
- AWS WAF — интеграция с ALB, CloudFront, API Gateway
- Imperva — корпоративный уровень
Self-hosted:
- ModSecurity — модуль для Nginx/Apache, открытый стандарт
- Coraza — Go-реализация ModSecurity, совместима с OWASP CRS
- BunkerWeb — Docker-ready Nginx + WAF
ModSecurity + OWASP CRS на Nginx
Установка на Ubuntu/Debian:
apt install libnginx-mod-security2
# или сборка из исходников для последней версии ModSecurity v3
Конфигурация:
# /etc/nginx/nginx.conf
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;
server {
listen 443 ssl;
# ...
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/main.conf;
}
# /etc/nginx/modsecurity/modsecurity.conf
SecRuleEngine On # DetectionOnly для начала — только логи
SecRequestBodyAccess On
SecResponseBodyAccess Off # Включить только если нужна проверка ответов
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsecurity/audit.log
OWASP Core Rule Set
# Скачать OWASP CRS
git clone https://github.com/coreruleset/coreruleset /etc/nginx/modsecurity/crs
# main.conf
Include /etc/nginx/modsecurity/modsecurity.conf
Include /etc/nginx/modsecurity/crs/crs-setup.conf
Include /etc/nginx/modsecurity/crs/rules/*.conf
CRS содержит сотни правил, разбитых по категориям: инъекции (941xxx), XSS (941xxx), LFI (930xxx), RCE (932xxx), сканеры (913xxx).
Настройка уровня защиты CRS
# crs-setup.conf
SecDefaultAction "phase:1,log,auditlog,pass"
# Уровень паранойи: 1 (минимум ложных срабатываний) — 4 (максимум правил)
SecAction \
"id:900000, \
phase:1, \
nolog, \
pass, \
t:none, \
setvar:tx.paranoia_level=2"
Начинают с уровня 1 в DetectionOnly-режиме, анализируют ложные срабатывания, постепенно повышают.
Cloudflare WAF: кастомные правила
# Правило: блокировать запросы с подозрительным User-Agent
(http.user_agent contains "sqlmap") or
(http.user_agent contains "nikto") or
(http.user_agent contains "masscan")
→ Action: Block
# Блокировать попытки обхода директорий
(http.request.uri.path contains "../") or
(http.request.uri.path contains "..%2F")
→ Action: Block
# JS Challenge для высокочастотных запросов к /api
(http.request.uri.path matches "^/api/") and
(rate(http.request.method eq "POST") > 50)
→ Action: JS Challenge
AWS WAF
# Terraform
resource "aws_wafv2_web_acl" "main" {
name = "main-waf"
scope = "CLOUDFRONT"
default_action { allow {} }
rule {
name = "AWSManagedRulesCommonRuleSet"
priority = 1
override_action { none {} }
statement {
managed_rule_group_statement {
name = "AWSManagedRulesCommonRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "CommonRuleSetMetric"
sampled_requests_enabled = true
}
}
}
Работа с ложными срабатываниями
Ложные срабатывания — главная проблема WAF. Стратегия:
- Запустить в DetectionOnly / Log-режиме на 1–2 недели
- Проанализировать audit.log — найти правила, блокирующие легитимный трафик
- Создать исключения для конкретных URI и правил
# ModSecurity — исключение правила для конкретного пути
SecRule REQUEST_URI "@beginsWith /admin/editor" \
"id:1001, phase:1, pass, nolog, ctl:ruleRemoveById=941100"
Мониторинг WAF
- ModSecurity audit.log → парсить через GoAccess или Filebeat → Elasticsearch
- Cloudflare Analytics → Security Events → фильтрация по правилам
- Алерт при резком росте блокировок — признак начинающейся атаки или сломанного приложения
Срок реализации
- Cloudflare WAF с готовыми managed rules: 4–8 часов
- ModSecurity + OWASP CRS + настройка исключений: 3–5 дней
- AWS WAF через Terraform + мониторинг: 2–3 дня







