IoT Botnet DDoS: атаки через камеры, роутеры и умные устройства

IoT Botnet DDoS — распределённая атака, в которой трафик генерируется большим количеством скомпрометированных устройств интернета вещей. В ботнет могут входить домашние маршрутизаторы, IP-камеры, видеорегистраторы, телевизоры, медиаприставки, сетевые накопители, принтеры, промышленные контроллеры и другие постоянно подключённые устройства.

Каждый отдельный узел обычно обладает ограниченной производительностью. Но массовость, постоянное подключение и географическая распределённость позволяют IoT-ботнету создавать мощные UDP, TCP, GRE и прикладные атаки.

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

Что относится к IoT

IoT, или Internet of Things, — физические устройства с программным обеспечением, сетевым подключением, датчиками или управляющими функциями. Они обмениваются данными с локальной сетью, облачным сервисом или другими устройствами.

К IoT можно отнести:

• домашние и офисные маршрутизаторы;
• IP-камеры;
• DVR и NVR;
• умные телевизоры;
• Android TV-приставки;
• сетевые хранилища;
• принтеры;
• умные колонки;
• домофоны;
• системы контроля доступа;
• датчики и контроллеры;
• интеллектуальное освещение;
• умные розетки;
• медицинские устройства;
• промышленное оборудование;
• телематические системы;
• устройства «умного дома».

В контексте ботнетов к IoT часто также относят SOHO-оборудование — маршрутизаторы и сетевые устройства для дома и малого офиса.

Что такое IoT-ботнет

IoT-ботнет — сеть устройств интернета вещей, скомпрометированных вредоносным программным обеспечением или через несанкционированный доступ. Злоумышленник централизованно либо распределённо управляет ими и использует для DDoS, проксирования, сканирования, распространения malware и других задач.

FBI в совместных рекомендациях описывает ботнеты на основе семейства Mirai, заражающие Linux-устройства, включая IP-камеры, веб-камеры, видеорегистраторы и маршрутизаторы.

Почему IoT-устройства удобны для ботнетов

Они работают круглосуточно

Камера, маршрутизатор или видеорегистратор обычно включены постоянно. Бот остаётся доступным дольше заражённого ноутбука или телефона.

Редко обновляются

Пользователь может годами не проверять наличие новой прошивки. Производитель, в свою очередь, может прекратить поддержку модели.

Используют стандартные учётные данные

Некоторые устройства поставляются с предустановленными логином и паролем. Если владелец не меняет их, одинаковые комбинации могут работать на большом числе устройств.

Имеют открытые административные интерфейсы

Веб-панель, Telnet, SSH, TR-069, UPnP или фирменный управляющий сервис могут быть доступны из интернета из-за заводской конфигурации или ошибки пользователя.

Имеют одинаковые прошивки

Одна уязвимость может затронуть множество экземпляров одной модели или несколько брендов, использующих общий OEM-компонент.

Плохо инвентаризируются

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

Не поддерживают полноценную защиту

На IoT часто невозможно установить EDR, антивирус или расширенный агент мониторинга.

Владелец не замечает заражение

Основная функция устройства продолжает работать. Камера передаёт изображение, а маршрутизатор обеспечивает доступ в интернет, одновременно участвуя в DDoS.

Находятся в обычных провайдерских сетях

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

Почему старые маршрутизаторы особенно опасны

Маршрутизатор является привлекательной целью, потому что:

• расположен на границе домашней или офисной сети;
• постоянно подключён к интернету;
• видит трафик внутренних устройств;
• может обладать публичным IP;
• часто работает много лет без замены;
• имеет достаточно ресурсов для proxy и DDoS;
• может скрывать вредоносную активность за обычным пользовательским трафиком.

FBI отдельно предупреждало о компрометации маршрутизаторов с завершившейся поддержкой, особенно при включённом удалённом администрировании.

Как IoT-устройство становится частью ботнета

Типовая цепочка включает:

