Міграція на LiveShield з іншої системи anti-DDoS

Міграція на LiveShield з іншої системи anti-DDoS

Міграція на LiveShield з іншої системи anti-DDoS

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

Обидві проблеми можна розв'язати. А друга у випадку LiveShield, по суті, не існує, і це випливає безпосередньо з архітектури системи.

Чому міграція не вимагає вимикання чинного захисту

LiveShield аналізує копію трафіку, що надходить через mirror з крайових маршрутизаторів чи комутаторів (port mirror / SPAN). Система не стоїть у шляху виробничого трафіку й нічого в ньому не змінює. Єдиним активним елементом є анонси BGP, які вмикаються свідомо, наприкінці процесу.

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

Міграція перестає бути стрибком у глибоку воду. Вона стає контрольованим процесом, у якому стару систему вимикають лише тоді, коли нова довела свою ефективність на реальному трафіку вашої мережі.

Як виглядає міграція поетапно

Типовий перебіг паралельного впровадження, що ґрунтується на нашій практиці в операторів ISP:

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

  1. Підготовка інфраструктури. Сервер (або сервери) з мережевою картою відповідної пропускної здатності, Debian 13, доступ через мережу керування. Mirror вхідного трафіку спрямовується на порт сервера паралельно до джерела даних чинної системи. На цьому етапі в діючому захисті нічого не змінюється.
  2. Пасивна робота та порівняння виявлення. LiveShield аналізує трафік і виявляє атаки, але не анонсує жодних правил: сесії BGP можна встановити й перевірити, проте мітигація залишається вимкненою. Це період, коли команда NOC дивиться на обидві системи поруч: часи виявлення, виявлені вектори, атаки, видимі лише в одній із систем. Водночас налаштовуються пороги для кожної IP і кожної підмережі під специфіку мережі.
  3. Поступове перебирання мітигації. Зазвичай починаємо з blackholing, потім вмикається FlowSpec на маршрутизаторах, які його підтримують. Це можна робити для кожного префікса або для кожної групи клієнтів: частину мережі вже захищає LiveShield, частину ще стара система.
  4. Вимкнення попередньої системи. Відбувається лише тоді, коли LiveShield перебрав повну мітигацію та пройшов пробний період на реальних інцидентах. Без великого дня перемикання й без сервісного вікна.
Усю конфігурацію ми можемо виконати з нашого боку, зокрема міграцію конфігурацій маршрутизаторів, якщо принагідно змінюється також крайове обладнання.

Міграція LiveShield

Що показує порівняння на живому трафіку

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

Приклад з однієї з таких паралельних інсталяцій: багатовекторна атака (IP Fragments + DNS + UDP flood) обсягом 6,5 Гбіт/с і 700 kpps. LiveShield виявив атаку й наклав перше правило фільтрації в ту саму секунду. Конкурентна система, що працювала поруч, виявила атаку через 4 секунди, а перше правило запровадила через 18 секунд після виявлення LiveShield. Третій вектор, попри правильну конфігурацію, вона не відфільтрувала взагалі.

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

Питання ліцензії: подвійні витрати менші, ніж здається

Залишається аргумент «ми маємо оплачену ліцензію». На практиці він рідко буває блокувальним із двох причин.

По-перше, модель ліцензування LiveShield ґрунтується виключно на вхідному трафіку, без плати за кількість сенсорів, фільтрів, інтерфейсів чи локацій. Не потрібно підлаштовувати архітектуру мережі під модель ліцензування чи докуповувати компоненти, щоб отримати повну функціональність: виявлення, фільтрація, FlowSpec, blackholing і звітність входять в одну ліцензію.

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

З чого почати

Якщо ви розглядаєте заміну системи anti-DDoS, найпростіший перший крок не вимагає жодних рішень щодо закупівлі: перевірте, чи можете спрямувати mirror трафіку на додатковий порт, і напишіть нам на office@liveshield.net. Ми визначимо апаратні вимоги під ваш обсяг трафіку та запропонуємо план паралельного впровадження, підлаштований під термін вашого чинного договору.

Не чекайте на наступну DDoS-атаку.
Зв'яжіться з нами вже сьогодні!

Будь ласка, перевірте заповнені поля на наявність помилок. Якщо проблема не зникає, зв'яжіться з нами безпосередньо за адресою office@liveshield.net

Дякуємо, що звернулися до нас!

Ваше повідомлення було успішно надіслано.
Ми зв'яжемося з вами якнайшвидше.

Або зателефонуйте нам безпосередньо

(+48) 880 779 307