Мережева безпека

WAF: що це і чому звичайного фаервола замало для веб-застосунків

WAF (Web Application Firewall) — що це, як він працює, чим відрізняється від мережевого фаервола, які моделі правил існують і чого WAF не замінює.

calendar_today 05.07.2026 schedule 5 хв читання
WAF (Web Application Firewall) аналізує HTTP-запити до сайту й блокує шкідливі, пропускаючи легітимні

Ситуація типова: на сервері налаштований міжмережевий екран, порти закриті, адміністративний доступ обмежений — а сайт усе одно зламали. Причина проста: класичний фільтр трафіку не розуміє, що відбувається всередині дозволеного вебзапиту. Саме цю прогалину закриває WAF.

WAF — що це і як розшифровується

WAF (Web Application Firewall) — це спеціалізований захисний засіб для вебзастосунків. Він працює на рівні HTTP та HTTPS: розбирає самі запити до сайту — їхні параметри, заголовки, вміст форм, поведінку джерела — і блокує ті, що виглядають як атака, пропускаючи решту.

Web Application Firewall — визначення: засіб, який аналізує обмін між браузером і вебзастосунком за правилами прикладного рівня та відхиляє запити, що порушують ці правила. Простіше кажучи, мережевий екран перевіряє конверт, а WAF читає лист.

Чому звичайного фаервола замало

Класичний firewall вирішує, звідки й куди йде з'єднання: адреса, порт, протокол, стан сеансу. Для нього запит на сторінку входу та спроба вкрасти базу даних через ту саму форму — однаковий трафік на дозволений порт 443.

WAF дивиться на інший шар. Він знає, що таке параметр форми, cookie, заголовок і маршрут, тому здатен помітити:

  • підозрілу конструкцію в полі, куди мали ввести прізвище;
  • сотні спроб входу з одного джерела за хвилину;
  • запит до адміністративного маршруту від випадкового відвідувача;
  • аномальний обсяг або частоту звернень до однієї сторінки.

Мережевий фільтр цього не бачить у принципі — не тому, що погано налаштований, а тому, що працює на іншому рівні. Як саме він ухвалює рішення — у статті Міжмережевий екран: як працює.

Де WAF стоїть у ланцюжку

Web Application Firewall — що це з погляду інфраструктури? Посередник, крізь який іде весь вебтрафік до вашого сайту. Схема майже завжди однакова: відвідувач → WAF → вебсервер із застосунком. Засіб працює як посередник, тобто розриває з'єднання на собі, розшифровує HTTPS, аналізує запит і лише потім передає його далі — або не передає.

Звідси два практичні наслідки:

  • WAF бачить розшифрований трафік. Це його сила (мережевий екран так не вміє) і водночас відповідальність: через нього проходять паролі й дані клієнтів.
  • Він додає ланку до маршруту. Затримка зазвичай невелика, але вона є, тож рішення обирають з огляду на навантаження.

Дві моделі: що блокувати й що дозволяти

Правила будують за однією з двох логік, і різниця між ними важливіша за назву постачальника.

  • Негативна модель (сигнатури). Блокуємо відоме погане: типові конструкції ін'єкцій, шкідливі шаблони, підозрілі заголовки. Вмикається швидко, працює з коробки, але завжди відстає від нових прийомів.
  • Позитивна модель (перелік дозволеного). Описуємо, як має виглядати нормальний запит: які поля, якого типу, якої довжини, за якими маршрутами. Усе, що не вписується, — відхиляється. Надійніше, зате потребує знання застосунку й супроводу після кожного релізу — тобто когось у команді, хто відповідає за ці правила.

На практиці їх поєднують: базовий набір сигнатур закриває масові атаки, а суворі правила описують критичні місця — форму входу, оплату, завантаження файлів, адміністративну частину.

Готові набори правил і власні

Постачальники дають керовані набори правил: їх оновлюють централізовано, щойно з'являється новий масовий прийом атак. Це те, що працює одразу після підключення.

Але жоден універсальний набір не знає вашого застосунку: які маршрути адміністративні, які поля приймають лише числа, звідки взагалі мають приходити запити до платіжного модуля. Такі правила пише команда — і саме вони дають найбільше користі. Розумний мінімум: керований набір плюс кілька власних правил для критичних сторінок.

Режими роботи: спершу дивитися, потім блокувати

Помилка новачків — увімкнути блокування одразу на бойовому сайті. Правильний шлях інший:

  1. Моніторинг. Засіб лише позначає підозрілі запити в журналі, нічого не блокуючи.
  2. Аналіз. Дивимося, що потрапило в підозрілі: серед них будуть і справжні атаки, і легітимні дії користувачів.
  3. Тонке налаштування. Для маршрутів, де правило спрацьовує помилково, роблять винятки.
  4. Блокування. Вмикаємо відхилення — спершу для найкритичніших правил, потім ширше.

Режим спостереження тримають щонайменше кілька тижнів: за цей час у журнал потрапляють усі сценарії реальних користувачів, зокрема рідкісні — сезонні форми, вивантаження звітів, інтеграції з партнерами.

Хибні спрацювання — головний біль будь-якого рішення такого класу: заблокований клієнт коштує дорожче за пропущеного бота-сканера. Тому налаштування — не разова дія, а процес, який іде разом зі змінами сайту.

Журнал теж не варто лишати без нагляду: у ньому видно, що саме й коли пробували проти вашого застосунку. Ці події корисно передавати в систему збору подій безпеки — про такий підхід читайте у статті Що таке SIEM.

Що WAF не замінює

  • Оновлення й безпечну розробку. Правило може прикрити вразливість, поки виходить патч, — це називають віртуальним патчуванням. Але прикриття не лікує сам дефект коду.
  • Мережевий фільтр. Периметр, порти й сегментація лишаються за ним; це два різні рівні, а не конкуренти.
  • Контроль доступу. Слабкі паролі й відсутність двофакторної автентифікації цей засіб не компенсує.
  • Резервні копії. Якщо застосунок усе-таки зламали, відновлення залежить від бекапів, а не від фільтра запитів.

Найкращий результат дає багаторівнева схема: мережевий екран на периметрі, WAF перед застосунком, оновлений код і адекватні права доступу.

Кому потрібен WAF

Якщо сайт — це візитівка без форм і бази даних, ризик мінімальний. Якщо ж є особисті кабінети, оплата, завантаження файлів, персональні дані клієнтів або просто впізнаваний бренд — застосунок сканують щодня, і питання лише в тому, чи знайдуть дірку раніше за вас.

Окремий випадок — сайти на популярних CMS із десятком плагінів: щойно в котромусь із них оприлюднюють вразливість, масове сканування починається за кілька годин, а оновлення виходить не завжди швидко. Для платіжної сфери наявність автоматизованого рішення для захисту публічних вебзастосунків узагалі є вимогою галузевих стандартів.

Який саме тип обрати — хмарний, апаратний чи серверний — розібрано у статті Види WAF, а перелік атак, які він зупиняє, — у матеріалі Як WAF захищає сайт.