Чому захист від DDoS-атак для інтернет-провайдерів став завданням №1 у 2026 році

За першу половину 2026 року Cloudflare відбила 935 мережевих DDoS-атак потужністю понад 1 Тбіт/с, а їхня кількість зросла на 519% порівняно з попереднім кварталом, згідно зі звітом Cloudflare DDoS Threat Report H1 2026. Для оператора зв’язку це не абстрактна статистика: кожна така атака проходить через магістральні канали, які ви орендуєте, та абонентську інфраструктуру, яку ви обслуговуєте. Захист від DDoS-атак для інтернет-провайдерів перестав бути опцією для великих операторів і став базовою вимогою до мережевої архітектури.

У COSMONOVA ми бачимо цю проблему з двох боків: як оператор, що підтримує канали зв’язку та дата-центри, і як партнер провайдерів, яким потрібна передбачувана мережева інфраструктура. Нижче розглянемо, як атаки порушують роботу мережі, як побудувати виявлення, фільтрацію та scrubbing-центр, а також який регламент мають мати NOC і SOC до моменту першого піка навантаження.

Увага

Найпоширеніша помилка провайдера — вважати, що «канал на 100 Гбіт/с і так витримає». Атака потужністю 31,4 Тбіт/с, зафіксована наприкінці 2025 року, згідно з даними SentinelOne DDoS Attack Statistics 2026, може перевантажити будь-який комерційний аплінк. Без фільтрації на джерелі ви платите за трафік, який вам не потрібен.

Як атаки на мережевому та транспортному рівнях порушують роботу інфраструктури провайдера

Мережеві та транспортні атаки спрямовані на пропускну здатність, а не на застосунки. Їхня мета — перевантажити канал і спричинити відмову в обслуговуванні для всіх абонентів ураженого сегмента.

Мережевий і транспортний рівні: флуд, перевантаження каналу та щільність пакетного трафіку

На мережевому рівні зловмисники використовують ICMP-флуд, фрагментацію та підміну адрес джерела. На транспортному — SYN-флуд, UDP-флуд та ампліфікацію через відкриті резолвери. Ключова метрика тут — не обсяг у гігабітах, а щільність пакетного трафіку: мільйони невеликих пакетів за секунду можуть вивести маршрутизатор з ладу раніше, ніж буде вичерпано пропускну здатність каналу.

Саме тому фільтрація пакетів на магістралі має працювати за правилами, а не лише за пороговими значеннями обсягу трафіку. SentinelOne повідомляє про зростання кількості атак на мережевому рівні на 168,2% рік до року на початку 2026 року. Розраховувати на те, що це рідкісне явище, більше не доводиться (DDoS Attack Statistics 2026: 41 Key Facts and Trends).

Прикладний рівень: флуд-запити до DNS та абонентських сервісів

Прикладний рівень небезпечніший тим, що трафік може виглядати легітимним. Флуд-запити до DNS, масові звернення до порталу самообслуговування, аномальна активність в API білінгу — усе це може залишатися в межах очікуваного обсягу трафіку, але водночас виводити сервіс з ладу.

Для провайдера критичними є два вектори: власні рекурсивні резолвери та абонентські сервіси (особистий кабінет, IPTV, VoIP). Тут потрібні обмеження частоти запитів, вебекран застосунків і поведінковий аналіз, а не просто блокування джерел.

Виявлення DDoS-атак у мережі: метрики, аномалії трафіку та час реагування

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

Що моніторити насамперед:

• Кількість пакетів за секунду на кожному аплінку та піринговому стику.

• Співвідношення пакетів і байтів: флуд невеликими пакетами помітний майже миттєво.

• Ентропію джерел: зростання кількості унікальних адрес за хвилину.

• Час виявлення та час пом’якшення атаки — дві метрики, які визначають масштаб збитків.

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

Фільтрація DDoS-трафіку: правила, обмеження частоти запитів і захист легітимних абонентів

Фільтрація DDoS-трафіку — це набір правил на мережевому периметрі та в scrubbing-центрі, який відкидає шкідливий трафік, зберігаючи легітимний. Головний ризик тут — не лише пропустити атаку, а й заблокувати власних абонентів.

Практичний набір правил для провайдера:

• Фільтрація пакетів за сигнатурами: SYN без ACK, невалідні прапорці, підміна RFC1918-адрес із зовнішніх інтерфейсів.

• Обмеження частоти запитів до DNS, NTP і порталів — окремо для джерела та призначення.

• Географічна фільтрація лише як тимчасовий захід у разі підтвердженої атаки з конкретного регіону.

• Блокування джерел через BGP-анонси (blackhole) з обов’язковим терміном дії правила.

• Списки винятків для критично важливих абонентів і партнерських мереж.

Порада професіонала

Правило blackhole без таймера — одна з найдорожчих помилок під час фільтрації. Налаштуйте автоматичне зняття анонсу не пізніше ніж через 30 хвилин і реєструйте кожен випадок. Інакше один помилковий префікс може позбавити абонента всього трафіку на цілу добу.

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

