Развитие облачных сервисов и IoT-решений без повышенного внимания к информационной безопасности приводит к заражению ботнетами типа Mirai. Так, по данным Cloudflare, в начале сентября 2025 года несколько поставщиков IoT-услуг и облачных сервисов, в том числе Google Cloud, оказались источниками атаки UDP Flood мощностью 11,5 Тбит/с и длительностью 35 секунд. Это сопоставимо с непрерывной потоковой передачей 10 тысяч часов видео высокого качества всего за полминуты. Такие атаки наглядно демонстрируют возможности злоумышленников: теперь DDoS-атаки мощностью в сотни Гбит/с можно проводить без особых усилий, вызывая простои бизнеса на часы, а то и на дни.
В чём же сила этих атак и как с ними бороться? Объясним это в статье и подскажем, какие меры стоит предпринять для смягчения последствий.
Как работает UDP Flood
UDP Flood — это разновидность объёмной DDoS-атаки на транспортном (L4) уровне сети, при которой злоумышленник отправляет большое количество UDP-пакетов на случайные или предопределённые порты узла назначения.
Изначально протокол UDP (User Datagram Protocol) создавался как минималистичный транспорт поверх IP для приложений, которым не требуются механизмы надёжной доставки: подтверждения получения, повторные передачи, управление порядком пакетов. Именно поэтому злоумышленник может непрерывно «поливать» цель в одну сторону, не дожидаясь никакой реакции. Впоследствии эти свойства сделали UDP удобной основой для VoIP, видеостриминга и онлайн-игр — там, где потеря отдельного пакета некритична.
Ещё одна особенность использования протокола UDP — это ответ узла назначения ICMP-сообщением о недоступности сервиса, если порт закрыт и ICMP не ограничен политиками безопасности. Данный процесс нагружает атакуемый сервер обработкой запроса, проверкой наличия сервиса на указанном порту и формированием ответа. Также ответное сообщение должно было бы нагружать и сам источник атаки, однако злоумышленники начали применять технику IP Spoofing, заменяя в пакете IP-адрес отправителя на случайный. Таким образом, используя минимальные ресурсы, атакующий добивается перенасыщения как нисходящего, так и восходящего канала связи.
Ранее мы подробно рассматривали SYN Flood — классическую TCP-атаку, нацеленную на исчерпание таблиц соединений и ресурсов TCP-стека.
Проведем сравнение UDP Flood vs TCP SYN Flood.
| Критерий | UDP Flood | TCP SYN Flood |
| Вычислительные затраты атакующего | Низкие | Высокие |
| Масштабируемость | Высокая | Ограничена поддержанием полуоткрытых соединений |
| Простота подмены IP-адреса | Высокая | Средняя |
| Исчерпание ресурсов | Ширина канала / аппаратные лимиты оборудования (таблицы TCAM, session tables, control-plane CPU) / CPU узла назначения | Количество пользователей сервиса / CPU узла назначения |
| Воздействие на оператора связи | Высокое | Низкое |
| Метод детектирования | Аномалии профиля трафика (PPS/BPS, ассиметрия потока, кратный рост источников) | Отношение SYN пакетов к общему числу (SYN ratio) |
| Метод защиты на уровне атакуемого узла | Ограничение UDP потока (Rate-limiting), защитные механизмы сервисов (DNS RRL, SIP rate control, QUIC Retry Token) | SYN Cookies |
Виды UDP Flood
Знать, что атака работает на транспортном уровне по протоколу UDP, — это лишь первый шаг. Для эффективной защиты важно определить её конкретный тип: механизм, источник трафика и задействованные прикладные протоколы. Без этого меры противодействия могут оказаться либо избыточными, либо неэффективными. Рассмотрим основные разновидности UDP Flood, с которыми чаще всего сталкиваются операторы связи.
UDP Flood через ботнет (non-spoofed)
Сегодня это самый распространённый сценарий. Рост числа уязвимых IoT-устройств, устаревших серверов и домашних роутеров создаёт огромную базу для ботнетов. Трафик идёт с реальных IP заражённых устройств, поэтому пакеты выглядят легитимно и плохо фильтруются.
Риски выходят за пределы атакуемой стороны: оператор, в сети которого находятся заражённые абоненты, может столкнуться с переполнением таблиц CG-NAT из-за массового исходящего трафика. В итоге страдают обычные пользователи, а сам оператор фактически становится невольным участником атаки.
Классический UDP Flood (spoofed)
Старый, но всё ещё актуальный метод: поток UDP-пакетов генерируется с подменёнными адресами отправителя, часто с помощью доступных утилит. Низкий порог входа делает его популярным у начинающих злоумышленников.
Его распространённость постепенно снижается благодаря внедрению BCP38-фильтрации и появлению более эффективных методов усиления. Тем не менее при слабой фильтрации такой тип атаки по-прежнему способен перегружать каналы.
Оба типа могут атаковать один порт или множество случайных. Во втором случае целевой узел дополнительно нагружается обработкой ICMP-ответов.
Отражённый UDP Flood (reflection/amplification)
Особо опасный подвид, использующий открытые сервисы-рефлекторы. Злоумышленник отправляет небольшой запрос с подменённым адресом жертвы, а сервер возвращает значительно больший ответ уже ей. Коэффициент усиления может достигать десятков, сотен и даже тысяч раз, что позволяет создавать огромный трафик при минимальных ресурсах атакующего.
Ковровые и многовекторные атаки
Любой из этих видов может быть направлен не на один хост, а на целую подсеть — так называемый carpet bombing, когда трафик распределяется по множеству адресов и сложнее обнаруживается. На практике злоумышленники часто комбинируют несколько методов одновременно, формируя многовекторные атаки, требующие комплексной защиты.
Как обнаружить UDP Flood
Первый этап построения защиты — научиться своевременно определять и понимать под какую атаку попала инфраструктура.
Первый и наиболее очевидный признак — резкий и аномальный рост входящего трафика. В отличие от органического роста нагрузки, характерного для пиковых часов, атака проявляется как вертикальный всплеск на графике: трафик за секунды возрастает в разы или на порядки. При этом нагрузка на процессор пограничного маршрутизатора или межсетевого экрана стремительно растёт, поскольку оборудование вынуждено обрабатывать каждый входящий пакет.
Параллельно фиксируется деградация качества обслуживания: увеличиваются задержки, растёт процент потерь пакетов для легитимных пользователей, сервисы начинают отвечать с опозданием или перестают отвечать вовсе. В случае атаки на CG-NAT у оператора связи появляются жалобы от абонентов на невозможность установить новые соединения — верный признак исчерпания таблиц трансляций.
Характерная картина при анализе трафика: высокая доля UDP-пакетов с минимальным или фиксированным размером, условно-случайные или явно повторяющиеся порты назначения, аномально высокое число уникальных IP-адресов отправителей (при spoofed-атаках) либо, напротив, трафик с определённых ASN или географических регионов (при ботнет-атаках). При reflection-атаках трафик будет приходить с адресов известных публичных DNS- или NTP-серверов, что само по себе является аномалией. Часто перечень уязвимых серверов распространяется через платформы Threat Intelligence, что позволяет иметь готовый перечень для блокировки или ограничения потока.
Для оперативного обнаружения атак операторы связи, как правило, используют несколько источников для мониторинга.
- NetFlow/sFlow/IPFIX — телеметрия с маршрутизаторов остаётся основным источником данных для анализа трафика на уровне оператора. Коллекторы позволяют в реальном времени строить профили трафика и выявлять аномалии по протоколу, порту, объёму и географии. Пороговые алерты на резкий рост UDP-трафика настраиваются по базовым показателям нормальной нагрузки.
- SNMP-мониторинг интерфейсов маршрутизаторов через Zabbix, Prometheus с SNMP-экспортером или Grafana позволяет фиксировать насыщение каналов и аномальный рост счётчиков ошибок и отброшенных пакетов.
- DPI (Deep Packet Inspection) позволяет проводить анализ на уровне содержимого пакетов, выявляя характерные сигнатуры известных атак, в том числе reflection-трафик от конкретных типов рефлекторов. Решения на базе DPI, например СКАТ DPI от VAS Experts, дают возможность не только детектировать атаку, но и мгновенно применять гранулярные политики фильтрации без блокировки легитимного трафика.
- Системы обнаружения аномалий (NBAD) — специализированные AntiDDoS-решения, которые анализируют поведение трафика относительно базовой линии и автоматически запускают процедуры митигации при выявлении атаки. Время реакции таких систем измеряется секундами, что критически важно при атаках высокой интенсивности. СКАТ AntiDDoS является ярким примером системы данного класса: анализируя данные QoE с помощью нейросетей и алгоритмов машинного обучения, детектор выявляет отклонения от нормы, классифицирует угрозы и определяет их источники.
Методы защиты
Защита от UDP Flood не универсальна: DNS-сервер, SIP-платформа и веб-сервисы атакуются по-разному и требуют разных контрмер. Ниже — практические рекомендации для каждого типа инфраструктуры с конкретными командами и настройками.
Защита DNS-серверов
DNS — двойная мишень: сервер атакуют напрямую, а также используют как рефлектор для атак на других. Авторитетный резолвер с открытым рекурсивным разрешением и без rate limiting — идеальный усилитель для злоумышленника.
Закрыть рекурсию для внешних клиентов
Авторитетный DNS-сервер не должен отвечать на рекурсивные запросы от внешних IP. В BIND:
options { recursion yes; allow-recursion { 192.168.0.0/16; 10.0.0.0/8; }; allow-query-cache { 192.168.0.0/16; 10.0.0.0/8; }; };
В Unbound — запретить запросы от всех, кроме доверенных подсетей через access-control.
access-control: 192.168.0.0/16 allow access-control: 10.0.0.0/8 allow access-control: 0.0.0.0/0 refuse
Response Rate Limiting (RRL)
Ограничивает число ответов одному IP-адресу в единицу времени. Снижает эффективность DNS Amplification и защищает от прямого флуда запросами. Пример для BIND 9.18+:
rate-limit { responses-per-second 15; window 15; slip 2; };
Минимизация ANY-ответов
ANY-запросы дают максимальный amplification factor. Современные версии BIND и Unbound по умолчанию возвращают minimal-any, но стоит явно указать.
minimal-responses yes; // BIND minimal-any yes; // BIND 9.11+
Защита VoIP / SIP-инфраструктуры
SIP работает поверх UDP (порт 5060) и особенно уязвим к флуду: каждый входящий пакет требует разбора на уровне приложения, что быстро истощает ресурсы SBC (Session Border Controller) и Asterisk/FreeSWITCH. Кроме того, SIP-инфраструктура нередко подвергается комбинированным атакам — флуд совмещается с регистрационным спамом и Toll Fraud.
SIP-aware rate limiting на SBC
Session Border Controller должен ограничивать число SIP-сообщений (INVITE, REGISTER, OPTIONS) с одного IP. Пример настройки в Kamailio.
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 16)
modparam("pike", "remove_latency", 4)
Модуль pike блокирует источник при превышении 16 запросов за 2 секунды. Для enterprise-трафика порог следует калибровать под реальную нагрузку.
Ограничение на уровне подсистем ядра Linux
Фильтрация на уровне ОС до попадания пакетов в SIP-стек существенно снижает нагрузку. При использовании iptables:
iptables -A INPUT -p udp --dport 5060 -m hashlimit \ --hashlimit 50/sec --hashlimit-burst 100 \ --hashlimit-mode srcip --hashlimit-name SIP \ -j ACCEPT iptables -A INPUT -p udp --dport 5060 -j DROP
При использовании nftables.
table inet filter {
chain input {
type filter hook input priority 0;
ip protocol udp udp dport 5060 \
limit rate over 50/second burst 100 \
per ip saddr accept
ip protocol udp udp dport 5060 drop
}
}
Значение 50/sec или 50/second подбирается под реальную нагрузку — текущее подойдет для небольшого корпоративного SBC. Ограничение должно применяться per-IP, иначе можно дропнуть легитимный burst-трафик или нарушить RTP-negotiation.
Скрытие SIP-инфраструктуры за SBC
Медиасерверы (Asterisk, FreeSWITCH) не должны иметь публичных IP. SBC принимает весь внешний SIP/RTP-трафик, терминирует его и передаёт во внутреннюю сеть. Это исключает прямые атаки на application-серверы.
Отдельная полоса для RTP-трафика
Media-потоки (RTP/UDP) следует выделить в отдельный диапазон портов и ограничить по полосе на уровне QoS. При атаке флуд на порт 5060 не должен конкурировать с активными голосовыми сессиями.
Важно: SIP OPTIONS flood — популярная атака, имитирующая легитимные keepalive-запросы. Убедитесь, что ваш SBC различает OPTIONS от доверенных пиров и случайных источников, и жёстко ограничивает последних.
Защита веб-сервисов и API
HTTP работает поверх TCP, но UDP Flood поражает веб-инфраструктуру косвенно: насыщая канал и перегружая пограничное оборудование, атака делает недоступными все сервисы, включая веб. Отдельная угроза — QUIC (HTTP/3), работающий поверх UDP/443: злоумышленники всё чаще используют QUIC-рефлекторы или атакуют QUIC-эндпоинты напрямую.
Ограничение UDP/443 (QUIC) при атаке
Если веб-сервер не использует HTTP/3, порт UDP/443 следует закрыть полностью. Если QUIC нужен — внедрите rate limiting аналогично SIP.
ip protocol udp udp dport 443 \ limit rate over 500/second burst 1000 \ per ip saddr accept ip protocol udp udp dport 443 drop
Использование QUIC connection migration с осторожностью
Connection migration в QUIC позволяет смену IP без разрыва соединения — это полезно для мобильных клиентов, но может использоваться для amplification. Контролируйте параметры preferred_address и migration в конфигурации сервера.
Настройка nginx для защиты от атак на QUIC
Помимо сетевых фильтров, можно оптимизировать параметры nginx, чтобы снизить нагрузку при косвенных UDP-атаках.
quic_retry on; quic_max_idle_timeout 30s; quic_max_packet_size 1350;
Убедитесь, что ваша версия nginx поддерживает QUIC и соответствующие директивы. Эти настройки не заменяют защиту на сетевом уровне, а лишь помогают снизить нагрузку на веб-сервер.
Универсальные меры защиты для оператора
uRPF (BCP38)
Фильтрует пакеты с подменёнными адресами прямо на маршрутизаторе — до входа в сеть оператора. Режим strict наиболее эффективен, но требует симметричной маршрутизации; loose подходит для мультихоминга. Пример для Cisco IOS на пограничном интерфейсе:
ip verify unicast source reachable-via rx ! strict mode ip verify unicast source reachable-via any ! loose mode
BGP Flowspec
Позволяет распространить правила фильтрации по всей сети через BGP-анонсы — заблокировать атакующий трафик ближе к источнику, не перегружая центральные узлы. Пример правила для блокировки UDP-флуда на конкретный префикс:
match destination 203.0.113.0/24 protocol udp dst-port 53 then discard
Для применения Flowspec оборудование сети должно поддерживать данный функционал на уровне data plane.
RTBH (Remotely Triggered Black Hole)
Экстренная мера при атаке терабитного диапазона: анонс атакуемого префикса в blackhole-сообщество вышестоящего провайдера. Трафик отбрасывается на стыке — до вашего канала. Жертва временно недоступна, но инфраструктура оператора защищена.
ip route 203.0.113.1/32 Null0 router bgp 65000 network 203.0.113.1/32 route-map BLACKHOLE
Scrubbing-центр
При наличии собственного или арендованного центра очистки трафика атакованный префикс перенаправляется через него по BGP. Scrubbing-центр фильтрует аномальный трафик и возвращает чистый поток по GRE- или MPLS-туннелю к оператору.
Защита от VAS Experts
Система СКАТ AntiDDoS обеспечивает комплексную защиту от UDP Flood на операторском уровне, объединяя DPI, поведенческий анализ и автоматическую митигацию в едином решении.
| Возможность | Описание |
| DPI на скорости линии | Анализ трафика до 5 Тбит/с без деградации производительности |
| Packet rate detection (Mpps-level) | Мгновенное выявление аномального роста PPS и защита от packet-rate атак, нагружающих CPU и control-plane оборудования |
| Гранулярная фильтрация | По протоколу, порту, размеру пакета, географии — без блокировки легитимного трафика |
| Защита CG-NAT | Контроль исходящего флуда, предотвращение исчерпания таблиц трансляций |
| BGP-интеграция | Автоматический запуск RTBH и Flowspec при детектировании атаки |
| Carpet bombing detection | Агрегированный анализ на уровне AS — выявляет распределённые атаки на подсети |
| Inline-фильтрация в data-plane | Митигация непосредственно на узле оператора без вывода трафика в внешний scrubbing-центр — полный цикл защиты внутри одной платформы |
Кейсы
Разбор публичных инцидентов позволяет не только оценить масштаб современных угроз, но и извлечь практические уроки для собственной инфраструктуры.
Кейс 1 — GitHub, февраль 2018
| Мощность атаки | 1,35 Тбит/с (рекорд на тот момент) / 126,9 Mpps |
| Длительность | ~10 минут |
| Вектор | Memcached UDP Amplification (порт 11211), ~50 000 рефлекторов |
| Коэффициент | до 51 000x (1 байт запроса → 51 КБ ответа) |
| Последствия | GitHub был недоступен несколько минут до переключения на Akamai Prolexic |
| Главная мысль | Memcached не должен быть доступен из интернета. UDP/11211 следует закрыть глобально |
| Как предотвратили | Перенаправление трафика через scrubbing-центр Akamai поглотило атаку за ~8 минут |
Кейс 2 — NDA клиент Microsoft Azure, ноябрь 2021
| Мощность атаки | 3,47 Тбит/с / 340 млн пакетов в секунду |
| Длительность | ~15 минут |
| Вектор | UDP Reflection на порту 80 с одновременным использованием четырёх протоколов-усилителей: SSDP, CLDAP, DNS и NTP. |
| Распределённость | Атака исходила примерно с 10 000 источников из 10 стран — США, Китая, Южной Кореи, России, Таиланда, Индии, Вьетнама, Ирана, Индонезии и Тайваня |
| Цель | Корпоративный клиент Microsoft Azure в Азии (публично не раскрыт) |
| Последствия | Отсутствуют, произведена автоматическая митигация без участия оператора |
| Главная мысль | Многовекторный amplification — новая норма; защита должна быть автоматизирована |
| Как предотвратили | Azure DDoS Protection; далее — inline-защита через NVA с Gateway Load Balancer |
Кейс 3 — NDA клиент Cloudflare, сентябрь 2024
| Мощность атаки | 3,8 Тбит/с / 2,14 млрд пакетов в секунду |
| Длительность | ~65 секунд |
| Вектор | UDP Flood через ботнет (роутеры ASUS, DVR, VPN-серверы) |
| Цель | Клиент Cloudflare из финансового сектора |
| Последствия | Отсутствуют, произведена автоматическая митигация без участия оператора |
| Главная мысль | Атаки терабитного диапазона стали обыденностью; ручная реакция невозможна |
| Как предотвратили | Автоматические системы Anycast + поведенческий анализ + instant Flowspec |
Кейс 4 — DDoS scrubbing в Западной Европе, сентябрь 2025
| Мощность атаки | 1,5 млрд пакетов/с — один из наибольших по packet rate инцидентов в публичной истории |
| Вектор | ~65 секунд |
| Вектор | UDP Flood через ботнет из CPE/IoT-устройств; более 11 000 уникальных сетей по всему миру |
| Цель | Веб-сайт европейского DDoS scrubbing-вендора FastNetMon — попытка обезоружить саму систему защиты |
| Проблема | Трафик на отдельный IP ниже порогов алертов, но магистраль насыщена |
| Последствия | Нулевые для пользователей; инцидент раскрыт FastNetMon публично |
| Главная мысль | Высокая частота мелких UDP-пакетов нагружает CPU сетевых устройств сильнее, чем объемные атаки |
| Как предотвратили | FastNetMon Advanced обнаружил всплеск за секунды и автоматически перенаправил и отбросил вредоносный трафик до насыщения канала |
Заключение
UDP Flood — не единственная, но одна из наиболее разрушительных форм DDoS-атак. Connectionless-природа протокола UDP делает его идеальным вектором: нет необходимости устанавливать соединение, нет встроенной защиты от спуфинга, а amplification-механизмы способны превратить скромные ресурсы атакующего в терабиты мусорного трафика.
Современные атаки стали автоматизированными, многовекторными и короткими по длительности — что исключает ручную реакцию и требует автоматических систем обнаружения и митигации. Ковровые атаки дополнительно обходят классический пороговый мониторинг. В этих условиях побеждает тот, у кого выстроена эшелонированная защита, а не набор разрозненных инструментов.
Краткая памятка: что необходимо сделать
- Внедрить uRPF(BCP38) на всех пограничных интерфейсах — это фундамент;
- Настроить NetFlow/sFlow телеметрию с анализом на уровне AS, а не только отдельных хостов;
- Закрыть открытые рекурсивные DNS-резолверы и применить RRL на авторитетных серверах;
- Разместить SIP-инфраструктуру за SBC с rate limiting на уровне приложения;
- Ограничить или закрыть UDP/443 (QUIC) там, где HTTP/3 не используется;
- Иметь готовые процедуры RTBH и BGP Flowspec — не настраивать под давлением атаки;
- Рассмотреть внедрение DPI-платформы для видимости трафика на уровне пакета.