1. обнаружение доступного устройства;
2. определение модели, сервиса или версии прошивки;
3. получение несанкционированного доступа;
4. запуск вредоносного компонента;
5. подключение к управляющей инфраструктуре;
6. получение команд;
7. участие в сканировании или DDoS;
8. попытку сохранить доступ либо повторно заразить устройство.

Основные причины компрометации:

• стандартные пароли;
• слабые пароли;
• отсутствие ограничения попыток входа;
• известные уязвимости;
• устаревшая прошивка;
• открытые служебные порты;
• небезопасное удалённое управление;
• непроверенные приложения и плагины;
• уязвимый облачный сервис;
• компрометация цепочки поставок;
• злоупотребление встроенной proxy-функцией.

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

Что такое Mirai

Mirai — известное семейство вредоносного программного обеспечения для IoT, получившее широкую известность после крупных DDoS-атак. Оно заражало доступные из интернета устройства, использовавшие слабые или стандартные учётные данные.

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

Cloudflare описывает Mirai как malware, превращающее IoT-устройства под управлением облегчённых Linux-систем в удалённо контролируемых ботов.

Почему Mirai остаётся важным примером

• показал масштаб проблемы стандартных паролей;
• продемонстрировал мощность большого числа слабых устройств;
• стал основой для многочисленных вариантов;
• подтвердил возможность многовекторных атак через IoT;
• показал зависимость интернета от безопасности потребительского оборудования;
• создал модель, которую продолжают воспроизводить новые семейства.

Не всякая IoT-атака является Mirai. Использование названия Mirai для любого IoT-ботнета технически некорректно.

Архитектура IoT-ботнета

Компонент	Функция
Scanner	Ищет потенциально доступные устройства
Loader	Доставляет или запускает вредоносный компонент
Bot	Выполняет команды и генерирует трафик
Command and Control	Передаёт цель, вектор и параметры
Botmaster	Управляет инфраструктурой
Промежуточные серверы	Скрывают C2 и повышают устойчивость
Панель DDoS-for-hire	Может предоставлять доступ сторонним заказчикам

Некоторые IoT-ботнеты используют централизованные C2, другие — несколько резервных доменов, IP-адресов, proxy-слоёв или peer-to-peer-компоненты.

Какие DDoS-векторы используют IoT-ботнеты

UDP Flood

Устройство отправляет большое количество UDP-дейтаграмм на один или несколько портов цели. UDP не требует предварительного соединения и подходит для генерации stateless-трафика.

Целями становятся:

• пропускная способность;
• пакетная производительность;
• UDP-сервис;
• firewall;
• общий канал дата-центра.

TCP SYN Flood

Боты создают множество попыток установления соединения. Сервер или промежуточное устройство хранит состояние полуоткрытых сессий либо тратит ресурсы на их проверку.

TCP ACK Flood

Большое количество ACK-пакетов заставляет stateful firewall и сервер искать соответствующее соединение. Мелкие пакеты создают высокий pps.

TCP PSH-ACK Flood

Может имитировать передачу данных внутри соединения. Если бот завершает handshake, нагрузка способна пройти до приложения.

GRE Flood

Некоторые IoT-ботнеты поддерживают GRE-пакеты, создающие нагрузку на канал, маршрутизатор и обработку туннельного трафика.

ICMP Flood

Массовый поток ICMP Echo или других сообщений занимает полосу и нагружает сетевое оборудование.

Random Packet Flood

Изменяются адреса, порты, флаги, размеры и полезная нагрузка. Это затрудняет фильтрацию одной статической сигнатурой.

HTTP Flood

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

Multi-vector DDoS

Ботнет может чередовать UDP, TCP, GRE и прикладные векторы либо использовать несколько типов одновременно.

Direct-path и отражённые IoT-атаки

Direct-path Flood

Заражённое устройство отправляет трафик непосредственно жертве. При отсутствии spoofing в логах виден публичный IP владельца устройства.

