Налаштування 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 дня







