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;
`/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-обмеження, повідомлення команд.
Критерії відкату: зростання 4хх/5хх> поріг, FP> поріг, p95 latency↑.
Post-mortem: додавання тесту в регресійний набір правил, фіксація SIGMA-алерта в SIEM.
Комплаєнс і приватність
Логувати мінімум: шлях/метод/код/причина блоку/ідентифікатори; не зберігати PII/секрети тіла.
Терміни зберігання логів з політики; доступ - за ролями; шифрування на диску.
Особливості для iGaming/фінтех
Платежі/виплати/гаманці: per-org квоти, мTLS до PSP, строгі allow-листи шляхів, HMAC для вебхуків PSP.
АТО/бонус-аб'юз: 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 і продуктивність.