Як WAF захищає сайт: атаки, які він зупиняє

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

Що саме прикриває WAF: вебсайт, кабінет, API

Фільтр запитів стоїть перед усім, що спілкується мовою HTTP. Це більше, ніж сторінки сайту:

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

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

Атаки, які зупиняє WAF

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

SQL-ін'єкції. Спроба підсунути в поле форми фрагмент запиту до бази даних. Розпізнається за характерними конструкціями там, де мали бути ім'я, номер чи дата.
XSS (міжсайтовий скриптинг). Вставка скрипта, який виконається у браузері іншого відвідувача. Фільтр бачить розмітку й код там, де на них ніхто не чекав.
Перебір паролів і обхід входу. Сотні спроб з одного джерела за хвилину — привід уповільнити або відхилити запити ще до того, як застосунок їх обробить.
Шкідливі боти й скрапери. Автоматичний збір цін і контенту, накрутки, зловживання формами. Ознаки — ритм звернень, порядок сторінок, дивні заголовки, репутація адреси.
HTTP-флуд. Прикладний рівень DDoS-атаки: сайт «завалюють» начебто звичайними запитами до найважчих сторінок. Фільтр обмежує частоту й відсіює джерела, які поводяться інакше, ніж люди; це частина комплексного захисту від DDoS.
Сканування чутливих шляхів. Масовий перебір адрес: адміністративні панелі, службові файли, забуті архіви з резервними копіями. Такі звернення відсікають ще до того, як вони дійдуть до застосунку.
Експлуатація відомих вразливостей. Спроби скористатися дірою в CMS чи плагіні, поки виходить оновлення. Тут працює правило-заглушка: воно блокує саме той шаблон запиту, яким користуються зловмисники.
Завантаження шкідливих файлів. Перевірка типу, розміру та вмісту того, що надсилають у форму завантаження.

Як фільтр відрізняє бота від людини

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

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

Саме тому WAF-рішення завжди балансує між суворістю й хибними спрацюваннями: надто жорсткі правила відсікають разом із ботами й живих клієнтів.

Чого WAF не зупинить

Найважливіша частина, про яку мовчать презентації. Фільтр бачить запити, а логіку вашого бізнесу — ні.

Порушення контролю доступу. Якщо користувач змінює в адресі номер замовлення й бачить чуже — запит цілком легітимний за формою. Для фільтра він нічим не відрізняється від звичайного. У переліку OWASP Top 10 цей клас посідає перше місце — і це саме той випадок, де WAF допомагає найменше.
Вкрадені або слабкі паролі. Вхід із правильними даними виглядає нормальним. Тут рятує двофакторна автентифікація, а не фільтр запитів.
Логічні вразливості. Знижка, яку можна застосувати двічі; крок оплати, який можна пропустити. Формально жодного «шкідливого» запиту немає.
Дірки в залежностях, для яких ще немає правила. Поки прийом атаки невідомий, розпізнавати нема за чим.

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

Чи достатньо WAF? Кібербезпека сайту не зводиться до одного фільтра

Робочий мінімум навколо WAF-захисту:

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

WAF — безпека того шару, куди мережевий екран не дістає. Решту шарів доводиться закривати іншим.

Як зрозуміти, що фільтр працює

Три ознаки, що все налаштовано по-справжньому:

У журналі є заблоковані запити. Порожній журнал означає не тишу, а вимкнене блокування або надто м'які правила.
Ви знаєте, що саме блокується. Заблокований клієнт має помічатися швидше, ніж він устигне піти до конкурента.
Правила змінюються разом із сайтом. Кожен реліз із новими формами — привід переглянути винятки.
Ви перевіряли його самі. Навмисно надіслати підозрілий запит зі своєї адреси й побачити відмову — найпростіший спосіб пересвідчитися, що WAF-захист увімкнений, а не просто оплачений.

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

Хочете надійно закрити свій сайт? Фахівці з кіберзахисту допоможуть підібрати й налаштувати WAF та інші засоби під вашу інфраструктуру — отримати консультацію.