Що відбувається, коли DDoS-атака перевищує пропускну здатність аплінка?
Що відбувається, коли DDoS-атака перевищує пропускну здатність аплінка?
Коли DDoS-атака перевищує пропускну здатність каналу аплінка, жодна фільтрація, запущена локально в оператора, не здатна зарадити: канал уже фізично насичений до того, як трафік досягне фільтрувального пристрою. У такій ситуації єдиним ефективним механізмом є RTBH (Remotely Triggered Black Hole), анонсований у бік транзитного оператора, який відкидає трафік ще до входу на канал клієнта.
Це одне з перших запитань, що звучать у розмовах з ISP та операторами дата-центрів про впровадження захисту від DDoS, і слушно: це не теоретичний сценарій, а буденність у мережах, що обслуговують абонентський трафік і хостинг.
Чому локальна фільтрація не зупинить атаку, більшу за канал
Системи захисту від DDoS на основі BGP FlowSpec, зокрема LiveShield, аналізують трафік і генерують точні правила фільтрації, що встановлюються на крайових маршрутизаторах оператора. Цей механізм працює дуже добре, поки проблемою є характер трафіку, а не його обсяг відносно доступної смуги.
Критична точка виглядає так: FlowSpec анонсується локально, на маршрутизаторах, які вже розташовані за каналом аплінка. Якщо атака генерує більше трафіку, ніж канал фізично переносить, частина цього трафіку ніколи не дійде до маршрутизатора з встановленим правилом FlowSpec: канал буде насичено раніше, незалежно від того, наскільки точним є правило фільтрації.
Іншими словами: FlowSpec розв'язує проблему якості трафіку на каналі, а не проблему його обсягу понад пропускну здатність каналу.
Коли єдиним ефективним механізмом є RTBH до аплінка
У сценарії, коли обсяг атаки перевищує пропускну здатність аплінка, єдиний механізм, що реально розвантажує канал, це RTBH (Remotely Triggered Black Hole), анонсований не на власних маршрутизаторах, а в бік транзитного оператора (аплінка).
RTBH працює на зовсім іншому принципі, ніж FlowSpec: замість точної фільтрації конкретних пакетів він повідомляє мережі транзитного оператора, що весь трафік, спрямований на певну IP-адресу (найчастіше /32), слід відкинути ще до входу на канал клієнта. Це грубе рішення, адже воно відсікає й легітимний трафік до тієї самої адреси, але ефективне там, де FlowSpec фізично не має шансів спрацювати.
LiveShield генерує правила RTBH автоматично на основі тих самих порогів виявлення, що відповідають за FlowSpec, і анонсує їх через сесію BGP, налаштовану з маршрутизатором оператора. Проте ключово, що ефективність цього механізму залежить від того, що відбувається далі, тобто від того, як швидко і яким чином транзитний оператор реагує на ці анонси.
Як LiveShield скорочує час до втручання, перш ніж спрацює RTBH в аплінка
Оскільки остаточна ефективність RTBH залежить від аплінка, перевага системи захисту від DDoS розігрується на етапі, який оператор справді контролює: як швидко атаку буде виявлено і як швидко правильне правило RTBH потрапить до транзитного оператора. Чим коротший цей час, тим коротше вікно, в якому канал лишається насиченим, перш ніж аплінк встигне зреагувати.
LiveShield аналізує трафік пакет за пакетом, у реальному часі та в пам'яті, замість того щоб спиратися на агреговані дані NetFlow чи sFlow, які за своєю природою дають картину ситуації із запізненням від десятків секунд до кількох хвилин. На практиці це означає виявлення атаки та генерацію перших захисних правил упродовж одиниць секунд від її початку, а не постфактум, коли канал уже тривалий час насичений.
Другий елемент, що скорочує час реакції, це автоматизація. Механізм event pipeline дозволяє наперед визначити, що саме має статися в момент виявлення атаки, яка перевищує певний поріг: генерація та анонс RTBH, сповіщення команди NOC, виклик зовнішнього скрипта (що запускає, наприклад, scrubbing) чи запис події в тікетну систему. Оператор не реагує вручну постфактум, а має готовий, раніше протестований сценарій, який запускається сам.
А якщо все ж потрібна повна мітигація, а не лише відсікання трафіку
Для операторів, які вже мають (або планують) договір із зовнішнім центром scrubbing, event pipeline LiveShield дозволяє поєднати виявлення атаки з автоматичним перенаправленням трафіку до такого центру, замість того щоб лише блокувати адресу через RTBH. Це не готова інтеграція «з коробки»: вона потребує налаштування під конкретну топологію мережі та конкретного постачальника scrubbing, але функціональність event pipeline це дозволяє, тож LiveShield може виконувати роль шару виявлення та ухвалення рішень і в архітектурі, що зрештою не закінчується на RTBH.
Що залежить від транзитного оператора, а що від системи захисту від DDoS
Це розрізнення варто розуміти перед впровадженням будь-якої системи захисту від DDoS, а не лише LiveShield: локальна система відповідає за виявлення атаки та генерацію коректного правила RTBH. Те, як швидко це правило реально відсікає трафік перед входом на канал, залежить від конфігурації та політики транзитного оператора, а не від системи захисту від DDoS.
На практиці це означає, що перед впровадженням захисту від волюметричних атак, які перевищують ємність каналу, ISP має домовитися безпосередньо зі своїм постачальником транзиту про таке:
- чи постачальник взагалі приймає й виконує анонси RTBH (community blackhole) від клієнта,
- яка community BGP сигналізує blackholing на боці конкретного транзитного оператора,
- скільки часу минає від анонсу маршруту RTBH до фактичного відсікання трафіку в мережі оператора,
- чи застосовує постачальник додаткові ліміти (наприклад, максимальну кількість префіксів RTBH, що приймаються одночасно),
- чи RTBH працює однаково для IPv4 та IPv6.
Без цієї розмови з аплінком система захисту від DDoS може працювати правильно, тобто виявити атаку й згенерувати правило у слушний час, і попри це не захистити канал, якщо сам аплінк не виконує отримані анонси або реагує на них надто повільно.
FlowSpec
Чи є альтернатива RTBH за атаки, більшої за канал?
Локальної альтернативи немає. Якщо обсяг атаки перевищує пропускну здатність каналу аплінка, єдиний шлях полягає у відсіканні трафіку ближче до джерела, тобто на боці транзитного оператора або ще далі, в наступних постачальників у ланцюжку. Рішення, що працюють виключно локально в клієнта, незалежно від виробника й механізму фільтрації, фізично не здатні обробити трафік, який не вміщується на каналі.
Тому під час проєктування захисту від DDoS для мереж ISP варто з самого початку розглядати RTBH до аплінка як невід'ємну частину архітектури, а не як запасний механізм, що вмикається лише у виняткових випадках.
Підсумок
DDoS-атака, що перевищує пропускну здатність каналу аплінка, це сценарій, у якому локальної фільтрації трафіку (FlowSpec) стає недостатньо, бо канал насичується до того, як трафік досягає фільтрувального пристрою. Єдиним ефективним механізмом у цій ситуації є RTBH, анонсований транзитному операторові, а його реальна ефективність залежить від політики та швидкості реакції цього оператора. Тому домовленості з постачальником транзиту мають бути частиною підготовки до впровадження захисту від DDoS, а не елементом, який пропускають до першої великої атаки.
Найчастіші запитання
Чи зупинить FlowSpec атаку, більшу за мій аплінк? Ні. FlowSpec анонсується на маршрутизаторах клієнта, які вже розташовані за каналом аплінка. Якщо атака насичує цей канал, частина трафіку ніколи не дійде до правила фільтрації.
Що таке RTBH і чим він відрізняється від FlowSpec? RTBH (Remotely Triggered Black Hole) це механізм, що відсікає весь трафік, спрямований на певну IP-адресу, і анонсується транзитному операторові, завдяки чому трафік відкидається ще до входу на канал клієнта. На відміну від FlowSpec він не фільтрує точно: блокує адресу цілком разом із легітимним трафіком.
Чи кожен транзитний оператор виконує анонси RTBH? Це залежить від конкретного постачальника транзиту й потребує узгодження безпосередньо з ним, зокрема щодо прийнятої community BGP та часу реакції на анонс.
