Власна anti-DDoS система і послуга від upstream не виключають одна одну, бо відповідають за різні речі. Послуга upstream дає потужність мережі постачальника і діє ще до того, як трафік дійде до каналу оператора, але охоплює лише трафік, що проходить через цього постачальника. Власна система бачить трафік з усіх моніторованих каналів, ухвалює рішення про реакцію за секунди й може надсилати правила або blackholing до upstream. Тому для більшості операторів питання звучить не «чи», а «як розподілити ролі».
Що пропонують anti-DDoS послуги від upstream?
Upstream може запропонувати оператору один або кілька рівнів захисту: blackholing, що запускається BGP community, прийняття від клієнта правил BGP FlowSpec, керовану послугу з виявленням і фільтрацією на боці постачальника та перенаправлення трафіку до scrubbing center. Обсяг і умови різняться залежно від постачальника.
На польському ринку публічно описано, зокрема, дві такі послуги:
Orange: DDoS Protection описано як безперервний моніторинг трафіку клієнта 24/7/365, виявлення аномалій і усунення підозрілих пакетів, із SOC, доступним цілодобово, та підсумковим звітом після інциденту. Блокування відбувається автоматично або після консультації з клієнтом. Окрема послуга Orange Internet Protection є додатком для клієнтів Biznesowy VPN і Miejski Ethernet, а про її автоматичне вмикання клієнт отримує електронне повідомлення.
Exatel: TAMA існує в трьох варіантах. Basic застосовує blackholing, Standard фільтрує шкідливий трафік і пропускає коректний, а Advanced додає підтримку SOC під час атаки. Послуга захищає клієнтів на лініях Exatel і працює на центральній платформі в його центрі обробки даних. Волюметричний захист описано до 100 Гб/с, а пороги pps і bps для окремих IP-адрес клієнт може встановити самостійно.
Потужність - це реальна перевага мережі постачальника. CERT Orange Polska описав атаку на одну IP-адресу з піком 1,5 Тб/с. Це у багато разів більше за канали типового локального оператора. Водночас на публічних сторінках обох послуг ми не знайшли ні конкретних часів реакції, ні цін, тому ці параметри потрібно уточнювати безпосередньо в постачальника.
Що дає власна anti-DDoS система в мережі оператора?
Власна система бачить трафік з перспективи всієї мережі оператора й реагує на його маршрутизаторах. LiveShield аналізує копію трафіку з порту SPAN або оптичного Link TAP, поза виробничим шляхом, тому охоплює всі моніторовані канали, а не лише одного постачальника.
Пороги в pps і bps встановлюються окремо для окремих IP-адрес і для підмереж, що дозволяє виявляти також carpet bombing.
Після виявлення система створює на прикордонних маршрутизаторах оператора правила BGP FlowSpec, підібрані до характеристик трафіку, а blackholing залишається крайнім заходом. Різницю ми описуємо в матеріалі про FlowSpec і RTBH.
Для stateful-атак, таких як SYN-ACK reflection, призначений inline-фільтр LiveShield AIF.
Трафік залишається в мережі оператора. Згідно з документацією, він не тунелюється за межі інфраструктури, тому постійної додаткової затримки немає.
Перебіг інциденту записується, а звіт KSC містить, зокрема, час виявлення, час першого правила та час до мітигації. Повідомлень до CSIRT система не надсилає, звіт створює користувач.
Ліцензія не залежить від кількості локацій чи пристроїв. Принципи ми описуємо в матеріалі Одна ліцензія на всю мережу.
Чим послуга від upstream відрізняється від власної системи?
Різниця стосується охоплення видимості, потужності та того, хто ухвалює рішення. Наведене нижче порівняння спирається на публічно доступні описи послуг і на документацію LiveShield.
Порівняння: послуга від upstream і власна anti-DDoS система в мережі оператора. Охоплення, потужність, виявлення і пороги, спосіб блокування, час реакції, докази після атаки та модель розрахунків.
Жодна з колонок не виграє в кожному рядку. Тому порівняння має сенс лише тоді, коли зіставити його з профілем власної мережі.
Чому системи в мережі оператора недостатньо проти атаки, більшої за канал?
Фільтрація в мережі оператора діє на трафіку, який уже до неї дійшов. Коли атака насичує канал до upstream, правила на прикордонному маршрутизаторі не відновлять смугу, бо пакети вже її зайняли. Цей випадок ми докладніше розглядаємо в матеріалі про те, що відбувається, коли DDoS-атака перевищує пропускну здатність каналу uplink.
Тоді сигнал має піти вище: правила FlowSpec або blackholing до upstream, якщо постачальник їх надає, або перенаправлення трафіку до scrubbing center. У цій ролі послуги upstream доповнюють локальний захист, а не замінюють його.
Як виглядав розподіл ролей під час атаки 70 Гб/с на одну адресу?
У першій хвилі атаки правила обрала локальна система, а виконання blackholing взяли на себе upstream. 27 вересня 2026 року в мережі одного з варшавських операторів, захищених LiveShield, розпочалася атака на одну IPv4-адресу абонента. Пік становив 70,47 Гб/с і 7,15 Mpps на третій секунді.
Локально система створила правила FlowSpec, підібрані до трафіку: відкидання UDP на порт 80, малих UDP-датаграм і IP-фрагментів, а в другій хвилі також TCP SYN і ICMP.
За обсягу понад 70 Гб/с вона оголосила upstream blackholing адреси жертви. Він тривав 68 секунд, з 20:19:42 до 20:20:50, після чого був автоматично знятий.
Трафік від двох транзитних постачальників упав майже до нуля, тоді як трафік із точок обміну трафіком і далі обмінювався та підлягав правилам FlowSpec.
Друга хвиля обсягом близько 52 Гб/с не перевищила порогів blackholing. Вистачило правил FlowSpec.
Дані походять із панелі LiveShield і показують вхідний у мережу трафік. Як обмежити побічні ефекти blackholing, ми описуємо в матеріалі про селективний blackholing.
Як поєднати власну систему з послугою від upstream?
Поєднання потребує домовленостей з кожним upstream окремо, бо саме постачальник вирішує, які сигнали приймає. На практиці воно складається з кількох елементів.
З'ясуйте пропозицію upstream. Для кожного постачальника потрібно підтвердити, чи приймає він FlowSpec і RTBH та які community або параметри потрібні. Частина постачальників вимагає окремої сесії BGP лише для blackholing.
Community для кожного upstream. LiveShield оголошує маршрут blackhole з локальною community, а маршрутизатор перезаписує її на community, яку вимагає даний постачальник. Вимоги кожного постачальника налаштовуються в меню Upstreams (документація blackholing).
Селективний blackholing. Маршрут надходить лише до тих upstream, які перевищили власні пороги. Це потребує маркування трафіку VLAN 802.1Q і працює повільніше за звичайний blackholing, бо система відстежує трафік кожного upstream окремо. RTBH зазвичай працює лише в постачальників IP-транзиту, а на приватному пірингу й у точках обміну трафіком, як правило, не підтримується.
Перенаправлення до scrubbing center. Якщо оператор має договір з таким постачальником, система після виявлення атаки на префікс може створити правило FlowSpec з дією redirect до вказаного VRF або IP-адреси. Перенаправлення можна пов'язати з порогами обсягу, а повернення трафіку після атаки може відбуватися автоматично. Маршрутизатор має підтримувати дію redirect, а конфігурація підбирається під мережу оператора і постачальника. Подробиці описано в матеріалі про поєднання локального захисту зі scrubbing center.
Тест без очікування атаки.Manual Rules дозволяють створити ручний blackholing для вибраної адреси, з вибраною community та upstream. Варто перевірити, чи постачальник справді прийняв маршрут /32 і відкидає трафік до цієї адреси.
Коли достатньо послуги від upstream, а коли потрібна власна система?
Послуги від upstream може вистачити як першого кроку, коли мережа користується одним транзитним постачальником, не має ресурсів для обслуговування власної системи та погоджується з темпом реакції постачальника. Власна система потрібна, коли оператор має власний ASN, кілька upstream, пірингові сесії чи точки обміну трафіком і хоче захищати абонентів селективно, бо послуга одного постачальника не бачить трафіку з решти напрямків.
У більшості мереж із таким профілем найкраще працює багаторівневий підхід: власна система виявляє й фільтрує локально, а upstream додає потужність там, де локальної фільтрації не вистачає.
Роботу панелі LiveShield можна переглянути в публічному демо на demo.liveshield.net. Технічна документація доступна на docs.liveshield.net, а про впровадження у власній мережі можна запитати за адресою [email protected].
