Як виглядає DDoS-атака крок за кроком: від виявлення до мітигації

Більшість матеріалів про захист від DDoS описує тему на загальному рівні: «система виявляє атаку й блокує її». На практиці між першим пакетом атаки та її ефективною мітигацією відбувається кілька конкретних технічних кроків, і те, наскільки швидко й точно вони виконуються, визначає реальний вплив атаки на мережу. Нижче ми розкладаємо цей процес на фази, так, як він виглядає в середовищі оператора ISP чи дата-центру.

Перш ніж узагалі можна говорити про виявлення атаки, система захисту мусить знати, як виглядає трафік у певній мережі за нормальних умов, для окремих IP-адрес і для цілих підмереж. Без цієї точки відліку кожне рішення про те, що є аномалією, а що звичайним піком трафіку (наприклад, вечірній пік у інтернет-провайдера), було б вгадуванням. Цей етап відбувається у фоні, постійно, незалежно від того, триває атака чи ні.

DDoS-атака рідко виглядає як один зрозумілий шаблон. На практиці це найчастіше одна з кількох категорій:

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

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

Сам поріг (threshold) недостатній: ефективне виявлення мусить також відрізняти атаку, розподілену на багато адрес, від звичайного зростання трафіку в усій мережі. Тут вступає агрегація для кожної підмережі: система мусить уміти поєднати в один інцидент сотні позірно незалежних невеликих аномалій на окремих IP.

Після виявлення аномалії система мусить вирішити, як на неї відповісти. Тут у гру вступають два взаємодоповнювальні механізми, обидва на основі BGP:

BGP FlowSpec: розповсюдження точних правил фільтрації (наприклад, блокування конкретного протоколу, порту чи шаблону пакета) безпосередньо на крайові маршрутизатори, без ручного налаштування списків ACL. Для атак TCP/UDP система аналізує семпльовані пакети та генерує правило, підібране під конкретний шаблон атаки. На практиці це означає блокування зловмисного трафіку зі збереженням нормального трафіку на тій самій адресі та протоколі.

Blackholing (RTBH): радикальніший механізм, за якого трафік до атакованої адреси спрямовується в нікуди. Ефективний і миттєвий, але коштом також легітимного трафіку до цієї адреси. Класичний повний blackholing має, однак, чітку межу доцільності: заблокувати одну атаковану IP-адресу є прийнятною ціною, але коли атака розподілена на кілька сотень адрес у тій самій підмережі (carpet bombing), blackholing усього діапазону означає відсікання всіх клієнтів у цій підмережі, тобто на практиці той самий ефект, якого прагнув досягти зловмисник, лише виконаний руками оператора.

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

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

Самої класифікації «це атака» недостатньо, щоб накласти точне правило: потрібно ще знати, як саме виглядає трафік, який слід заблокувати. Тут більшість систем на основі статичних сигнатур має проблему: сигнатура, написана під один варіант атаки, не спіймає модифікований варіант, а зловмисники з часом модифікують вектори, щоб обійти відомі правила.

Замість того щоб покладатися лише на готові сигнатури, система аналізує семпльовані пакети атаки в реальному часі та постійно будує її характеристику: протокол, порти, розмір і прапорці пакетів, розподіл адрес джерела. Перше правило накладається одразу, на основі попередньої класифікації (наприклад, «блокуй UDP flood на цю адресу»), але в наступні секунди воно уточнюється в міру надходження нових зразків, щоб зрештою охоплювати якомога вужчий, фактичний шаблон атаки, а не весь трафік певного протоколу.

Це саме навчання відповідає за відстеження атаки в часі: якщо під час інциденту зловмисник змінює ціль чи вектор, система оновлює правило, замість того щоб триматися первинної класифікації. За атак типу carpet bombing це також перетворюється на динамічне розширення або звуження маски захищеної підмережі, щоб слідувати за фактичним охопленням атаки, а не за її станом у першу секунду.

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

Правило, накладене в перші секунди, не є остаточним: доки триває інцидент, механізм навчання шаблону (Фаза 3b) постійно його перевіряє й коригує. Тож система, яка лише раз наклала правило й «забула» про інцидент, тут не годиться: фільтрація лишається актуальною щодо фактичної поведінки атаки протягом усього часу її тривання, а не лише в момент виявлення.

Паралельно з мітигацією система має поінформувати відповідних осіб (e-mail, вебхук), найкраще з можливістю розділити сповіщення на різні групи клієнтів чи префікси, щоб команді NOC не доводилося вручну відфільтровувати, якого клієнта стосується певний алярм. Для операторів, на яких поширюється національна система кібербезпеки/NIS2, важливо також, щоб дані про інцидент (час, вектор, обсяг) були доступні у формі, що полегшує подальше звітування до CSIRT. Варто підкреслити: такий модуль підтримує процес звітування, але сам по собі не замінює повної програми відповідності NIS2.

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

Ефективний захист від DDoS це не окрема функція, а ланцюг рішень, що ухвалюються впродовж секунд: профіль трафіку, виявлення, класифікація, навчання шаблону атаки, вибір між FlowSpec і blackholing, розповсюдження правил, утримання фільтрації, підлаштованої під змінний вектор, і зрештою відкликання мітигації. Кожна ланка цього ланцюга, що працює повільніше чи менш точно, перетворюється на довший час недоступності сервісу або більший обсяг заблокованого легітимного трафіку.

Повний опис архітектури, конфігурації BGP і механізмів фільтрації міститься в технічній документації: docs.liveshield.net. Роботу системи можна також перевірити без зобов'язань у демоверсії: demo.liveshield.net.