Приборкання хибних спрацювань WAF: тюнінг правил без поламаного застосунку
Хибне спрацювання — головна причина, чому WAF вимикають
Найпоширеніша смерть WAF — не обхід зловмисником, а внутрішнє рішення команди його приглушити. Сценарій завжди однаковий: фільтр заблокував легітимного клієнта — здавалося б, невинний запит із апострофом у прізвищі чи великим вкладенням, — служба підтримки отримала скаргу, і хтось у поспіху послабив правила «щоб не заважали». Через місяць захист фактично вимкнено.
Тому приборкання хибних спрацювань — це не косметика, а умова того, що WAF узагалі лишиться увімкненим. І робиться воно не грубим послабленням, а точковим тюнінгом.
Anomaly scoring: чому не блокують «з першого збігу»
Головний запобіжник проти хибних спрацювань закладений уже в самій моделі набору правил OWASP — це anomaly scoring. Замість блокування на першому ж підозрілому збігу кожне спрацьоване правило додає бали до загального рахунку запиту, і відмова настає лише тоді, коли сума перетинає поріг.
Це критично, бо один збіг рідко є доказом атаки. Поле пошуку законно може містити апостроф; довге тіло запиту може бути звичайним вкладенням. Накопичувальний рахунок вимагає, щоб запит зачепив кілька ознак атаки одразу, перш ніж його зупинять. Ми детальніше розписали цю механіку в статті про OWASP CRS українською.
Практичний висновок: часто правильний тюнінг — це не «вимкнути правило», а зважено підняти поріг чи знизити вагу конкретного правила для конкретного маршруту, лишивши решту захисту недоторканою.
Детекція перед блокуванням
Найбезпечніший спосіб вводити чи змінювати правило — спершу запустити його в режимі детекції: воно фіксує кожен збіг в аудит-логу, але нічого не блокує. Кілька днів такого спостереження показують реальну картину — що саме правило ловить на вашому справжньому трафіку, а не в теорії.
Далі цикл простий:
- Спостерігайте. Дивіться, які запити правило позначило б і скільки з них — легітимні.
- Розбирайте збіги. Аудит-лог показує не лише «заблоковано», а й які саме правила й з яким рахунком спрацювали. Це і є матеріал для тюнінгу.
- Точково коригуйте. Підніміть поріг для конкретного маршруту, зменшіть вагу надто чутливого правила чи додайте виняток для відомого легітимного шаблону — але вузько, а не «для всього сайту».
- Переводьте в блокування. Лише коли режим детекції показав чистий результат, правило вмикається на блокування.
Той самий обережний підхід «спершу спостерігай» лежить в основі віртуального патчингу — нове правило не йде одразу в бій наосліп.
Чому це можливо робити без страху
Дві архітектурні речі роблять тюнінг безпечним. По-перше, зміни правил розлітаються на всі вузли за менш ніж секунду через watch за сховищем конфігурації — тобто ви коригуєте й одразу бачите ефект, без передеплою застосунку. По-друге, кожне рішення пояснюване: незмінний (append-only) аудит-лог зберігає рахунок і перелік правил за кожним блокуванням, тож ви ніколи не тюнінгуєте наосліп.
Чого ми не обіцяємо
Ідеального нуля хибних спрацювань не існує — будь-хто, хто обіцяє «жодного легітимного запиту ніколи не заблоковано», або не блокує нічого, або не рахував. Наша мета інша: дати вам інструменти, щоб хибні спрацювання були рідкісними, видимими й точково виправними, а не приводом вимкнути захист. Накладні витрати на перевірку правил тримаються в межах проєктного бюджету затримки — як ми його вимірюємо.
Хочете WAF, який можна тонко налаштувати під свій застосунок, а не терпіти чи вимикати? Напишіть нам.