Чим небезпечний невідфільтрований трафік: налаштування AWS WAF
Невідфільтрований трафік майже ніколи не виглядає як атака — він виглядає як зростання затримок. Пул обробників займають однотипні запити до форм, пошуку та авторизації, вільні з'єднання закінчуються, і застосунок перестає приймати нові звернення.
Черга зростає, особистий кабінет відповідає помітно повільніше, а частина запитів відвалюється за часом очікування ще до того, як потрапить у бізнес-логіку.
Відмова під навантаженням настає раніше, ніж встигає допомогти автомасштабування: новий екземпляр піднімається довше, ніж триває сплеск, а сам трафік розподілений по сотнях адрес, тому блокування всередині застосунку не дають ефекту.
Штатні засоби захисту такого перевантаження веб-застосунку не бачать: підозрілі запити синтаксично коректні, звертаються до наявних адрес і відрізняються лише щільністю та розкидом джерел.
Налаштування AWS WAF переносить фільтрацію на периметр — до того, як запит займе обробник.
Керовані набори правил відсікають відомі класи атак, правила обмеження частоти тимчасово блокують джерело, що перевищило поріг, а перевірка ознак автоматизації відокремлює ботів від живих користувачів.
Усі рішення потрапляють до журналу, тому видно, яке правило спрацювало і чи не зачепило воно реальних клієнтів.
Далі розбираємо, як вибудовується такий захист: де проходить межа фільтрації, як підбираються пороги під профіль вашого трафіку і що робити з хибними спрацюваннями, щоб не втратити замовлення.
Що дає керована фільтрація запитів на периметрі
Фільтрація запитів на периметрі вирішує одне завдання: сміттєвий трафік не повинен доходити до застосунку та бази. Без неї потік сканерів, ботів і переборів облікових даних займає з'єднання, гріє шаблони й навантажує базу запитами, які ніколи не стануть замовленням.
Профіль навантаження стає рваним: корисні користувачі чекають у черзі за тими, хто просто перебирає адреси.
AWS WAF ставиться перед застосунком і працює на рівні окремого запиту, а не з'єднання. Правила описують, що вважати нормою: частота звернень з однієї адреси, характерні сигнатури типових атак, неприпустимі методи й розміри тіла.
Керовані набори правил закривають поширені класи автоматизованих атак, а власні правила додають специфіку конкретного продукту — наприклад, обмеження на часті звернення до форм входу або до пошуку.
Ключовий ризик тут — хибні спрацювання: заблокований живий користувач дорожчий за пропущеного бота. Тому нові правила спочатку вмикаються в режимі підрахунку й не блокують трафік, а лише пишуть події.
За журналом відсічених запитів видно, які шляхи та заголовки потрапили під правило, після чого пороги підкручуються до вмикання блокування.
Результат вимірюється трьома числами: частка запитів, відсічених до застосунку, час відповіді під піковим навантаженням і кількість звернень до бази. На типовому вебі частка відсіченого сміття — десятки відсотків, і саме вона виходить з черги до застосунку.
Застосунок отримує рівний потік, стабільність під навантаженням перестає залежати від того, хто сьогодні сканує периметр, а журнал залишається робочим інструментом, а не архівом.
Варіанти захисту периметра: що обирають і чому
Вибір підходу залежить від передбачуваності легітимного трафіку та від того, де застосунок приймає запити. Готові набори правил закривають типові класи атак майже одразу після підключення, але пороги в них усереднені й на нестандартних сценаріях дають хибні спрацювання.
Тому старт — режим спостереження: правила рахують збіги й не блокують, а логи показують, які шляхи та параметри потрапляють під підозру.
Власні правила фільтрації описують логіку конкретного застосунку: частоту звернень до форми входу, допустимі значення параметрів, порядок викликів API. Вони точніші, але потребують супроводу — зміна сценарію може потребувати правки умов.
Обмеження фільтрації на периметрі теж варто враховувати: вміст захищеного каналу розбирається не повністю, а розподілений перебір облікових даних видно лише в застосунку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готові набори правил | Стандартний вебпроєкт, потрібен базовий бар'єр швидко | Усереднені пороги, хибні спрацювання на нестандартних сценаріях |
| Власні правила фільтрації | Нестандартні форми, публічний API, багато автоматизованих звернень | Потрібні тестовий контур і регулярний перегляд умов |
| Режим спостереження | Перший етап впровадження або зміна схеми трафіку | Не захищає: запити доходять до застосунку |
| Захист лише на боці застосунку | Внутрішні сервіси, трафік яких не йде через периметр | Навантаження на застосунок, ресурси витрачаються до перевірки |
На практиці варіанти комбінують: спостереження на готових наборах, потім власні правила під логіку застосунку й переведення в блокування за підтвердженими спрацюваннями.
Етапи впровадження: від аудиту трафіку до передачі регламентів
Налаштування AWS WAF, розпочате одразу з блокувальних правил, майже завжди зачіпає живий трафік: під фільтр потрапляють інтеграції, платіжні сценарії та мобільні клієнти.
Тому ми йдемо від спостереження до обмеження — спершу знімаємо картину запитів, потім збираємо схему правил і лише після цього вмикаємо блокування. Порядок етапів фіксований: на кожному кроці видно ефект, а відкат займає одну операцію.
- Аудит трафіку та точок входу. Збираємо статистику за адресами, методами, заголовками й часткою автоматизованих клієнтів — отримуємо базову лінію, з якою звіряємо все подальше.
- Схема правил. Розкладаємо загрози за пріоритетами: що блокуємо жорстко, що обмежуємо за частотою запитів, що поки лише пишемо в журнал.
- Увімкнення в режимі спостереження. Правила рахують збіги, але не заважають відвідувачам: видно, кого зачепило б блокування, без впливу на конверсію та доступність.
- Розбір хибних спрацювань. За журналами виводимо з-під фільтра службові адреси, обмін із зовнішніми системами та повернення від платіжних провайдерів.
- Перехід у блокування. Правила вмикаємо по одному, з планом відкату й порогом, після якого автоматично повертаємося в спостереження.
- Перевірка на бойовому трафіку. Стежимо за часткою відмов, часом відповіді та проходженням ключових сценаріїв під навантаженням і в години пік.
- Передача регламентів. Віддаємо карту правил, порядок додавання винятків, чергові сценарії та точки ескалації.
Конфігурації правил, схема трафіку та регламенти реагування
Налаштування AWS WAF не закінчується вмиканням фільтра — воно закінчується комплектом артефактів, який ваша команда може відкрити, прочитати й застосувати без нас.
Нижче — що залишається у вас після робіт: файли конфігурації, схема проходження трафіку, політики доступу та інструкції на випадок інциденту.
- Конфігурація правил — опис кожного набору: що блокує, що лише рахує, у якому порядку спрацьовує. Зберігається декларативно, щоб правило відкочувалося однією зміною.
- Схема проходження трафіку — шлях запиту від вхідної точки до застосунку з позначеними місцями перевірки та поведінкою при спрацюванні: блокування, перевірка або пропуск із записом.
- Політики доступу — дозволені джерела, службові діапазони адрес, порядок винятків для внутрішніх перевірок і партнерських інтеграцій.
- Регламент реагування — хто отримує повідомлення про сплеск блокувань, як відрізнити атаку від помилки в самому правилі й коли правило переводиться в режим спостереження.
- Інструкція з аварійного режиму — покрокове зняття обмежень, якщо захист почав відсікати живих користувачів, із зазначенням відповідального.
- Документація із захисту — паспорт конфігурації: дата останньої зміни, хто вніс і навіщо, які маршрути це зачіпає.
- Чек-ліст після релізу застосунку — умови, за якими нова версія вважається коректно захищеною, і порядок перевірки на копії середовища.
Правила переглядаються за розкладом, а не за фактом аварії: раз на квартал звіряємо конфігурацію з поточною схемою застосунку — нові маршрути та форми легко випадають з-під захисту.
Впровадження на бойовому проєкті: метрики до та після
Сервіс із високою часткою зовнішнього трафіку — каталог з особистими кабінетами та формами — тримав усю фільтрацію всередині застосунку.
При сплеску автоматичних запитів (парсери, перебір форм, часті звернення до пошуку) пул застосунків ішов у перевантаження: черга зростала, частина живих користувачів бачила помилки, а черговий інженер до пів години шукав джерело й перезапускав вузли.
Що змінили і що вийшло
Фільтрацію підняли на периметр — на AWS WAF. Спершу правила працювали в режимі спостереження: рахували, яку частку трафіку відсікли б, і звіряли з логами, щоб не зачепити легітимних роботів.
Потім увімкнули блокування: сигнатурні правила для типових атак, ліміти за частотою запитів на адресу й на сесію, окремі набори для форм і програмних інтерфейсів, списки винятків для пошукових систем.
Частка запитів, відсічених на периметрі, у години сплесків сягала третини вхідного потоку — застосунки перестали бачити цей трафік узагалі. Час реакції на інцидент скоротився з годин до хвилин: нове правило вводиться правкою конфігурації, а не релізом коду. Окремо налаштували оповіщення щодо зростання блокувань, щоб зміна шаблону атаки була видна одразу.
Усунений клас відмов — переповнення пулу застосунків під автоматичним сплеском і помилки в живих користувачів слідом. Відкат — переведення правила в режим підрахунку або його вимкнення, без збірки й викочування: неправильне налаштування не валить сервіс.
Чим WAF відрізняється від захисту від масових атак і мережевого екрана?
Це три різні шари, які дивляться на трафік із різною глибиною. Мережевий екран і правила груп безпеки працюють із пакетами: адреса джерела, порт, протокол. Для них спроба ін'єкції в параметрі форми або підробка cookie — звичайний дозволений запит до вебсервера.
Захист від масових атак вмикається ще раніше й оцінює профіль потоку: сплеск однотипних звернень відсікається на периметрі, до того як він дійде до балансувальника й застосунків.
AWS WAF розбирає вміст запиту прикладного рівня: метод, шлях, заголовки, параметри рядка запиту, тіло та cookie.
Тут працюють керовані набори правил під поширені класи атак, власні умови за конкретними формами й адресами, а також правила обмеження частоти звернень за адресою або сесією.
Тому фільтр запитів ловить те, що для мережевого екрана невідрізненне від живого користувача: експлуатацію форм, перебір облікових даних, автоматизований обхід каталогу.
Межа відповідальності проходить за логікою застосунку. WAF не перевіряє права доступу, не валідує бізнес-правила й не заважає оформити замовлення на чужий рахунок — це завдання коду.
Але й застосунок не повинен бути єдиною лінією оборони: без фільтрації на периметрі кожна спроба перебору доходить до сервера й витрачає його ресурси нарівні з корисним трафіком.
Робоча схема — поєднання рівнів із зрозумілим порядком проходження. Масові атаки гасить захист периметра, мережеві правила залишають відкритими лише потрібні порти, фільтр запитів обмежує частоту й відсікає шкідливий вміст, застосунок перевіряє авторизацію та цілісність даних.
Якщо шар прибрати, навантаження перерозподіляється на наступний — і відмова проявляється там, де її складніше помітити.
Часті технічні заперечення перед стартом робіт
Заперечення перед стартом майже завжди одні й ті самі, і стосуються вони не вибору правил, а ризику вронити живий трафік. Фільтр стоїть між користувачем і застосунком, тому помилка в налаштуванні видна одразу — на відміну від завдань, які можна викотити й полагодити по ходу. Нижче зібрали сумніви, які інженерні команди піднімають на першій же зустрічі.
Увімкнення фільтра зупинить сервіс на час налаштування?
Ні. Перший етап розгортаємо в режимі спостереження: правила рахують збіги й пишуть їх у журнал, але не блокують запити. Трафік іде як звичайно, а ми отримуємо реальну картину — які запити застосунок приймає і хто з легітимних клієнтів потрапляє під підозру. Переведення в блокувальний режим — окремий крок, уже після розбору журналу.
Хибні блокування відріжуть живих клієнтів?
Саме для цього й потрібен режим спостереження. За журналом видно, які правила спрацьовують на живих користувачах, і для них налаштовуються винятки — точково, за шляхом запиту або ознакою клієнта, а не вимкненням правила цілком.
Поріг піднімаємо там, де правило шумить, і залишаємо жорстким там, де воно ловить реальні спроби обходу.
Чи потрібен доступ до коду й репозиторію?
Ні. Працюємо з конфігурацією фільтра та точками входу: достатньо знати домени, маршрути й заголовки, які очікує застосунок. Доступ до вихідних кодів і баз даних не потрібен — правки в коді до завдання не входять.
Хто розбирає спрацювання після запуску?
Розбір ведемо за журналом: дивимося, що саме спрацювало, відокремлюємо автоматичні сканери від живих сесій і вирішуємо — залишити правило, звузити його чи внести адресу у винятки.
Після запуску віддаємо регламент: які звіти дивитися, з якою періодичністю і за якими ознаками розуміти, що правило час правити.
Обговоримо задачу і повернемося з планом впровадження
Щоб повернутися з оцінкою робіт, а не із загальними словами, нам потрібні вихідні дані щодо трафіку та точки входу застосунку. Опишіть задачу у вільній формі — що захищаєте, з якими інцидентами вже стикалися і який результат вважаєте успішним; решту зберемо самі під час розмови.
На дзвінку уточнимо й попросимо надіслати:
- схему точок входу — домени, балансувальники, CDN і ланцюжок запиту до самого застосунку;
- вивантаження логів за типову добу та за піковий інтервал: за ними видно профіль запитів і частку службового шуму;
- перелік відомих інцидентів — сканування, перебір облікових даних, сплески однотипних запитів;
- список легітимних ботів, партнерських інтеграцій і моніторингу, які блокувати не можна;
- поточні правила обмеження частоти й те, де вони зараз налаштовані — на балансувальнику, у застосунку чи ніде;
- вимоги до режиму роботи: починаємо зі спостереження чи одразу з блокування;
- регламент доступу й погодження змін — хто тримає панель і як затверджуються правила.
За цими даними ми розуміємо обсяг робіт і порядок етапів.
Повернемося з планом впровадження: що налаштовуємо в режимі спостереження, за який строк збираємо статистику щодо хибних спрацювань, у який момент перемикаємо правила в блокувальний режим і як відкочуємося, якщо якесь правило зачепило реальних користувачів.
Обговоримо задачу — надсилайте логи та схему, і ми повернемося з оцінкою та планом впровадження за етапами.