Reflection Flood

Устройство отправляет запросы сторонним сервисам с подменённым адресом жертвы. Ответы поступают цели от отражателей.

В этом случае:

• источник ответа не обязательно заражён;
• бот может вообще не появиться в логах жертвы;
• подмена требует сети без эффективного egress filtering;
• защита анализирует отражённый протокол и поведение ответов.

Чем IoT-ботнет отличается от серверного ботнета

Критерий	IoT-ботнет	VPS/Cloud-ботнет
Мощность одного узла	Обычно невысокая	Высокая
Количество узлов	Может быть очень большим	Обычно меньше
Тип сети	Домашняя, мобильная, корпоративная	Дата-центр или облако
Стабильность подключения	Обычно высокая для камер и роутеров	Высокая до блокировки аккаунта
Сложность HTTP-поведения	Часто ограниченная	Высокая
Репутация IP	Может выглядеть как обычная резидентская сеть	Легче классифицируется как hosting
Обновление защиты владельцем	Часто нерегулярное	Зависит от администратора и образа

Чем IoT-ботнет отличается от мобильного

Мобильные устройства меняют сети, работают от аккумулятора, часто находятся за CGNAT и имеют полноценные приложения. IoT-устройства обычно:

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

Почему IoT-ботнет сложно блокировать

Большое число адресов

Ручной denylist быстро становится непрактичным.

Резидентские сети

Полная блокировка домашнего провайдера затрагивает реальных посетителей.

CGNAT

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

Динамические IP

После переподключения заражённый маршрутизатор получает новый адрес, а прежний передаётся другому пользователю.

Большое географическое распределение

Устройства могут находиться в десятках стран и тысячах автономных систем.

Невысокая скорость одного бота

Один узел не превышает индивидуальный лимит, но вся сеть создаёт высокий суммарный поток.

IPv6

Устройство может иметь несколько IPv6-адресов, а блокировка одного адреса не всегда охватывает его префикс.

Как распознать IoT Botnet DDoS

Одного универсального признака не существует. Необходимо объединять сетевую, географическую, протокольную и поведенческую телеметрию.

Сетевые признаки

• множество источников из домашних ISP;
• большое количество ASN;
• одинаковая структура пакетов;
• одинаковые TCP-флаги;
• сходные размеры пакетов;
• синхронное начало активности;
• высокий общий pps;
• низкая скорость отдельного источника;
• короткие повторяющиеся импульсы;
• быстрое переключение UDP, TCP и GRE;
• одинаковые нестандартные ошибки реализации;
• распределение по IPv4 и IPv6.

Признаки прикладного IoT-ботнета

• простые повторяющиеся HTTP-запросы;
• неполный набор браузерных заголовков;
• редкое выполнение JavaScript;
• непоследовательная работа с cookies;
• отсутствие загрузки CSS, JS и изображений;
• одинаковые TLS-отпечатки;
• ошибки в синтаксисе HTTP;
• запросы к одному endpoint;
• регулярные интервалы;
• быстрая синхронная смена URL.

Эти признаки не абсолютны. Некоторые устройства используют полноценные библиотеки и способны формировать корректный HTTPS-трафик.

Как отличить IoT-ботнет от обычных посетителей

Признак	Легитимные пользователи	IoT-ботнет
Навигация	Разнообразная и связная	Часто ограничена одним маршрутом
Зависимые ресурсы	Загружаются браузером	Могут отсутствовать
JavaScript	Обычно выполняется	Часто не выполняется
Cookies	Последовательно сохраняются	Игнорируются или повторяются
Интервалы запросов	Неравномерные	Машинно регулярные
Бизнес-действия	Есть конверсии	Полезные действия отсутствуют
Смена поведения	Независимая	Синхронная у большой группы

Почему геолокации недостаточно

IoT-устройства распределены по миру. Блокировка страны может уменьшить трафик, но:

