Захист від DDoS у мережі оператора: критерії вибору

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

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

Перше запитання, яке варто собі поставити: де насправді відбувається аналіз і фільтрація трафіку. Частина рішень працює on-premise, безпосередньо в інфраструктурі оператора: увесь трафік залишається в мережі, а рішення про фільтрацію ухвалюються локально. Інші перенаправляють трафік назовні, до центру очищення, яким керує постачальник.

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

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

Система захисту від DDoS, яка не інтегрується нативно з вашим BGP, це система, що потребує додаткової інтеграційної роботи. Варто перевірити, чи має рішення власний демон BGP, чи залежить від зовнішнього програмного забезпечення, а також чи підтримує і BGP FlowSpec, і RTBH (remotely triggered blackholing).

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

LiveShield має власний демон BGP і підтримує обидва механізми, FlowSpec і селективний RTBH, добираючи відповідний залежно від характеру атаки, без потреби ручного налаштування на боці оператора. Рішення протестоване на обладнанні, з яким працює більшість операторів ISP у Польщі: маршрутизатори Juniper (MX, PTX) та Cisco (ASR1k, ASR9k, NCS5500 у варіантах SE, серія 8000). Це не декларація відповідності стандарту «на папері», а перелік обладнання, на якому конфігурацію було фактично перевірено.

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

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

Оператори, на яких поширюється закон про Національну систему кібербезпеки, мають обов'язок триетапного звітування про серйозний інцидент до відповідного CSIRT: раннє попередження впродовж 24 годин від виявлення, повне повідомлення впродовж 72 годин та підсумковий звіт упродовж місяця від повідомлення. На практиці це означає, що під час атаки хтось мусить одночасно реагувати оперативно й готувати документацію відповідно до цих термінів.

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

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

Наступне запитання: на чому система взагалі має працювати. Частина рішень вимагає виділеного, закритого appliance, що означає жорстку вхідну вартість і відсутність гнучкості під час масштабування. Інші працюють на стандартному серверному обладнанні за умови, що воно відповідає певним мінімумам.

LiveShield працює на стандартному обладнанні x86 з підтримкою DPDK, без потреби інвестувати у виділений appliance. Модуль, що відповідає за обробку пакетів у реальному часі (Worker), потребує фізичної машини, це єдиний компонент із такою вимогою. Два інші модулі, Manager і Analyser, можуть працювати віртуально, що полегшує підлаштування впровадження до інфраструктури, яку оператор уже має.

Орієнтовний апаратний мінімум: кількість фізичних ядер, що обраховується за формулою Гбіт/с ÷ 10 + 4 (не менше 8 ядер), 32 ГБ+ RAM, диск NVMe від 60 ГБ і мережева карта, сумісна з DPDK. Рекомендовані моделі: Intel X710, XXV710, E810 чи X520, за потреби карти Mellanox ConnectX. Жодної залежності від одного виробника обладнання.

Моделі розрахунків сильно відрізняються між постачальниками. Частина розраховується від пропускної здатності мережі: один параметр, одна ціна, усі функції в ціні. Інші застосовують модульне ліцензування, де розширена фільтрація, підтримка FlowSpec чи звітність є окремими позиціями витрат, що докуповуються окремо.

Ліцензія LiveShield пов'язана виключно з вхідним трафіком (Гбіт/с), без поділу на модулі, без додаткових плат за FlowSpec, розширену фільтрацію чи звітність. Повна функціональність системи вміщується в одну ціну, що полегшує передбачення витрат за зростання трафіку в мережі.

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

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

Перед ухваленням рішення варто мати відповідь на кожне з наведених нижче запитань:

На кожне з цих запитань LiveShield має конкретну, перевірювану відповідь, а не лише декларацію відповідності стандарту.

Повна технічна документація: docs.liveshield.net.
Технічні запитання: office@liveshield.net