Как нейтрализовать ботнет в операторской сети

Разберем, что происходит внутри CG-NAT при ботнет-нагрузке, почему страдают обычные абоненты и какие инструменты позволяют это остановить.

Как ботнет «съедает» ресурсы CG-NAT

Большинство операторов использует технологию CG-NAT (Carrier-Grade NAT). Это технология, при которой оператор связи использует один публичный IPv4-адрес сразу для группы абонентов. Абоненты получают приватные IP-адреса, а при выходе в интернет их трафик проходит через общий шлюз, где подменяется на один из публичных адресов оператора.

Это решает проблему дефицита адресного пространства, но одновременно создает зависимость – ресурс NAT конечен.

Оператор обычно распределяет NAT-порты с переподпиской. Одному абоненту может выделяться до 2000 портов, при этом  за одним публичным IP одновременно работают десятки пользователей. В теории это дает сотни тысяч соединений, но физический лимит остаётся прежним — около 64 000 портов на один IP-адрес.

Когда несколько абонентов с зараженными устройствами, которым выделен один публичный адрес, начинают генерировать тысячи коротких UDP-сессий, они мгновенно выбирают весь выделенный пул портов.

В результате легитимные абоненты, использующие тот же адрес, вынуждены конкурировать за порты с BotNet устройствами и перестают получать новые соединения – браузеры зависают, звонки обрываются, стриминг прерывается. При этом сам зараженный пользователь часто даже не подозревает, что его устройство участвует в атаке.

Что происходит с NAT под ботнет-нагрузкой

Кроме того, ботнет-атаки напрямую влияют на производительность CG-NAT. Ботнет-флуд становится стресс-тестом для неочевидных путей линейного поиска в коде NAT. Обычный абонент поддерживает в среднем несколько десятков или сотни одновременных соединений. Тогда как как зараженное устройство создает тысячи в секунду. При этом трафик ботнета имеет принципиально отличающиеся от обычного пользователя паттерны.

В итоге такой трафик:

• быстро заполняет таблицы трансляции;
• перегружает очереди
• создает конкуренцию за ресурсы между потоками.

Если в коде есть хоть один неоптимальный путь – ботнет его с высокой вероятностью сделает его узким горлышком. В результате деградирует не только доступность, но и производительность всей системы NAT. Поэтому при оптимизации продукта CG-NAT разработчики VAS Experts учитывают не только поведение нормального трафика, но и возможные сценарии атак, которые могут повлиять на устойчивость всей системы.

Главный источник ботнетов — абонентские устройства

Основной вектор заражения – домашние и SOHO-роутеры, давно не получавшие обновлений безопасности. АНБ США в апреле 2026 года официально призвало пользователей обновить прошивки маршрутизаторов, зафиксировав волну атак через устаревшие устройства.

Рекомендации регуляторов сводятся к базовой гигиене: сменить стандартные логины и пароли, отключить удаленное управление из интернета, установить актуальную прошивку, а устройства без поддержки производителя – заменить. Однако на практике большинство домашних пользователей не выполняет эти требования самостоятельно.

Это означает, что оператору приходится защищать не только свою инфраструктуру, но и абонентские устройства – иначе ущерб от ботнета распределяется на всех.

Черные списки IP: проблема для всей абонентской базы

Второй критический эффект ботнета – попадание IP-адресов оператора в стоп-листы. Когда заражённые хосты начинают рассылать спам, участвовать в DDoS-атаках или сканировать интернет, публичные IP оператора фиксируются в блэклистах таких сервисов, как Spamhaus, AbuseIPDB, Cloudflare Radar и других.

В результате проблема выходит за пределы отдельного инцидента. Оператор сталкивается не только с техническим риском, но и с репутационными потерями. Пользователи воспринимают ограничения как сбой сервиса, а не как последствия заражения в сети.

Дополнительно усложняется диагностика. В условиях CG-NAT привязать вредоносную активность к конкретному абоненту становится сложнее, а процесс очистки IP-репутации занимает время и требует взаимодействия с внешними сервисами.

Для оператора это уже не локальная проблема безопасности, а фактор, напрямую влияющий на качество услуги и удержание абонентов.

Как это работает на практике: обнаружение и митигация UDP-флуда

Рассмотрим практический пример обнаружения ботнет-активности и её нейтрализации у одного из операторов – клиентов VAS Experts.

Шаг 1. Обнаружение атаки через QoE Analytics

В модуле QoE Analytics по пути QoE Analytics → DDoS Attacks → Top Attacks выгрузили статистику за последние 24 часа. Сортировку задали по столбцу Sessions в порядке убывания, чтобы сразу увидеть самые «тяжелые» по сессиям направления.