• затронет реальных посетителей;
• не остановит ботов из разрешённых стран;
• ботнет может изменить географическую группу;
• геоданные могут быть неточными;
• часть адресов принадлежит международным операторам;
• IPv6 и CGNAT усложняют классификацию.

GeoIP следует использовать как один сигнал, а не как единственный критерий.

Какие метрики собирать

Метрика	Что показывает
Общий bps и pps	Мощность атаки
Количество уникальных IP	Размер наблюдаемой группы
Количество ASN	Распределённость по сетям
Доля residential/mobile/hosting	Тип источников
Пакеты на один IP	Интенсивность отдельного бота
Распределение протоколов	UDP, TCP, ICMP, GRE и другие векторы
Распределение TCP-флагов	SYN, ACK и смешанные атаки
TLS fingerprints	Технически одинаковые клиенты
HTTP headers	Общие библиотеки и шаблоны
RPS по endpoint	Прикладную цель
Challenge success rate	Способность группы проходить проверку
Business conversion rate	Полезность трафика

Как защитить сайт от IoT Botnet DDoS

1. Использовать upstream-очистку

Объёмный поток необходимо фильтровать до внешнего канала сайта. Локальный firewall не освобождает уже занятую линию.

Защита должна поддерживать:

• высокий bps;
• высокий pps;
• UDP и TCP;
• GRE и другие IP-протоколы;
• IPv4 и IPv6;
• короткие импульсные атаки;
• автоматическое переключение векторов.

2. Не полагаться только на блокировку IP

Нужны дополнительные уровни:

• лимиты по подсети;
• анализ ASN;
• анализ типа сети;
• TLS fingerprinting;
• поведенческая группировка;
• лимиты по endpoint;
• общая квота на дорогие операции;
• адаптивные challenge-механизмы.

3. Защитить TCP

Применяются:

• SYN cookies;
• SYN proxy;
• TCP proxy;
• лимиты новых соединений;
• раннее отбрасывание invalid;
• защита conntrack;
• безопасные таймауты;
• ограничение ответных RST.

4. Отделять сетевой и прикладной Flood

После удаления UDP или SYN Flood необходимо проверить, не продолжается ли HTTP-атака. Нормализация сетевых метрик не гарантирует восстановления приложения.

5. Использовать поведенческую bot detection

Резидентский IP не означает, что клиент является человеком. Следует анализировать:

• последовательность запросов;
• загрузку зависимых ресурсов;
• cookies;
• TLS fingerprint;
• скорость действий;
• историю клиента;
• реакцию на challenge;
• связь запросов с бизнес-действиями.

6. Защищать тяжёлые endpoint отдельно

Для поиска, авторизации, API, генерации отчётов и других дорогих функций устанавливаются:

• отдельные rate limits;
• лимиты на сессию;
• лимиты на аккаунт;
• короткие backend timeouts;
• очереди;
• circuit breaker;
• кэширование;
• деградированный режим;
• обязательная авторизация при необходимости.

7. Автоматизировать реакцию

IoT-ботнет может создавать кратковременные всплески, заканчивающиеся до ручного вмешательства. Обнаружение и фильтрация должны работать автоматически.

Как защитить собственные IoT-устройства

Организация должна предотвращать использование своей инфраструктуры в чужих атаках.

1. Провести инвентаризацию

Для каждого устройства нужно знать:

• производителя;
• модель;
• серийный номер;
• версию прошивки;
• IP- и MAC-адрес;
• сетевой сегмент;
• владельца;
• срок поддержки;
• доступные сервисы;
• метод обновления.

2. Заменить стандартные пароли

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

3. Отключить прямой доступ из интернета

Административные интерфейсы не должны быть общедоступными. Для удалённого управления лучше использовать:

• VPN;
• management VLAN;
• allowlist адресов;
• jump host;
• централизованный контроллер;
• многофакторную аутентификацию, если она поддерживается.

4. Обновлять прошивки

