Web Application Firewall и защита от атак
Краткое резюме
WAF/WAAP фильтрует и контролирует HTTP(S)/WebSocket-трафик на уровне приложения: блокирует эксплуатацию уязвимостей (OWASP Top 10), попытки обхода аутентификации, сканирование, автоматизированный бот-трафик и L7 DDoS. Современный стек дополняется анти-бот-движком, API-защитой, rate limiting, виртуальными патчами, а также тесной интеграцией с CI/CD, чтобы правила выкатывались так же безопасно, как код.
Роли и место в архитектуре
Edge/CDN WAF (облако): низкая латентность, глобальная репутация/Managed Rules, L7 DDoS.
Self-hosted WAF (on-prem/K8s): глубокая интеграция с внутренними сетями, тонкая настройка.
WAAP-подход: WAF + API-Gateway функции (schema-validation, authZ), анти-бот, L7 DoS, mTLS.
Схемы включения: Reverse-proxy перед приложением; Ingress-контроллер в K8s; Service Mesh фильтры; sidecar.
Модель защиты
Negative security (подписи/CRS): быстрое покрытие известных техник (SQLi/XSS/SSRF/RCE).
Positive security (allow-list): разрешаем только «валидные» запросы (методы/пути/схемы/типы контента).
Virtual Patching: оперативная блокировка эксплойта до фикса кода.
Контекстность: разные политики для статического контента, API, админок, загрузок, вебхуков.
Типовые угрозы и меры
OWASP Top 10: SQLi, XSS, IDOR/BOLA, SSRF, инъекции в шаблонизаторах, десериализация, мисконфиги.
L7 DDoS: медленные запросы/заголовки, burst на горячие эндпоинты → защита: rate-limits, challenge, авто-блок.
Боты/скрейперы: поведение, частота, «нечеловеческие» паттерны, device-фингерпринтинг, динамические токены.
Credential Stuffing/ATO: перехват/перебор логинов → аномалия по IP/ASN, velocity rules, доп. факторы.
Загрузки: тип/размер/мультискан антивирусом, «image-only» в медиазонах.
API/GraphQL: schema-validation, `maxDepth`/`maxCost`, запрет ненаказуемых wildcard, контроль методов и заголовков.
Политики и конструкторы правил
Базовый «скелет» для любого приложения:1. Транспорт: TLS 1.2+/1.3, HSTS, mTLS на чувствительных бэкендах.
2. Методы: allow-list (`GET, POST, PUT, DELETE, PATCH, OPTIONS`) уникально на ресурс.
3. Пути: строгие маски/регэкспы; админка/биллинг — на отдельный префикс/домен.
4. Заголовки: белые списки, запрет опасных (`X-Original-URL`, нестандартные) без нужды.
5. Тела: JSON-only/Multipart-only по маршруту; лимиты `Content-Length`, блок бинарей на «логин/поиск».
6. Rate limits: per-IP/ASN/ключ/организация; отдельные лимиты на «дорогие» запросы.
7. Анти-бот: поведенческий скоринг, «нераздражающие» челленджи, склейка идентичностей (cookie-токены, JA3/TLS FP).
8. CRS/Managed Rules: включены, тюнинг под FP.
9. Вирт-патчи: быстрая блокировка известных параметров/шаблонов атак.
10. Логи/метрики: единый формат, корреляция с `trace_id`, отчеты об FP/TP.
Практика тюнинга: как снизить ложные срабатывания
Запускать новые правила в Detect-only/Count-mode (shadow) с выборкой трафика.
Создавать исключения по контексту (`path=/search`, `param=q` разрешить спецсимволы).
Делить зону: «публичные страницы» vs «чувствительные операции» (порог агрессивности разный).
Конвейер: правило → стейджинг → канарейка (1–5%) → прод; rollback по метрикам FP.
Вести каталог «ложных» payload для регрессионных тестов.
Интеграция в DevSecOps
CI: статические правила в Git; тесты: реплей реальных запросов + синтетика из каталога атак.
CD: канареечные выкладки, флаги фичей; «политический» мониторинг (изменение правил = change).
RASP и SAST/DAST: WAF дополняет, но не заменяет исправление кода.
Наблюдаемость и SLO
Метрики:- p95/99 латентности через WAF; доля заблокированных/пропущенных; share Managed Rules vs custom; «attack rate».
- Анти-бот: доля челленджей/сдач, FP/TP.
- L7 DDoS: burst-rate, auto-mitigation events.
- «Не более 0.5% FP на авторизованные операции/сутки».
- «p95 overhead WAF ≤ 10 мс».
- «TTR виртуального патча ≤ 30 минут».
- Алармы: всплеск 4xx/5xx после релиза правил; рост FP; падение прохождения капч; деградация JWKS/мТLS-валидации.
Примеры конфигураций
ModSecurity + OWASP CRS (Nginx)
nginx
Enabling ModSecurity modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main. conf;apache
SecRuleEngine On
Include /usr/local/owasp-modsecurity-crs/crs-setup. conf
Include /usr/local/owasp-modsecurity-crs/rules/.conf
Example of an exception for a search parameter
SecRule REQUEST_URI "@beginsWith /search" "id:900100,phase:1,pass,nolog,ctl:ruleRemoveByTag=attack-xss"
SecRule REQUEST_URI "@beginsWith /search" "id:900101,phase:2,pass,ctl:ruleRemoveTargetById=942100; ARGS:q"AWS WAF (JSON, rate limit + блок списка стран)
json
{
"Name": "prod-web-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "BurstLogin",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": { "ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
"PositionalConstraint": "CONTAINS"
}}
}
},
"Action": { "Block": {} },
"VisibilityConfig": { "MetricName": "BurstLogin", "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true }
}
]
}Cloudflare (Expression Rules)
(http. request. uri. path contains "/admin" and ip. geoip. country ne "UA")
or (http. request. uri. path eq "/login" and cf. threat_score > 10)
or (http. request. uri. path contains "/api" and not http. request. headers["authorization"][0] contains "Bearer ")NGINX: простое правило по методам/телам
nginx location /api/withdraw {
limit_except POST { deny all; }
if ($request_method = POST) {
set $cl $http_content_length;
if ($ cl = "") {return 411;} # length is required if ($ cl> 1048576) {return 413;} # ≤ 1MB add_header X-Idempotency-Required "true";
}
}GraphQL: ограничители
`maxDepth=6`, `maxCost=1000`, запрет `__schema` в проде, allow-list операций, валидация заголовков (`Content-Type: application/json`).
Анти-бот и человеко-дружественные проверки
Invisible challenge (JS-челленджи без капчи), proof-of-work на «дорогих» путях, поведенческая аналитика (движения/тайминги).
TLS/JA3-фингерпринтинг, IP/ASN репутация, списки прокси/VPN (в разумных пределах).
Ловушки (honeypot-поля) на формах, динамические токены формы/сеанса.
Защита приватности: минимизация трекинга, прозрачные политики, опции opt-out.
API-фокус
Schema-first: OpenAPI/JSON Schema для валидации; запрет лишних полей.
Auth: обязательно Bearer JWT или mTLS; reject без `Authorization`.
Rate/Quota: per-key/per-org; при превышении — «soft block»/slowing.
Webhooks: подпись HMAC, `timestamp+nonce`, короткое окно приема.
GraphQL: см. ограничители выше; логировать имя/метку операции.
Загрузки и медиа
Лимит размера, whitelists MIME/расширений, переименование файлов;
AV-скан (мульти-движки), ImageMagick policy (без опасных декодеров);
Thumb-сервис на отдельном домене, serve-only-images.
Безопасность админок и критичных зон
Отдельный домен/путь, mTLS/запрет с общих ASN/стран, жесткие rate limits, JIT-доступы, IP allow-list.
Дополнительные сигналы (device posture, risk score) → требовать вторую проверку.
Операции, инциденты и виртуальные патчи
Runbook: быстрый выпуск block-правила, TTL-ограничение, уведомление команд.
Критерии отката: рост 4xx/5xx>порог, FP>порог, p95 latency↑.
Post-mortem: добавление теста в регрессионный набор правил, фиксация SIGMA-алерта в SIEM.
Комплаенс и приватность
Логировать минимум: путь/метод/код/причина блока/идентификаторы; не хранить PII/секреты тела.
Сроки хранения логов по политике; доступ — по ролям; шифрование на диске.
Особенности для iGaming/финтех
Платежи/выплаты/кошельки: per-org квоты, мTLS к PSP, строгие allow-листы путей, HMAC для вебхуков PSP.
ATO/бонус-абьюз: velocity-правила на логин/регистрации/промокоды, поведенческие лимиты и анти-бот.
Контент-провайдеры/студии: отдельные домены/политики, IP/ASN allow-list, мониторинг Time-to-Wallet/конверсий на влияние WAF.
Региональные требования: гео-политики (страны/регионы), прозрачность обработок для GDPR.
Дорожная карта внедрения
1. Инвентаризация зон (публичные, API, админка, загрузки).
2. Базовый профиль: TLS, методы/пути allow-list, Managed Rules/CRS.
3. Rate limits + анти-бот на чувствительных путях.
4. Виртуальные патчи и процесс срочных правил (SLA ≤ 30 мин).
5. CI/CD для правил, стейджинг/канарейка/shadow-mode.
6. Телеметрия, SLO, регрессионные тесты правил.
7. Периодический review исключений и «чистка» обходов.
Типичные ошибки
«Включили все CRS на максимум» → лавина FP и выгорание команды.
Правила без канареек и shadow-режима.
Отсутствие сегментации: одна политика для всего.
Игнор API/GraphQL специфики (schema/limits).
Логи без корреляции (`trace_id`) и без метрик качества.
FAQ
WAF заменяет безопасный код?
Нет. Это слой смягчения и «виртуальный патч», но технический долг в коде устранять обязательно.
Как понять, что пора включать жесткие блоки?
Когда отчет по shadow-режиму показывает низкий FP и есть регрессионные тесты правил.
Нужен ли отдельный WAF для API?
Лучше WAAP/интеграция с API-шлюзом: схема, лимиты, аутентификация, подписи вебхуков.
Итог
Эффективный WAF/WAAP — это сочетание базовых CRS/Managed Rules, позитивной модели, анти-бота, лимитов и виртуальных патчей, подкрепленное процессами DevSecOps, телеметрией и четкими SLO. Такой подход обеспечивает быструю реакцию на уязвимости, устойчивость к автоматизированным атакам и предсказуемое влияние на UX и производительность.