Scrubbing-центр для інтернет-провайдера: архітектура очищення та маршрутизація трафіку

Інженер NOC у навушниках перед кількома моніторами з графіками мережевого трафіку в сучасному центрі керування, приглушене освітлення, зосереджений вираз обличчя.

Scrubbing-центр для інтернет-провайдера — це не просто «коробка з фільтрами». Це майданчик із достатньою пропускною здатністю, обладнанням для очищення трафіку та, головне, продуманою схемою перенаправлення і повернення трафіку. Ключове питання — як спрямувати трафік до центру та повернути його назад без втрати маршруту й погіршення якості обслуговування легітимних абонентів.

Варіанти розгортання: локальний, хмарний і гібридний scrubbing

Для провайдера існують три базові моделі. Вибір між ними залежить від профілю атак та економіки.

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

Хмарний scrubbing. Трафік перенаправляється до центру постачальника послуги через GRE-тунель або виділений стик. Переваги: потужність масштабується за потреби, а постачальник відповідає за оновлення сигнатур і цілодобовий моніторинг. Недоліки: залежність від зовнішнього каналу, додаткова затримка на маршруті «ви → центр → назад» і необхідність юридично закріпити SLA.

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

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

Як працює очищення: BGP-анонси, GRE-тунелі та повернення чистого трафіку

Стандартна схема роботи має такий вигляд:

1. Після підтвердження аномалії маршрутизатор оголошує специфічніший префікс через BGP у напрямку scrubbing-центру. Для атаки на конкретного абонента це може бути /32, для атаки на сегмент — /24.

2. Трафік надходить до центру через GRE-тунель або виділений стик. Важливо, щоб тунель був заздалегідь налаштований і протестований: під час атаки часу на його налаштування вже не буде.

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

4. Після завершення атаки анонс знімається, а трафік повертається на прямий маршрут. Зняття анонсу має відбуватися автоматично за таймером, а не вручну, інакше забутий анонс може назавжди перенаправити трафік до центру.

Для точкової фільтрації на магістралі використовуйте BGP FlowSpec. Ця технологія дає змогу передавати правила фільтрації (за адресою джерела, портом і протоколом) безпосередньо на аплінк-маршрутизатори без перенаправлення всього трафіку. Це швидше й дешевше, ніж пропускати весь потік через scrubbing, але потребує підтримки FlowSpec на обладнанні upstream.

Взаємодія з upstream-провайдерами та резервування каналів

Жоден scrubbing-центр не замінить домовленостей з upstream-провайдерами. На практиці це означає три речі: узгоджений канал зв’язку з NOC upstream, заздалегідь затверджений регламент анонсів і резервний маршрут на випадок, якщо основний аплінк буде перевантажений.

Що має бути зафіксовано в регламенті з upstream:

• Хто має право оголошувати RTBH (Remotely Triggered Black Hole) і за якого порога. Зазвичай це чергова команда NOC, але з обов’язковим повідомленням upstream.

• Максимальний час дії blackhole-анонсу — не більше ніж 30 хвилин без продовження.

• Контактні дані NOC upstream, доступні 24/7, і резервний канал зв’язку (телефон, а не лише тікет).

• Резервування каналів має бути фізично незалежним. Два канали від одного upstream в одній будівлі — фактично один канал. Якщо обидва аплінки проходять через одну точку обміну, атака на цю точку виведе з ладу весь захист.

Увага

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

План реагування на DDoS-атаку для NOC і SOC: покроковий регламент

План реагування на DDoS-атаку — це документ, який NOC і SOC мають виконувати без обговорень під час інциденту. Нижче наведено робочу структуру, яку варто адаптувати до власної мережі.

1. Виявлення інциденту (до 5 хвилин)

Відповідальний: черговий NOC.

Підтвердження аномальної активності за показниками моніторингу та реєстрація інциденту.

2. Класифікація (до 10 хвилин)

Відповідальний: SOC.

Визначення типу атаки та її вектора: мережевий, транспортний або прикладний рівень.

3. Локалізація (до 10 хвилин)

Відповідальний: NOC.

Визначення префіксів мережі та абонентів, які зазнали впливу атаки.

4. Пом'якшення впливу (до 15 хвилин)

Відповідальні: NOC + SOC.

Активація правил фільтрації трафіку та, за необхідності, анонсування маршруту до системи очищення трафіку (Scrubbing Center).

5. Ескалація (до 30 хвилин)

Відповідальний: черговий менеджер.

Інформування upstream-провайдера та керівництва у разі досягнення встановленого порогового значення інциденту.

6. Стабілізація (постійно)

Відповідальний: служба підтримки.

Контроль хибних спрацювань систем захисту та звернень абонентів під час стабілізації роботи мережі.

7. Аналіз інциденту (до 72 годин)

Відповідальні: NOC + SOC.

Проведення аналізу після завершення інциденту, оцінка ефективності реагування та оновлення правил захисту.

Ключовий висновок