Следует заранее определить процесс проверки, тестирования и установки обновлений. Если модель больше не поддерживается, её необходимо заменить либо максимально изолировать.

5. Отключить неиспользуемые сервисы

Telnet, UPnP, удалённый web management, старые API и сервисы обнаружения не должны оставаться включёнными без необходимости.

6. Сегментировать IoT

Камеры, принтеры и контроллеры не должны находиться в одной доверенной сети с:

• рабочими станциями;
• серверами;
• базами данных;
• системами управления;
• резервными копиями;
• административными интерфейсами.

IoT-сегмент должен иметь минимально необходимый доступ.

7. Ограничить исходящий трафик

Устройство должно обращаться только к необходимым сервисам. Полезны:

• egress ACL;
• DNS-фильтрация;
• лимиты исходящего pps;
• запрет spoofing;
• контроль неизвестных протоколов;
• мониторинг новых назначений;
• блокировка нежелательных стран и сетей при наличии обоснования.

8. Контролировать жизненный цикл

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

При закупке следует проверять:

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

Как обнаружить заражённое IoT-устройство

Сетевые признаки

• неожиданный исходящий UDP;
• высокий pps;
• массовые соединения с внешними адресами;
• сканирование портов;
• периодические обращения к неизвестному C2;
• DNS-запросы к подозрительным доменам;
• трафик в страны, не связанные с функцией устройства;
• GRE или другие неожиданные протоколы;
• изменение обычного профиля;
• исходящие соединения в нерабочее время.

Признаки на самом устройстве

• высокая загрузка CPU;
• перегрев;
• нестабильность;
• самопроизвольная перезагрузка;
• изменение конфигурации;
• новые администраторы;
• неизвестные процессы;
• невозможность обновить прошивку;
• перенаправление DNS;
• изменение правил firewall.

Многие IoT-устройства почти не предоставляют локальную телеметрию, поэтому основным источником обнаружения становится сетевой мониторинг.

Что делать при обнаружении заражённого IoT

1. Изолировать устройство. Отключить его от интернета и доверенных сегментов.
2. Сохранить данные. Зафиксировать IP, MAC, модель, прошивку и сетевую активность.
3. Сменить учётные данные. Включая связанные облачные аккаунты.
4. Установить актуальную прошивку. Только из официального источника.
5. Выполнить безопасный сброс. Если это предусмотрено инструкцией производителя.
6. Отключить ненужные сервисы.
7. Проверить соседние устройства. Бот мог сканировать локальную сеть.
8. Настроить сегментацию и egress control.
9. Заменить устройство. Если поддержка прекращена или доверие восстановить нельзя.
10. Продолжить мониторинг. Проверить, не возобновилась ли связь с C2.

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

Почему WAF не останавливает IoT-ботнет полностью

IoT-ботнет может использовать UDP, ICMP, GRE, TCP SYN и другие сетевые векторы, не содержащие HTTP. Такой поток не поступает в WAF.

WAF участвует только в HTTP/HTTPS-части атаки. При этом обычных сигнатур недостаточно, поскольку запрос может быть синтаксически корректным.

Для эффективной защиты нужны:

• L3/L4-очистка;
• TCP proxy;
• WAF;
• bot detection;
• поведенческий анализ;
• rate limiting;
• закрытый origin.

Какую роль играет TrafficVeil

TrafficVeil работает как reverse proxy для сайтов и защищает HTTP/HTTPS-трафик. При атаке через IoT-ботнет сервис может:

• не допускать внешние соединения непосредственно к origin;
• фильтровать L7 DDoS;
• выявлять автоматизированные запросы;
• анализировать поведение и технические признаки клиента;
• применять WAF;
• ограничивать частоту запросов;
• защищать отдельные маршруты сайта;
• снижать нагрузку на backend.

Обязательное условие — закрытый origin. Сервер должен принимать HTTP/HTTPS только от разрешённых адресов TrafficVeil по IPv4 и IPv6.

