WAF: що це і чому звичайного фаервола замало для веб-застосунків
WAF (Web Application Firewall) — що це, як він працює, чим відрізняється від мережевого фаервола, які моделі правил існують і чого WAF не замінює.
Ситуація типова: на сервері налаштований міжмережевий екран, порти закриті, адміністративний доступ обмежений — а сайт усе одно зламали. Причина проста: класичний фільтр трафіку не розуміє, що відбувається всередині дозволеного вебзапиту. Саме цю прогалину закриває WAF.
WAF — що це і як розшифровується
WAF (Web Application Firewall) — це спеціалізований захисний засіб для вебзастосунків. Він працює на рівні HTTP та HTTPS: розбирає самі запити до сайту — їхні параметри, заголовки, вміст форм, поведінку джерела — і блокує ті, що виглядають як атака, пропускаючи решту.
Web Application Firewall — визначення: засіб, який аналізує обмін між браузером і вебзастосунком за правилами прикладного рівня та відхиляє запити, що порушують ці правила. Простіше кажучи, мережевий екран перевіряє конверт, а WAF читає лист.
Чому звичайного фаервола замало
Класичний firewall вирішує, звідки й куди йде з'єднання: адреса, порт, протокол, стан сеансу. Для нього запит на сторінку входу та спроба вкрасти базу даних через ту саму форму — однаковий трафік на дозволений порт 443.
WAF дивиться на інший шар. Він знає, що таке параметр форми, cookie, заголовок і маршрут, тому здатен помітити:
- підозрілу конструкцію в полі, куди мали ввести прізвище;
- сотні спроб входу з одного джерела за хвилину;
- запит до адміністративного маршруту від випадкового відвідувача;
- аномальний обсяг або частоту звернень до однієї сторінки.
Мережевий фільтр цього не бачить у принципі — не тому, що погано налаштований, а тому, що працює на іншому рівні. Як саме він ухвалює рішення — у статті Міжмережевий екран: як працює.
Де WAF стоїть у ланцюжку
Web Application Firewall — що це з погляду інфраструктури? Посередник, крізь який іде весь вебтрафік до вашого сайту. Схема майже завжди однакова: відвідувач → WAF → вебсервер із застосунком. Засіб працює як посередник, тобто розриває з'єднання на собі, розшифровує HTTPS, аналізує запит і лише потім передає його далі — або не передає.
Звідси два практичні наслідки:
- WAF бачить розшифрований трафік. Це його сила (мережевий екран так не вміє) і водночас відповідальність: через нього проходять паролі й дані клієнтів.
- Він додає ланку до маршруту. Затримка зазвичай невелика, але вона є, тож рішення обирають з огляду на навантаження.
Дві моделі: що блокувати й що дозволяти
Правила будують за однією з двох логік, і різниця між ними важливіша за назву постачальника.
- Негативна модель (сигнатури). Блокуємо відоме погане: типові конструкції ін'єкцій, шкідливі шаблони, підозрілі заголовки. Вмикається швидко, працює з коробки, але завжди відстає від нових прийомів.
- Позитивна модель (перелік дозволеного). Описуємо, як має виглядати нормальний запит: які поля, якого типу, якої довжини, за якими маршрутами. Усе, що не вписується, — відхиляється. Надійніше, зате потребує знання застосунку й супроводу після кожного релізу — тобто когось у команді, хто відповідає за ці правила.
На практиці їх поєднують: базовий набір сигнатур закриває масові атаки, а суворі правила описують критичні місця — форму входу, оплату, завантаження файлів, адміністративну частину.
Готові набори правил і власні
Постачальники дають керовані набори правил: їх оновлюють централізовано, щойно з'являється новий масовий прийом атак. Це те, що працює одразу після підключення.
Але жоден універсальний набір не знає вашого застосунку: які маршрути адміністративні, які поля приймають лише числа, звідки взагалі мають приходити запити до платіжного модуля. Такі правила пише команда — і саме вони дають найбільше користі. Розумний мінімум: керований набір плюс кілька власних правил для критичних сторінок.
Режими роботи: спершу дивитися, потім блокувати
Помилка новачків — увімкнути блокування одразу на бойовому сайті. Правильний шлях інший:
- Моніторинг. Засіб лише позначає підозрілі запити в журналі, нічого не блокуючи.
- Аналіз. Дивимося, що потрапило в підозрілі: серед них будуть і справжні атаки, і легітимні дії користувачів.
- Тонке налаштування. Для маршрутів, де правило спрацьовує помилково, роблять винятки.
- Блокування. Вмикаємо відхилення — спершу для найкритичніших правил, потім ширше.
Режим спостереження тримають щонайменше кілька тижнів: за цей час у журнал потрапляють усі сценарії реальних користувачів, зокрема рідкісні — сезонні форми, вивантаження звітів, інтеграції з партнерами.
Хибні спрацювання — головний біль будь-якого рішення такого класу: заблокований клієнт коштує дорожче за пропущеного бота-сканера. Тому налаштування — не разова дія, а процес, який іде разом зі змінами сайту.
Журнал теж не варто лишати без нагляду: у ньому видно, що саме й коли пробували проти вашого застосунку. Ці події корисно передавати в систему збору подій безпеки — про такий підхід читайте у статті Що таке SIEM.
Що WAF не замінює
- Оновлення й безпечну розробку. Правило може прикрити вразливість, поки виходить патч, — це називають віртуальним патчуванням. Але прикриття не лікує сам дефект коду.
- Мережевий фільтр. Периметр, порти й сегментація лишаються за ним; це два різні рівні, а не конкуренти.
- Контроль доступу. Слабкі паролі й відсутність двофакторної автентифікації цей засіб не компенсує.
- Резервні копії. Якщо застосунок усе-таки зламали, відновлення залежить від бекапів, а не від фільтра запитів.
Найкращий результат дає багаторівнева схема: мережевий екран на периметрі, WAF перед застосунком, оновлений код і адекватні права доступу.
Кому потрібен WAF
Якщо сайт — це візитівка без форм і бази даних, ризик мінімальний. Якщо ж є особисті кабінети, оплата, завантаження файлів, персональні дані клієнтів або просто впізнаваний бренд — застосунок сканують щодня, і питання лише в тому, чи знайдуть дірку раніше за вас.
Окремий випадок — сайти на популярних CMS із десятком плагінів: щойно в котромусь із них оприлюднюють вразливість, масове сканування починається за кілька годин, а оновлення виходить не завжди швидко. Для платіжної сфери наявність автоматизованого рішення для захисту публічних вебзастосунків узагалі є вимогою галузевих стандартів.
Який саме тип обрати — хмарний, апаратний чи серверний — розібрано у статті Види WAF, а перелік атак, які він зупиняє, — у матеріалі Як WAF захищає сайт.