Регламент працює лише тоді, коли його перевірено під час навчань. Проводьте навчальну тривогу раз на квартал: оголосіть тестовий маршрут, пропустіть трафік через scrubbing і виміряйте фактичний час пом’якшення. Без навчань наведена вище таблиця залишиться теорією.

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

Метрики та критерії вибору захисту від DDoS-атак для оператора зв’язку

Вибір захисту від DDoS-атак для оператора зв’язку має ґрунтуватися на вимірюваних критеріях, а не на довжині списку функцій у презентації. Оцінюйте постачальника за показниками, які можна перевірити на власному трафіку, та за сценаріями, важливими саме для провайдера.

Ключові метрики: ємність, PPS, час реагування та хибні спрацювання

Ємність очищення — скільки Тбіт/с і мільйонів пакетів за секунду (PPS) може обробити центр. Для провайдера важлива не лише заявлена пікова ємність, а й пропускна здатність одного стику: якщо центр приймає трафік лише через один порт 100 Гбіт/с, атака на 200 Гбіт/с його перевантажить.

Час виявлення — кількість секунд від початку атаки до появи сповіщення. Орієнтир для оператора: не більше ніж 60 секунд для об’ємних атак і не більше ніж 5 хвилин для атак на прикладному рівні.

Час пом’якшення — час від сповіщення до застосування правил фільтрації. Цільовий показник за автоматичного спрацювання — не більше ніж 1–2 хвилини.

Сценарії перевірки: як протестувати захист до підписання контракту

Перед підписанням контракту запросіть тестовий період і пропустіть через систему захисту реальний профіль власного трафіку. Що саме перевіряти:

• Об’ємна атака. Згенеруйте UDP-флуд або ампліфікацію через тестовий стенд і виміряйте, за скільки секунд спрацювало пом’якшення та який обсяг легітимного трафіку пройшов.

• Атака на прикладному рівні. Перевірте флуд DNS-запитами або HTTP-запитами до абонентського порталу. Переконайтеся, що захист не блокує легітимних абонентів.

• Атака на конкретного абонента. Перевірте, чи може система точково фільтрувати /32, не зачіпаючи весь сегмент.

• Зняття анонсу. Переконайтеся, що після завершення атаки трафік автоматично повертається на прямий маршрут без втрат.

• Хибне спрацювання. Створіть легітимне навантаження, схоже на атаку, і перевірте реакцію фільтра.

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

Сукупна вартість володіння та економіка захисту для провайдера

Вартість захисту складається не лише з абонентської плати. Розраховуйте сукупну вартість володіння:

• Капітальні витрати на локальне обладнання для очищення трафіку, якщо ви обираєте локальну модель.

• Абонентська плата за хмарний scrubbing, яка зазвичай залежить від пікової ємності та обсягу очищеного трафіку.

• Вартість каналів для перенаправлення трафіку до scrubbing-центру: GRE-тунель також займає смугу пропускання.

Для провайдера з невеликою мережею хмарний scrubbing майже завжди дешевший за локальний на старті. Але зі зростанням абонентської бази та частішими атаками локальний центр може окупитися завдяки відсутності змінної плати. Точка беззбитковості залежить від профілю атак і тарифів постачальника — розраховуйте її на власних показниках.

Порада професіонала

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

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

Поширені запитання

Як інтернет-провайдеру виявити DDoS-атаку на мережу?

Стежте за різкими відхиленнями від базового рівня: зростанням кількості пакетів за секунду, заповненням аплінку, сплесками флуд-запитів до DNS та аномальною активністю з багатьох джерел. Виявлення DDoS-атак у мережі ґрунтується на постійному моніторингу трафіку та порогових значеннях обсягу атаки й щільності пакетного трафіку. У першому півріччі 2026 року Cloudflare зафіксувала 935 мережевих атак потужністю понад 1 Тбіт/с, тому пороги мають враховувати атаки з високою пропускною здатністю, а не лише сплески кількості запитів.

Як фільтрувати DDoS-трафік, не блокуючи легітимних абонентів?

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

Навіщо інтернет-провайдеру власний scrubbing-центр?

Scrubbing-центр для інтернет-провайдера дає змогу очищати трафік ближче до джерела атаки та не допускати перевантаження каналу до абонентського доступу. Така схема передбачає обробку трафіку поруч із точкою входу в мережу. На практиці це означає фільтрацію на магістралі, цілодобовий моніторинг і повернення чистого трафіку через тунелі. Без власного або партнерського центру атака потужністю 1 Тбіт/с швидко вичерпає пропускну здатність аплінків.

Що має містити план реагування на DDoS-атаку та які метрики важливі?

План реагування на DDoS-атаку визначає ролі NOC і SOC, канали ескалації, порядок увімкнення фільтрації та контакти upstream-провайдерів. У ньому мають бути передбачені сценарії атак на абонентів і власну інфраструктуру, а також порядок аналізу інцидентів. Ключові метрики: час виявлення, час пом’якшення, частка хибних спрацювань і дотримання SLA. Регулярні навчання та тестування правил фільтрації допомагають перевірити ефективність захисту до реального інциденту.