Если реальный IP доступен напрямую, IoT-ботнет может обойти reverse proxy и отправить UDP, TCP или HTTP Flood непосредственно на сервер.

Объёмная часть атаки, способная заполнить внешний канал, должна фильтроваться оператором или специализированной L3/L4 anti-DDoS-сетью.

Что делать во время IoT Botnet DDoS

1. Определить активные протоколы. UDP, TCP, ICMP, GRE, HTTP или комбинация.
2. Измерить bps, pps и RPS. Найти основной ресурс перегрузки.
3. Проверить типы сетей. Выделить residential, mobile и hosting.
4. Определить spoofing. Не считать каждый адрес реальным ботом автоматически.
5. Найти общие fingerprints. Пакеты, TLS, HTTP и поведение.
6. Перенести объёмную фильтрацию upstream.
7. Защитить TCP и conntrack.
8. Применить поведенческую L7-фильтрацию.
9. Ограничить дорогие endpoint.
10. Не блокировать всех домашних пользователей.
11. Закрыть origin по IPv4 и IPv6.
12. Следить за переключением вектора.

Какие данные сохранить

• время начала, пика и окончания;
• целевые IP, порты и URL;
• пиковые bps, pps и RPS;
• распределение протоколов;
• количество источников;
• распределение по ASN и странам;
• тип сетей источника;
• долю IPv4 и IPv6;
• размеры пакетов;
• TCP-флаги;
• TLS fingerprints;
• HTTP-заголовки;
• User-Agent;
• последовательности запросов;
• результаты challenge;
• коды HTTP-ответов;
• NetFlow, sFlow или IPFIX;
• ограниченный PCAP;
• изменения правил и их эффект.

Распространённые ошибки

Называть любой ботнет Mirai

Mirai — конкретное семейство и основа множества вариантов, но существуют и другие IoT-ботнеты.

Блокировать все домашние сети

В них находятся реальные пользователи, а заражённые устройства распределены между большим числом операторов.

Полагаться только на IP reputation

Резидентский адрес может не иметь негативной истории до начала атаки.

Использовать только CAPTCHA

CAPTCHA не останавливает UDP, SYN, ACK, GRE и другие сетевые векторы.

Ограничивать только один IP

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

Считать перезагрузку лечением

Уязвимое устройство может быть заражено повторно сразу после подключения.

Оставлять IoT в доверенной сети

Компрометация камеры или принтера тогда создаёт риск для серверов и рабочих станций.

Эксплуатировать устройства после окончания поддержки

Новые уязвимости могут остаться без исправления.

Оставлять origin доступным напрямую

Ботнет получает возможность обойти reverse proxy.

Чек-лист защиты сайта

• Подключена upstream L3/L4-защита.
• Контролируются bps, pps и RPS.
• Настроены SYN cookies или SYN proxy.
• Защищён conntrack.
• Используется поведенческая bot detection.
• Лимиты применяются не только по IP.
• Контролируются residential ASN и fingerprints.
• Дорогие endpoint имеют отдельные квоты.
• IPv4- и IPv6-политики согласованы.
• Публичный сайт работает через TrafficVeil.
• Origin закрыт по IPv4 и IPv6.
• Регламент реагирования протестирован.

Чек-лист защиты IoT-инфраструктуры

• Все устройства инвентаризированы.
• Стандартные пароли заменены.
• Для каждого устройства используются уникальные данные.
• Удалённое управление закрыто от интернета.
• Прошивки обновлены.
• Неиспользуемые сервисы отключены.
• UPnP и Telnet отключены, если они не нужны.
• IoT вынесены в отдельные VLAN.
• Исходящий трафик ограничен.
• Включён DNS- и сетевой мониторинг.
• Есть алерты на высокий исходящий pps.
• Контролируется срок поддержки устройств.
• Неподдерживаемые модели заменяются.
• Проверяется возможность безопасного обновления.
• Подготовлен регламент изоляции заражённого устройства.