Резервування LiveShield: що відбувається при відмові воркера, аналізатора чи цілої локації?

Воркер LiveShield потрібен окремо на кожній локації, де приймається трафік від аплінка, оскільки він аналізує локальну копію трафіку, отриману через дзеркалювання порту (SPAN) або оптичний TAP. Аналізатор і менеджер, модулі, що відповідають за рішення щодо мітигації та конфігурацію, натомість можна централізувати.

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

Воркер LiveShield аналізує трафік, який фізично до нього надходить, тобто копію трафіку з локального дзеркала порту або лінку TAP, підключеного до крайового маршрутизатора чи комутатора на певній локації. Якщо мережа має дві незалежні локації з окремими сесіями BGP до аплінків, кожна з них потребує власного воркера, підключеного до локального джерела трафіку. Воркера не можна «відправити» на віддалену локацію через мережу, бо тоді він мав би приймати сирий трафік через WAN-канал, що неефективно і на практиці нездійсненно за більших пропускних здатностей.

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

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

Приклад: якщо поріг виявлення UDP встановлено на 5 Гб/с на обох локаціях окремо, зловмисника, який надсилає по 3 Гб/с через кожну з них (разом 6 Гб/с), не буде виявлено в жодній із них, хоча реальна атака перевищує закладений поріг.

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

LiveShield працює в архітектурі поза шляхом виробничого трафіку (off-path): воркер аналізує копію трафіку, отриману з дзеркала, а не трафік, що фізично проходить через пристрій. Тому відмова воркера не переривається виробничий трафік на відповідній локації. Втрачається лише здатність виявляти нові атаки та реагувати на них, доки воркера не буде відновлено.

Це принципова відмінність від рішень, що працюють inline, де відмова фільтрувального пристрою може безпосередньо призвести до перерви в трафіку клієнтів.

Резервування LiveShield у мережі з кількома локаціями ґрунтується на двох принципах: воркер має працювати окремо на кожній локації, бо потребує локального джерела трафіку, а аналізатор і менеджер слід централізувати, щоб виявлення ґрунтувалося на повній картині трафіку з усіх локацій одночасно. Завдяки архітектурі off-path відмова воркера не переривається виробничий трафік, а лише обмежує здатність виявляти нові атаки до його відновлення.

Чи достатньо одного воркера LiveShield для мережі з двома локаціями? Ні, якщо обидві локації мають незалежні сесії BGP до аплінків і приймають трафік окремо: кожна з них потребує власного воркера, підключеного до локального дзеркала трафіку.

Чи потрібно встановлювати аналізатор і менеджер окремо на кожній локації? Не рекомендується. Один спільний аналізатор для всіх локацій дає повну картину трафіку й підвищує точність виявлення порівняно з окремими незалежними конфігураціями.

Чи переривається трафік клієнтів у разі відмови воркера? Ні. LiveShield працює в архітектурі off-path, аналізуючи копію трафіку з дзеркала порту або лінку TAP. Відмова воркера обмежує здатність виявляти нові атаки, але не впливає на виробничий трафік, що проходить через мережу.