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