LiveShield і scrubbing center - як локальний захист від DDoS та scrubbing center можуть взаємно доповнювати одне одного

LiveShield і scrubbing center - це не рішення, між якими оператор повинен зробити остаточний вибір раз і назавжди. Це два різні рівні захисту від DDoS, які підходять для різних ситуацій і можуть працювати разом: LiveShield фільтрує більшість атак локально, у режимі реального часу і без додаткової затримки, а scrubbing center бере на себе ті випадки, коли локальної фільтрації вже недостатньо - наприклад, атаку, що перевищує пропускну здатність каналу, або таку, що потребує глибшого, stateful-аналізу трафіку.

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

Scrubbing center - це зовнішня інфраструктура, до якої в разі атаки перенаправляється трафік, спрямований на атаковану адресу - там він очищається від пакетів атаки, і лише "чистий" трафік повертається до цільової мережі. Захист on-premise, як-от LiveShield, працює навпаки: аналіз і фільтрація відбуваються локально, на обладнанні оператора, без перенаправлення трафіку назовні.

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

З іншого боку, scrubbing center має ресурс, якого зазвичай не має окремий локальний оператор - значно більшу, агреговану пропускну здатність, здатну поглинути атаку, що перевищує можливості одного каналу uplink.

Переважна більшість DDoS-атак, з якими стикаються оператори ISP, не потребує перенаправлення трафіку назовні - достатньо точної, швидкої локальної фільтрації, яку LiveShield реалізує через BGP FlowSpec, доповнюючи її blackholing (RTBH), коли локальної фільтрації вже недостатньо для конкретного каналу. Спрямовувати кожну, навіть незначну атаку до зовнішнього scrubbing center було б неефективно - це додає затримку і вартість там, де локальне правило FlowSpec впоралося б так само ефективно і швидше.

Scrubbing center має сенс як другий рівень захисту, що вмикається вибірково, для тієї меншості випадків, коли локальна фільтрація справді не справляється - насамперед атака, що перевищує пропускну здатність каналу uplink, а також атаки, що потребують stateful-аналізу трафіку, який виходить за межі того, що можна реалізувати правилами FlowSpec на прикордонному обладнанні оператора.

LiveShield за замовчуванням не працює в моделі scrubbing center - стандартно не перенаправляє трафік назовні для очищення, а мітигує атаку локально, на власних прикордонних маршрутизаторах оператора, за допомогою механізмів FlowSpec і RTBH. Однак система надає механізм event pipeline - можливість запускати будь-які дії та скрипти у відповідь на виявлення атаки.

Завдяки цьому, якщо оператор має угоду із зовнішнім scrubbing center, LiveShield можна налаштувати так, щоб за певних умов - наприклад, коли атака перевищує визначений поріг трафіку, з яким локальна фільтрація вже не здатна ефективно впоратися - автоматично запускалося перенаправлення відповідного префіксу до цього scrubbing center. Це не готова інтеграція "з коробки" для будь-якого постачальника scrubbing-послуг - вона потребує налаштування, адаптованого під конкретне середовище та конкретну угоду з партнером - але сама функціональність event pipeline це повністю дозволяє.

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

Архітектура, що поєднує локальну фільтрацію з резервним каналом до scrubbing center, має найбільший сенс там, де оператор одночасно прагне зберегти повний контроль і мінімальну затримку для звичайного трафіку та більшості атак, але також враховує сценарій атаки, яка перевищить пропускну спроможність власних каналів uplink. Саме в такій ситуації сьогодні перебувають багато невеликих і середніх операторів ISP, які спостерігають зростання масштабу волюметричних атак - звідси й беруться ініціативи зі створення спільних, "громадських" scrubbing center на точках обміну трафіком.

Для оператора, який лише починає будувати захист від DDoS, розумна послідовність зазвичай така: спочатку локальна, швидка фільтрація (FlowSpec/RTBH), що покриває переважну більшість реальних атак, а вже потім, у міру потреб і масштабу, розширення угодою зі scrubbing center як страховкою на випадок атак, що перевищують локальну пропускну спроможність каналу.

LiveShield і scrubbing center не конкурують між собою, а покривають різні рівні захисту від DDoS: локальна, швидка фільтрація FlowSpec/RTBH обробляє переважну більшість атак без додаткової затримки та вартості перенаправлення трафіку, а scrubbing center є резервним рівнем на випадок атак, що перевищують можливості локальної інфраструктури. Механізм event pipeline у LiveShield дозволяє поєднати обидва підходи в єдину, цілісну архітектуру - автоматичне перенаправлення до scrubbing center запускається лише тоді, коли це справді потрібно, а не як маршрут за замовчуванням для будь-якого трафіку.

Чи замінює LiveShield scrubbing center? Ні, і це не його роль. LiveShield за замовчуванням мітигує атаки локально, на прикордонних маршрутизаторах оператора, за допомогою FlowSpec і RTBH - це інша, доповнювальна модель щодо scrubbing center, а не його заміна для кожного сценарію.

Чи можна поєднати LiveShield із зовнішнім scrubbing center? Так. Механізм event pipeline дозволяє налаштувати автоматичне перенаправлення трафіку до зовнішнього scrubbing center у відповідь на виявлення атаки, якщо оператор має відповідну угоду - це потребує індивідуального налаштування під конкретне середовище.

Коли варто розглянути scrubbing center на додаток до локального захисту від DDoS? Насамперед тоді, коли оператор враховує сценарій атаки, що перевищує пропускну здатність власного каналу uplink - у такій ситуації локальна фільтрація фізично не здатна розвантажити канал, і рішенням є або RTBH до upstream-провайдера, або перенаправлення до scrubbing center.

Чи потрібно спрямовувати кожну атаку до scrubbing center? Ні. Переважну більшість DDoS-атак можна ефективно й швидше обробити локальною фільтрацією FlowSpec, без додаткової затримки, пов'язаної з перенаправленням трафіку назовні. Scrubbing center має сенс як вибірковий резервний рівень, а не маршрут за замовчуванням для будь-якого трафіку.