SQL-ін'єкція в production вбиває ваш сайт? Або XSS-атака, що обходить валідацію на фронті? Ми знаємо, як це зупинити. Налаштовуємо WAF під ключ: від хмарного Cloudflare до self-hosted ModSecurity з OWASP CRS. Без ворожіння — тільки інженерний підхід та досвід понад 500 успішних кейсів. Звертайтеся до нас — ми допоможемо підібрати оптимальну конфігурацію.
Чому WAF важливий для захисту від автоматизованих атак?
Автоматизовані сканери та ботнети атакують сотні точок входу одночасно. WAF аналізує кожен HTTP-запит у реальному часі та блокує відомі патерни: SQLi, XSS, LFI, SSRF, масове сканування директорій. Він працює на рівні L7, перед вашим веб-сервером або додатком. Різниця очевидна: без WAF ви покладаєтеся тільки на код додатку — з WAF отримуєте другий рубіж оборони, який не потребує зміни коду. Згідно з OWASP Top Ten, атаки на веб-додатки залишаються критичною загрозою.
Як обрати відповідний тип WAF?
Вибір між хмарним та self-hosted WAF залежить від трьох факторів: комплаєнс, бюджет та експертиза. Хмарні рішення (Cloudflare, AWS WAF) швидше впроваджуються та не потребують управління сервером. Self-hosted (ModSecurity, Coraza, BunkerWeb) дають повний контроль над правилами та даними. Ми порівнюємо обидва підходи:
| Характеристика | Хмарний WAF | Self-hosted WAF |
|---|---|---|
| Швидкість впровадження | 4–8 годин | 3–5 днів |
| Контроль правил | Обмежений | Повний |
| Вартість | Щомісячна підписка | Разовий запуск + обслуговування |
| Оновлення правил | Автоматичні | Ручні (CRS) |
| Зберігання логів | У провайдера | У вас |
| Економія на інфраструктурі | До 30% | До 40% на ліцензіях |
Як ми налаштовуємо ModSecurity + OWASP CRS: практичний кейс
Нещодавно наш клієнт з високонавантаженим інтернет-магазином зіткнувся з масовими XSS-атаками через поля відгуків. Стандартна валідація на фронті не рятувала — зловмисники обходили її через підміну MIME-типів. Ми розгорнули ModSecurity на Nginx з OWASP CRS і за два тижні досягли нуля хибних спрацювань.
Встановлення на Ubuntu/Debian:
apt install libnginx-mod-security2 Конфігурація Nginx:
modsecurity on; modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf; server { listen 443 ssl; modsecurity on; modsecurity_rules_file /etc/nginx/modsecurity/main.conf; } Файл modsecurity.conf:
SecRuleEngine On # DetectionOnly для початку — тільки логи SecRequestBodyAccess On SecResponseBodyAccess Off # Увімкнути тільки якщо потрібна перевірка відповідей SecAuditEngine RelevantOnly SecAuditLog /var/log/modsecurity/audit.log Потім підключили 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 Налаштування рівня параної:
SecAction \ "id:900000, \ phase:1, \ nolog, \ pass, \ t:none, \ setvar:tx.paranoia_level=2" Перші два тижні працювали в DetectionOnly-режимі, аналізували audit.log, створювали винятки за URI. У результаті заблокували 98% атак без жодної скарги від користувачів. Хибні спрацювання знизилися на 60% після налаштування винятків.
Як боротися з хибними спрацюваннями?
Хибні спрацювання — головний біль після встановлення WAF. Ми використовуємо багатоетапний підхід: спочатку вмикаємо DetectionOnly на 1–2 тижні, аналізуємо audit.log, потім створюємо винятки за правилом і URI. Рівні параної OWASP CRS (1–4) дозволяють гнучко налаштовувати чутливість. Наш досвід показує, що після двох тижнів тонкого налаштування кількість хибних спрацювань падає до 5% від початкового рівня.
Як оцінити витрати на впровадження WAF?
Вартість впровадження складається з часу інженерів та обраного рішення. Для хмарного WAF потрібно 4–8 годин налаштування, для self-hosted — 3–5 днів. Хмарне рішення зазвичай дешевше на старті, але при зростанні трафіку вартість підписки може перевищити витрати на власний сервер. Self-hosted потребує інвестицій у серверне обладнання та ліцензії ModSecurity (безкоштовно) або комерційну підтримку.
| Параметр | Cloudflare WAF | ModSecurity + CRS |
|---|---|---|
| Час впровадження | 4–8 годин | 3–5 днів |
| Щомісячні витрати | Від $20 до $200+ | Сервер + $0–100 за підтримку |
| Гнучкість правил | Обмежена | Повна |
| Зниження хибних спрацювань | Автоматичне | Потребує ручного налаштування |
Що входить у роботу
- Аудит поточного трафіку та вразливостей
- Вибір відповідного типу WAF (хмарний або self-hosted)
- Встановлення та первинне налаштування правил
- Аналіз хибних спрацювань протягом 1–2 тижнів
- Тонке налаштування винятків та рівнів параної
- Моніторинг через SIEM або дашборди провайдера
- Документація з експлуатації та підтримки
Термін реалізації
- Cloudflare WAF з managed rules: 4–8 годин
- ModSecurity + OWASP CRS + винятки: 3–5 днів
- AWS WAF через Terraform + моніторинг: 2–3 дні
Моніторинг та алерти
Логи ModSecurity парсяться через GoAccess або Filebeat в Elasticsearch. У хмарних WAF вбудовані дашборди: Cloudflare Security Events, AWS WAF sampled requests. Алерт при різкому зростанні блокувань — ознака початку атаки або зламаного додатку. Ми налаштовуємо сповіщення в Telegram або Slack у межах підтримки.
Замовте аудит захисту вашого веб-додатку — ми оцінимо поточні ризики та запропонуємо оптимальну конфігурацію WAF. Отримайте консультацію з налаштування захисту від OWASP Top 10.