В обычной ситуации верх списка выглядит достаточно равномерно, значения могут отличаться, но без резких скачков. Однако, в текущей ситуации, в топе выделяется аномальная активность на одном из внутренних адресов — адрес 10.248.90.181 — количество сессий радикально превышает норму.

Шаг 2. Анализ трафика и сигнатур атаки

Перешли в QoE Analytics → DDoS Attacks Log, чтобы посмотреть, из чего именно складывается такая нагрузка. Период оставили тем же — Last 24 hours, добавили фильтр Target IP address = 10.248.90.181 и снова отсортировали по Sessions.

Фильтрация лога по целевому IP-адресу 10.248.90.181 выявляет характерную картину:

Протокол ~99% трафика – UDP (Net protocol: 17)	Сессий на запись ~12 000–13 000 на каждую запись лога	Пакетов на поток Медиана 2-4 пакета (очень короткие потоки)
Целевой порт Почти весь трафик бьёт в порт 41880	Порты атакующего Большой разброс – типично для ботнета	Вывод UDP Flood – объёмная DDoS-атака с ботнета

Почти весь трафик оказался UDP (Net protocol: 17). TCP практически не встречался, поэтому вариант с обычной пользовательской активностью — веб, стриминг, мессенджеры — можно сразу отложить.

Дальше разобрали структуру записей. В логе оказалось много строк, и каждая описывала короткий поток с очень большим числом сессий. По отдельным записям выходило примерно 12 000–13 000 sessions, но при этом на поток приходилось всего 2–4 packets.

Получается, что большое количество записей (десятки тысяч) с малым числом пакетов на поток и огромным числом сессий – классическая сигнатура ботнета, генерирующего короткие UDP-сессии.

После этого посмотрели, куда именно идет трафик. В полученном отчете видим большое количество портов в столбце Event Object. А почти все записи указывали на один и тот же целевой порт — 41880. Значит, нагрузка была не случайной, а направленной в конкретную точку. Разброс портов на стороне источника исключает одиночный источник атаки и подтверждает координированное участие множества зараженных устройств.

Перед нами классическая картина UDP Flood, распределенного по множеству источников.

Шаг 3. Автоматизированная митигация

Процесс нейтрализации запускается автоматически по следующей цепочке:

1. QoE детектор. Обнаружение аномалии количеству сессий
2. Список IP-атакующих. Формирование контейнера Attacks
3. GUI / сценарий. Назначение профиля UDP UNKNOWN DROP
4. Отгрузка на DPI. Применение блокировки на узлах сети
5. Снятие блокировки. Раз в сутки при отсутствии атак

Весь цикл – от вставки дампа до применения профиля на DPI – занимает несколько минут. При обнаружении атаки на DPI применяется профиль UDP UNKNOWN – DROP для абонентов, попавших в контейнер. Под блокировку попадает весь UDP-трафик, который классифицируется как UNKNOWN.

Контейнер пересматривается раз в сутки. Если за это время повторной активности не фиксировалось, IP автоматически исключается, и блокировка снимается автоматически.

Для оперативного контроля настроена отправка уведомлений в Telegram-канал при каждом изменении контейнера атак:

• Добавление IP → мгновенно при обнаружении.
• Удаление IP → раз в сутки в полночь.

Инженер может в любой момент проверить текущее состояние контейнеров и блокировок в CLI.

СКАТ AntiDDoS – защита сети оператора от DDoS и ботнетов

Платформа СКАТ AntiDDoS выявляет и блокирует атаки в реальном времени. Модуль QoE Analytics собирает IPFIX Fullflow со СКАТ DPI, строит эталонный профиль нормального  трафика и с помощью нейросетевых алгоритмов выявляет отклонения – включая ботнет-активность, UDP Flood и SYN Flood.

При обнаружении атаки система автоматически:

• формирует список атакующих IP,
• применяет профиль блокировки на DPI,
• снимает ограничения после нормализации трафика.

Почему оператор обязан бороться с ботнетом в своей сети?

Во-первых, ботнет-трафик напрямую исчерпывает ресурс NAT. Один зараженный абонент может занять порты, рассчитанные на десятки других пользователей. Во-вторых, публичные IP-адреса оператора попадают в международные стоп-листы, и ограничения начинают испытывать все клиенты за этим адресом, а не только источник проблемы. В-третьих, устройства с устаревшими прошивками заражаются повторно, если не предпринимать централизованных мер.

В таких условиях автоматизация становится обязательной. Ручная реакция занимает часы и плохо масштабируется. Автоматизированные сценарии на базе QoE и DPI позволяют выявлять аномалии и ограничивать вредоносную активность за минуты, без постоянного участия инженеров в каждом инциденте.