- DDoS-атаки переросли з сотень Гбіт/с до гіператак у кілька Тбіт/с, що підтримуються ботнетами Інтернету речей та методами посилення UDP.
- Професійне пом'якшення поєднує в собі центри очищення, мережі Anycast CDN, брандмауери, WAF, а також належні методи посилення захисту та раннього моніторингу.
- Програмований захист потоку Cloudflare дозволяє логіці пакетів у C/eBPF фільтрувати певний UDP-трафік на рівні програми.
- Ефективна стратегія вимагає глибоко ешелонованого захисту, автоматизації, планів дій у надзвичайних ситуаціях та співпраці з інтернет-провайдерами та постачальниками хмарних послуг.
Ми живемо в епоху, коли мережа є сполучною тканиною майже всього, що ми робимо. Коли компанія втрачає зв'язок через атаку типу «відмова в обслуговуванні», це стосується не лише веб-сайту, який виходить з ладу: паралізуються продажі, внутрішні процеси, обслуговування клієнтів, а в найсерйозніших випадках — важливі служби. Саме тому індивідуальне пом'якшення DDoS-атак із програмованим захистом потоку стало стратегічним компонентом будь-якої сучасної архітектури.
Поява таких технологій, як Cloudflare Programmable Flow Protection для Magic Transit , використання користувацької логіки C, розгорнутої як eBPF, інтеграція з хмарами, такими як AWS та Azure, та підтримка спеціалізованих служб захисту радикально змінили ситуацію. Тепер можна моделювати, що вважається «корисним» або «шкідливим» трафіком на рівні пакетів, адаптувати заходи пом’якшення до дуже специфічних протоколів UDP (таких як ті, що використовуються в онлайн-іграх або VoIP) та поєднувати це з бізнес-аналітикою та рішеннями штучного інтелекту, які навчаються на кожній атаці.
Що таке DDoS-атака і чому вона стала такою серйозною проблемою?
Розподілена атака типу «відмова в обслуговуванні» (DDoS) спрямована на перевантаження ресурсів системи (серверів, каналів, програм або проміжної інфраструктури) шляхом запуску потоку трафіку з кількох одночасних джерел. На відміну від класичної DoS-атаки, де атаку запускає одне джерело, DDoS-атака охоплює тисячі або навіть мільйони скомпрометованих пристроїв, організованих у ботнет.
Мотивація DDoS-атак різноманітна: економічний шантаж, саботаж серед конкурентів, активізм, репресії проти журналістів чи ЗМІ, або просто випробування сили новими ботнетами в режимі «демонстрації можливостей». Однак результат завжди один і той самий: недоступність сервісу , серйозне погіршення продуктивності, економічна та репутаційна шкода.
В останні роки спостерігається стабільне зростання частоти та інтенсивності цих атак. Звіти основних постачальників засобів безпеки вказують на стійке зростання гіпероб'ємних атак (понад 1 Тбіт/с або один мільярд пакетів за секунду), часто спрямованих на критично важливу інфраструктуру, таку як фінансові послуги, комунальні послуги та телекомунікації.
Типи DDoS-атак: від мережі до програми
Щоб зрозуміти, як працює індивідуальне пом'якшення DDoS-атак, корисно розглянути основні категорії атак. Загалом кажучи, ми можемо згрупувати їх у чотири основні родини, пов'язані з різними рівнями моделі OSI та різними ресурсами, які вони спрямовані на виснаження.
Атаки мережевого рівня (L3/L4) зосереджені на використанні мережевих та транспортних протоколів (IP, TCP, UDP, ICMP) для виснаження обмежених ресурсів сервера або проміжної інфраструктури: процесора, пам'яті, таблиць брандмауера, підключень, що очікують на встановлення, або мережевих буферів. Класичні приклади включають SYN-флуд (затоплення сервера запитами на TCP-з'єднання, які ніколи не завершують встановлення зв'язку), UDP-флуд на випадкові порти та ICMP-атаки.
Атаки прикладного рівня (L7) спрямовані на меншу пропускну здатність, ніж ресурси самого веб-застосунку або API. Вони генерують величезну кількість HTTP-запитів (GET/POST), складних запитів до внутрішніх пошукових систем, викликів важких API або взаємодій, які, хоча й здаються законними, змушують серверну частину, бази даних або системи генерації контенту працювати на межі своїх можливостей.
Об'ємні атаки: тут метою є перевантаження з'єднання, доки воно не стане непридатним для використання. Надсилаються величезні обсяги трафіку, часто використовуючи методи посилення та відбиття на неправильно налаштованих UDP-сервісах, таких як публічні DNS-сервери (DNS, NTP, Memcached, CLDAP, SNMP, SSDP, Chargen, SLP тощо), так що невеликий пакет запиту генерує набагато більшу відповідь, спрямовану на імітовану жертву.
Багатовекторні атаки наразі є найскладнішими. Вони поєднують кілька методів (волюметричні, протокольні та прикладні) та змінюють стратегію в режимі реального часу, коли виявляють, що захист успішний. Одиночна атака може початися як UDP-флуд, потім перейти в SYN-флуд, а згодом перетворитися на HTTP-атаку 7-го рівня, змушуючи жертву розгортати комплексні та скоординовані засоби захисту.
Реальна еволюція DDoS-атак: від Mirai до гіператак Tbps
Теорія гарна, але справжні масштаби проблеми стають очевидними в реальних випадках. За останнє десятиліття ми перейшли від атак на сотні гігабіт за секунду до подій, що легко перевищують кілька терабіт за секунду (Тбіт/с) , зі швидкістю передачі пакетів, що сягає мільярдів за секунду.
У 2016 році атака на Dyn — головного постачальника DNS — досягла приблизно 1,2 Тбіт/с і тимчасово вивела з ладу такі сайти, як Twitter, GitHub, PayPal і Netflix. Ботнет Mirai, який залучив понад 600 000 пристроїв Інтернету речей (маршрутизатори, камери та відеореєстратори зі стандартними обліковими даними), використовувався для генерації величезного трафіку до DNS-серверів Dyn, ймовірно, використовуючи комбінацію методів UDP-перевантаження та посилення.
Того ж року блог про безпеку KrebsOnSecurity зазнав атаки потужністю приблизно 623 Гбіт/с , також на базі Mirai. Протягом майже чотирьох днів великі UDP-пакети переважно запускалися на випадкові порти, перевантажуючи з’єднання та змушуючи перенаправляти трафік на спеціалізовані служби зменшення ризиків, такі як Akamai Prolexic, які застосовували сигнатурну та поведінкову фільтрацію.
У 2018 році GitHub став мішенню атаки зі швидкістю 1,35 Тбіт/с, заснованої на посиленні Memcached. Зловмисники надсилали невеликі UDP-запити до серверів Memcached, що знаходилися на порту 11211, використовуючи підроблену IP-адресу GitHub. Кожен крихітний запит викликав відповіді в 50-100 разів більші, спрямовані на системи GitHub, які були змушені перенаправляти трафік до центрів очищення, де відповіді Memcached фільтрувалися за їхніми специфічними шаблонами.
У 2020 році Amazon повідомила, що AWS Shield запобігла атакі зі швидкістю 2,3 Тбіт/с, спираючись на відображення CLDAP (UDP 389). Вектор атаки полягав у бомбардуванні серверів LDAP без урахування стану запитами, які генерували велику кількість відповідей жертві. AWS розподіляв трафік по своїй глобальній мережі та застосовував правила фільтрації для цього конкретного шаблону CLDAP.
Зовсім недавно з'явилися ботнети, такі як Mēris , що використовують вразливості в маршрутизаторах MikroTik. У 2021 році було зафіксовано піки в 21,8 мільйона запитів на секунду (RPS), а в 2022 році вони досягли 46 мільйонів RPS проти інфраструктури Google, з приблизними обсягами 1,3 Тбіт/с. Зусилля щодо пом'якшення наслідків включали масове встановлення патчів на пристрої, закриття портів, таких як 5678 , та застосування спеціальних правил фільтрації для сигнатури Mēris у таких мережах, як Cloudflare та Akamai.
У квітні 2025 року Cloudflare повідомила про гіператаку зі швидкістю приблизно 6,5 Тбіт/с та кількома мільярдами пакетів на секунду. Згідно з їхнім аналізом, це був неатрибутований ботнет з характеристиками, подібними до Mēris та Aisuru, який в основному використовував прямі UDP-флуди з пристроїв Інтернету речей та неправильно налаштованих серверів, не вимагаючи традиційного посилення. Захист спирався на глобальну мережу Anycast від Cloudflare, пом'якшення XDP/eBPF на периферії, динамічне очищення та обмеження швидкості для кожної IP-адреси та регіону.
А у травні 2025 року KrebsOnSecurity знову потрапила в заголовки газет, витримавши атаку зі швидкістю приблизно 6,3 Тбіт/с, запущену ботнетом Aisuru. У цьому випадку протягом 40-45 секунд генерувалося близько 585 мільйонів UDP-пакетів на секунду. Google Project Shield, який захищав сайт, негайно активував агресивні політики фільтрації небажаних UDP-пакетів і перенаправив трафік до центрів очищення, розподілених по всій глобальній мережі, тому вплив на сервіс був практично непомітним.
Ресурси та методи зловмисників: ботнети, посилення та ухилення
Щоб досягти цих вражаючих цифр, зловмисники використовують різноманітні ресурси, комбінуючи їх відповідно до своєї мети. Основою є масивні ботнети : мережі скомпрометованих пристроїв по всьому світу, що вербуються шляхом використання відомих вразливостей, паролів за замовчуванням або розкритих адміністративних служб. Mirai, Mēris та Aisuru – це сімейні назви, але існують незліченні варіації, спрямовані на різних виробників або послуги.
Другою основною вразливістю є неправильно налаштовані сервери, що діють як відбивачі. Будь-який неавтентифікований UDP-сервіс, який відповідає більшою кількістю даних, ніж отримує, є кандидатом: DNS (порт 53), NTP (123), Memcached (11211), CLDAP (389), SNMP (161), SSDP, Chargen, SLP, TFTP, Portmap, P2P-сервіси або навіть протоколи відеоігор. Зловмисник надсилає невеликі запити, підробляючи IP-адресу жертви, а сервери посилюють і повертають відповідь фактичній цілі.
Наприклад, у DNS запит ANY до відкритого резолвера може помножити розмір запиту приблизно у 28 разів. У NTP стара команда MONLIST досягала коефіцієнтів посилення 50-500x. Memcached є крайнім випадком: крихітний запит може повернути сотні кілобайт, досягаючи коефіцієнтів посилення десятків тисяч. CLDAP працює з коефіцієнтами 56-70x, тоді як SLP використовувався зі значеннями, що перевищують 2000x.
Крім того, зловмисники вдосконалюють свої методи ухилення. IP-спуфінг залишається класичним методом приховування справжнього походження та використання відображення. Інші методи включають постійну зміну векторів атаки, змішування зашифрованого трафіку для збільшення навантаження на захисника, використання "низьких та повільних" методів (поступове споживання ресурсів без очевидних піків) або наближення трафіку до рівня додатків, де він набагато більше нагадує легітимний трафік.
На етапі перед атакою для виявлення вразливих сервісів використовуються інструменти масового сканування, такі як masscan або zmap, а також набори експлойтів, спеціально розроблені для Інтернету речей або серверів. Під час атаки використовуються генератори трафіку, такі як hping3, LOIC/HOIC або оптимізовані скрипти C/Python, тоді як для аналізу після атаки самі зловмисники можуть використовувати Wireshark, tcpdump та платформи моніторингу.
Фази DDoS-атаки та необхідність адаптивного захисту
Хоча складні DDoS-атаки часто сприймаються як хаотичні сплески трафіку, вони проходять кілька окремих фаз . По-перше, етап розвідки, на якому зловмисник вивчає відкриту поверхню, ідентифікує домени, IP-адреси, відкриті сервіси, CDN або постачальників засобів пом'якшення ризиків та шукає вразливості.
Далі йде компрометація пристроїв, яка передбачає зараження комп’ютерів, що живлять ботнет. Це може означати використання вразливостей у маршрутизаторах, камерах, системах віддаленого керування або серверах, часто шляхом використання застарілого програмного забезпечення або облікових даних за замовчуванням. Після залучення вони підключаються до інфраструктури C2, яка централізує команди та оновлення.
Фаза виконання атаки зазвичай приурочена до критичних моментів для жертви: маркетингові кампанії, запуски продуктів, вихідні з меншою кількістю персоналу на службі або політично чи медіа-чутливі дати. Мета полягає в максимізації впливу та тиску . В атаках наступного покоління також існує компонент динамічної адаптації: ботнет відстежує реакцію жертви та змінює свій вектор атаки, якщо виявляє ефективне пом'якшення наслідків.
З боку захисту це вимагає розробки однаково адаптивних стратегій. Статичного брандмауера або порогу пропускної здатності більше недостатньо: потрібні системи, здатні виявляти аномалії трафіку в режимі реального часу , корелювати події, розгортати нові правила на льоту та масштабувати ресурси (обчислювальні, сховища та мережеві потужності) на вимогу.
Нещодавнє дослідження показало, що кількість DDoS-атаок на критичну інфраструктуру зросла більш ніж на 50% за чотири роки, і що вони часто використовуються як димова завіса для інших вторгнень, таких як розгортання програм-вимагачів, поки команда безпеки зосереджена на «гасінні вогню» відмови в обслуговуванні.
Традиційне пом'якшення: центри очищення, CDN, брандмауери та WAF
Професійний захист від DDoS-атак спирається на комбінацію технологій та постачальників. Найбільш характерним компонентом є центри очищення трафіку , великі розподілені інфраструктури, які можуть поглинати десятки Тбіт/с та фільтрувати шкідливий трафік, перш ніж повертати клієнту лише дійсні з'єднання.
Такі компанії, як Netscout/Arbor, Akamai/Prolexic, Cloudflare, Radware, Imperva та AWS Shield, керують глобальними мережами з кількома точками присутності. Коли виявляється атака, трафік, призначений для організації-жертви, перенаправляється (через зміни BGP або оновлення DNS) до цих центрів, де застосовуються фільтри на основі сигнатур, поведінки, чорних списків, статистичного аналізу та користувацьких правил.
Паралельно багато організацій розгортають локальні пристрої захисту від DDoS-атак у власних центрах обробки даних або в центрах своїх інтернет-провайдерів. Такі пристрої, як Arbor TMS, Radware DefensePro, FortiDDoS або певні рішення F5, відповідають за виявлення та пом'якшення атак до певного ліміту потужності. Загальною практикою є поєднання цих локальних пристроїв із хмарним рішенням для очищення атак, які перевищують їхню потужність.
Архітектури CDN та Anycast , такі як Cloudflare, Akamai, Fastly або Google Cloud CDN, додають ще один рівень захисту, географічно розподіляючи навантаження. Публікуючи сервіс за CDN, трафік розподіляється між кількома вузлами, а об'ємні атаки розріджуються, оскільки вони не концентруються в одній точці. Крім того, вони зазвичай інтегрують брандмауери веб-застосунків (WAF) та політики обмеження швидкості на рівні HTTP.
Зрештою, мережеві брандмауери (Cisco, Palo Alto, iptables у Linux тощо) та спеціалізовані WAF (ModSecurity, Cloudflare WAF, AWS WAF) дозволяють фільтрувати трафік за IP-адресою, портом, прапорцями та шаблонами програм . Хоча вони самі по собі не зупинять атаку Tbps на рівні магістралі, вони є важливими для блокування відомих векторів атак, обмеження підозрілих з’єднань та захисту рівнів 6 та 7 стеку.
Програмований захист потоку та індивідуальне пом'якшення наслідків за допомогою Magic Transit
У цьому контексті дедалі складніших атак та дедалі специфічніших протоколів з'являються такі рішення, як Cloudflare Programmable Flow Protection for Magic Transit , що знаменують собою якісний стрибок: вони дозволяють компаніям писати власну логіку пом'якшення наслідків та розгортати її безпосередньо в мережі глобального провайдера.
Ідея проста, але потужна: клієнти Magic Transit можуть завантажувати програми обробки пакетів з відстеженням стану, написані на C. Cloudflare перевіряє, компілює та перетворює ці програми в eBPF, запускаючи їх у просторі користувача в межах своєї глобальної інфраструктури. Це дозволяє їм перевіряти UDP-трафік додатків з урахуванням протоколу: розуміючи заголовки, характерні для онлайн-гри, високочастотної торгової системи, VoIP-сервісів або потокових платформ, та вирішуючи, пакет за пакетом, що дозволяти, а що блокувати.
Ця користувацька логіка інтегрується з Flowtrackd, платформою Cloudflare для пом'якшення наслідків з урахуванням стану. Функція підтримує як симетричні, так і асиметричні топології, хоча в цій закритій бета-фазі вона зосереджена на аналізі вхідного трафіку. Усе управління здійснюється через Cloudflare API, з кінцевими точками для завантаження програм, створення пов'язаних правил, переліку конфігурацій або їх видалення за потреби.
Ключовий висновок полягає в тому, що ми більше не покладаємося виключно на загальні сигнатури постачальників та евристики. Наприклад, компанія-розробник відеоігор може чітко визначити легітимний потік свого власного протоколу UDP (підтвердження, повідомлення про позицію, keep-alive тощо) та які шаблони характерні для атаки. Ця логіка компілюється та розгортається на всіх точках присутності Cloudflare, наближаючи рішення до периферії мережі.
Для середовищ зі спеціалізованими протоколами або програмами з дуже високими вимогами до затримки, це пом'якшення DDoS-атак за допомогою програмованого захисту потоку є революційним: воно додає рівень бізнес-інтелекту поверх стандартних засобів захисту. А в поєднанні з хмарними сервісами, такими як AWS або Azure, та спеціалізованими програмними рішеннями (такими як розроблені компаніями, що спеціалізуються на штучному інтелекті та аналітиці, як-от Q2BSTUDIO), це дозволяє ще більше автоматизувати виявлення правил та оновлення на основі нових загроз.
Чому інтернет-провайдерам та організаціям потрібні розширені засоби захисту від DDoS-атак
Інтернет-провайдери (ISP) та великі організації знаходяться на передовій. Досить велика атака може перевантажити не лише одного клієнта, а й цілу секцію мережі оператора, спричиняючи каскадні збої , які впливають на тисячі користувачів. Тому заходи захисту від DDoS-атак стали важливою вимогою, а не додатковим засобом.
З точки зору бізнесу, наслідки відсутності захисту очевидні: переривання обслуговування, порушення угод про рівень обслуговування (SLA), договірні штрафи, пряма втрата доходу та відтік клієнтів на користь конкурентів, яких вважають більш надійними. Якщо критично важлива програма недоступна, коли користувачеві вона потрібна, він, природно, шукатиме альтернативи.
У таких секторах, як банківська справа, страхування, комунальні послуги та охорона здоров'я, вплив може виходити за межі економічних: збої у фізичних процесах , операційні ризики та перебої в наданні життєво важливих послуг. Крім того, існують репутаційні втрати, які важко відшкодувати, коли бренд асоціюється з «системним збоєм» протягом кількох годин у соціальних мережах та пресі.
Що ще гірше, DDoS-атаки часто використовуються як прикриття для більш руйнівних атак. Поки команда безпеки зосереджена на управлінні стрімким зростанням трафіку, зловмисники можуть намагатися проникнути в мережу, розгорнути програмне забезпечення-вимагач або викрасти дані. Іншими словами, DDoS-атаки діють як приманки та відволікаючі маневри в багатоетапних атаках.
Сучасні рішення для пом'якшення наслідків, як локальні, так і хмарні, значно скорочують час простою, підтримують безперервність бізнесу та захищають як локальні активи, так і ресурси публічної хмари. Ключовим є їхня здатність автоматично масштабуватися для обробки величезних стрибків трафіку та пропонувати чіткі гарантії пропускної здатності та часу реагування.
Конкретні методи пом'якшення: від обмеження швидкості до утворення чорних дір
Окрім основних технологічних блоків, існує низка специфічних методів, що щодня застосовуються для боротьби з різними типами атак. Одним із найбазовіших є фільтрація периметра за допомогою брандмауерів та списків контролю доступу (ACL) на маршрутизаторах і комутаторах, що блокують пакети на основі IP-адреси джерела, IP-адреси призначення, портів, прапорців TCP або розміру.
Ще одним класичним компонентом є обмеження швидкості , як на рівнях 3/4, так і в HTTP. У системах Linux iptables пропонує модулі, такі як hashlimit або SYNPROXY, для контролю кількості підключень або пакетів за секунду, що приймаються з однієї IP-адреси. На рівні програми проксі-сервери, такі як Nginx або HAProxy, можуть встановлювати обмеження на запити для кожного клієнта або для кожного маршруту.
Для атак рівня 7 дуже корисно впроваджувати перевірки або додаткову автентифікацію . CAPTCHA, перевірки JavaScript та подібні механізми дозволяють краще розрізняти реальні браузери та автоматизовані боти, зменшуючи навантаження на фактичну програму. У TCP такі методи, як SYN-файли cookie, допомагають серверу уникнути необхідності зберігати стан для кожної спроби з'єднання, доки не буде завершено рукостискання.
Коли обсяг атаки є некерованою навіть для інфраструктури пом'якшення наслідків, можна використовувати чорні діри BGP : інтернет-провайдер анонсує маршрут до атакованої мережі як «чорну діру», відкидаючи весь трафік, призначений для цього префікса, перш ніж він потрапить до магістралі. Це крайній захід, оскільки він робить послугу недоступною, але запобігає впливу атаки на інші частини мережі.
Сервіси очищення хмарних ресурсів, такі як Cloudflare, Akamai, AWS Shield, Google Project Shield, Radware та інші, дозволяють направляти весь трафік до їхніх центрів обробки даних та очищувати його там, застосовуючи певні правила для таких векторів, як посилення Memcached, CLDAP, DNS, NTP, непідсилені UDP-флуди тощо. Кожна заблокована атака живить моделі машинного навчання та бази даних сигнатур, які використовуються в майбутніх зусиллях з пом'якшення наслідків.
Передовий досвід та уроки, отримані в умовах поточних DDoS-атак
З основних інцидентів останніх років можна винести кілька чітких уроків. По-перше, захист пристроїв Інтернету речей має вирішальне значення: значна частина потужності ботнетів, таких як Mirai, Mēris або Aisuru, походить від домашніх маршрутизаторів, камер та інших пристроїв із застарілою прошивкою та заводськими паролями за замовчуванням.
Друге — ми повинні усунути вектори посилення в наших власних мережах: вимкнути непотрібні UDP-сервіси, фільтрувати вихідний трафік NTP, DNS або Memcached, застосувати правила брандмауера, які дозволяють запити лише з авторизованих діапазонів, і періодично перевіряти відкриті порти. Будь-який неправильно налаштований сервер може стати підсилювачем для зловмисника.
Також важливо раннє виявлення аномалій . Такі інструменти, як NetFlow, sFlow, IDS/IPS (Snort, Suricata), платформи аналізу журналів або SIEM, повинні бути налаштовані на сповіщення одразу після появи незвичайних піків трафіку, раптових змін у схемах з'єднання або відомих сигнатур атак. Чим швидше буде активовано реагування, тим менше часу залишиться для ескалації атаки.
У веб-середовищі майже обов'язково використовувати оновлені WAF, CAPTCHA, коли вони відповідають потребам користувача, а також кеші або CDN для поглинання частини навантаження. На системному рівні ввімкнення SYN-файлів cookie, налаштування порогів одночасних підключень та закриття будь-яких несуттєвих служб зменшує ризик атаки.
Зрештою, кожна організація повинна мати задокументований план дій у надзвичайних ситуаціях DDoS : посібник із чіткими кроками, призначеними відповідальними особами, технічними контактами постачальників послуг із пом'якшення наслідків та інтернет-провайдерів, а також попередньо визначеними критеріями щодо того, коли активувати очищення, коли запитувати видалення чорних дір або коли знижувати рівень несуттєвих функцій для захисту основного бізнесу.
Ця тенденція вказує на дедалі швидші, інтенсивніші та адаптивніші атаки, а також на розумніші та більш настроювані засоби захисту. Використання можливостей таких рішень, як Programmable Flow Protection, у поєднанні з постійним моніторингом трафіку, найкращими практиками конфігурації та резервними хмарними архітектурами дозволяє компаніям продовжувати працювати в звичайному режимі навіть посеред пакетного шторму, захищаючи не лише свої дані, але й репутацію та довіру клієнтів.
