Шокирующий масштаб бразильского ботнета: 5 фактов, которые изменят ваш взгляд на сетевую безопасность

Вступление

В эпоху, когда каждый «умный» гаджет может стать точкой входа для злоумышленников, вопросы кибербезопасности выходят на первый план. Недавно в Reddit появился пост, в котором пользователь поделился поразительными данными о том, как два небольших бразильских провайдера превратились в «мозговой центр» почти полуторного миллиона запросов к его домашней сети. Этот случай ярко иллюстрирует, что даже небольшие провайдеры могут стать источником масштабных атак, если их инфраструктура скомпрометирована.

Суть проблемы проста: почти половина всех записей в таблице сессий сетевого шлюза приходилась на трафик из Бразилии, хотя реальный объём данных от этих запросов составлял лишь 0,025 % от общего трафика. В результате система тратит ресурсы на обработку «мусора», а администраторы теряют видимость реального трафика.

Японское хокку, отражающее ситуацию:

Тихий поток в ночи —
Сети скрытые шепчут,
Буря в тени.

Пересказ Reddit‑поста своими словами

Автор поста живёт в США, подключён к сети Cox Fiber с выделенным блоком /27. Он выгрузил данные о сетевых потоках (flows) за сутки с устройства UDM SE и обнаружил следующее (за 12 часов 18 февраля):

• Всего зафиксировано 286 826 потоков.
• 127 887 (44,6 %) приходились на входящие запросы из Бразилии, все они пытались открыть порт 443 (HTTPS).
• Было задействовано 5 306 уникальных IP‑адресов, но они принадлежали лишь двум небольшим провайдерам.
• Объём «атакующего» трафика – 17,2 МБ, в то время как легитимный трафик составил 68,1 ГБ.

Детали о провайдерах:

• 67 Telecom (AS61614) – небольшая фирма в Понта‑Пора, граница с Парагваем. Сканирование происходило из пяти /24‑подсетей, при этом в основной подсети 45.232.212.0/24 каждый IP‑адрес (от .0 до .255) отправлял запрос.
• JK Telecomunicações (AS262909) – провайдер в Диамантине, штат Минас‑Жерайс. Сканирование охватило всю подсеть 177.36.48.0/20 (4 096 адресов), каждый из 16 /24‑подсетей был полностью задействован.

Трафик имел «униформный» характер:

• 84,5 % потоков – 104 байта, 2 пакета (SYN‑скан, подтверждение открытого порта).
• 6,2 % – 52 байта, 1 пакет (один SYN, отклонённый файрволом).
• ≈4,7 % – до 936 байт, 18 пакетов (начало TLS‑рукопожатия, вероятно, для «фингерпринтинга»).
• Средний объём данных на поток – 135 байт, то есть почти никакой полезной передачи.

Временные пики совпадали с бразильскими рабочими часами, а в течение дня количество запросов варьировалось от 2 900 до 14 000 потоков в час (≈4 SYN/сек). Все IP‑адреса, проверенные через GreyNoise, отмечены как «noise: true», то есть они активно сканируют сеть по всему миру.

Автор связывает наблюдения с ботнетом Aisuru/Kimwolf, известным с конца 2024 года, который использует более 700 тыс. скомпрометированных IoT‑устройств и более 2 млн Android‑устройств. Ботнет применялся как для DDoS‑атак (до 31,4 Тбит/сек), так и для прокси‑инфраструктуры, обслуживая скрейпинг ИИ и подбор учётных данных.

Что отличает этот случай от большинства отчётов, так это полное покрытие целых подсетей, а не «разбросанные» IP‑адреса по тысячам автономных систем.

Дальнейшие действия автора:

• Подтвердил, что порт 443 действительно отвечает.
• Заблокировал весь входящий трафик из Бразилии на уровне файрвола.
• Отправил жалобы в 67 Telecom и в бразильский CERT.
• Проверил, как IDS/IPS реагирует на такие запросы.

Суть проблемы, хакерский подход и основные тенденции

Суть проблемы – это не просто «фоновой шум» от случайных сканеров, а целенаправленная, масштабная кампания, использующая полностью задействованные подсети небольших провайдеров. Хакеры применяют классический SYN‑скан для быстрой проверки открытости порта 443, а затем, в случае положительного ответа, могут перейти к более «тонким» методам – TLS‑фингерпринтинг, попытки установить соединение и использовать устройство как прокси.

Тенденции, которые можно выделить из данного кейса:

1. Комплексное компрометирование инфраструктуры провайдера – вместо того, чтобы заражать отдельные роутеры, злоумышленники, вероятно, получили доступ к оборудованию уровня CGNAT или к маршрутизаторам ядра сети.
2. Полное покрытие подсетей – сканирование всех IP‑адресов в /24 и /20 свидетельствует о автоматизированных скриптах, которые берут «список» подсетей и перебирают их последовательно.
3. Гео‑ориентированный тайминг – пики совпадают с рабочим временем в Бразилии, что указывает на использование «человеческого» расписания (например, сотрудники, работающие в ночную смену в США).
4. Переключение ролей устройств – IoT‑устройства, ранее использовавшиеся только для DDoS, теперь становятся «домашними прокси» для обхода гео‑блокировок и сбора данных.

Детальный разбор проблемы с разных сторон

Техническая сторона

• Нагрузка на таблицу сессий – почти половина записей в таблице сессий занята «мусорным» трафиком, что усложняет диагностику реальных проблем.
• Потенциальные уязвимости в оборудовании провайдера – если злоумышленники контролируют CGNAT‑устройства, они могут генерировать трафик от любого IP‑адреса в подсети, что делает блокировку по IP‑адресу бессмысленной.
• Недостаточная фильтрация на уровне ISP – небольшие провайдеры часто не имеют продвинутых систем DDoS‑защиты, что делает их «слабым звеном».

Экономическая сторона

Для провайдера компрометация инфраструктуры может привести к репутационным потерям и штрафам от регуляторов. Для конечного пользователя – рост расходов на обслуживание сети (большие логи, необходимость в более мощных устройствам).

Юридическая сторона

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

Практические примеры и кейсы

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

Сценарий 1: Домашний пользователь с небольшим роутером

Пользователь замечает, что его домашний роутер начинает «зависать» при попытке открыть веб‑страницу. После включения логирования он видит, что в течение часа генерируется более 10 000 SYN‑запросов к порту 443 из диапазона 45.232.212.0/24. Решение:

1. Включить rate‑limit на входящие SYN‑пакеты (например, 5 пакетов/сек).
2. Создать правило drop для всех входящих соединений из Бразилии.
3. Обновить прошивку роутера до последней версии, отключив UPnP.

Сценарий 2: Малый бизнес с выделенным блоком IP‑адресов

Компания использует несколько публичных IP‑адресов для веб‑серверов. В логах наблюдается рост количества соединений из 177.36.48.0/20. Действия:

1. Развернуть IDS/IPS (например, Suricata) с правилами, блокирующими SYN‑сканирование.
2. Внедрить GeoIP‑фильтрацию на уровне балансировщика нагрузки.
3. Подключить сервис DDoS‑защиты (Cloudflare, Akamai) для фильтрации трафика до попадания в сеть.

Экспертные мнения из комментариев

«Я провёл небольшое сканирование в Shodan и нашёл открытые сервисы Mikrotik. Не удивлюсь, если эти провайдеры используют оборудование Mikrotik, но не обновляют его. Патчи, исправляющие серьёзные уязвимости, вышли совсем недавно».

— Smith6612

«Блокировать весь трафик из Бразилии – самое простое и эффективное решение».

— Electronic_Air_9683

«Вместо блокировки пакетов лучше их просто сбрасывать (DROP), чтобы файрвол не тратил ресурсы на ответные SYN‑ACK».

— silentstorm2008

Возможные решения и рекомендации

• Гео‑блокировка – быстрый способ сократить нагрузку, но может затронуть легитимный трафик (например, CDN).
• Rate‑limiting SYN‑пакетов – ограничивает количество новых соединений от одного источника.
• Сегментация сети – отделить публичные сервисы от внутренних, используя отдельные VLAN и файрволы.
• Обновление прошивок у оборудования провайдеров (Mikrotik, Cisco, Juniper) – критически важно, если провайдер действительно использует уязвимое ПО.
• Внедрение IDS/IPS с правилами, обнаруживающими SYN‑сканирование и TLS‑фингерпринтинг.
• Сотрудничество с провайдерами – отправка отчётов в CERT и в ISP, запрос о проведении аудита их инфраструктуры.
• Лог‑агрегация и анализ – использовать ELK‑стек или Splunk для автоматического выявления аномалий.

Заключение и прогноз развития

Случай, описанный в Reddit, демонстрирует, что даже небольшие провайдеры могут стать «платформой» для масштабных сканирующих кампаний, если их оборудование скомпрометировано. Тенденция роста количества IoT‑устройств, их плохая защита и использование в ботнетах будет только усиливаться. Ожидается, что к 2027 году появятся новые «гибридные» ботнеты, сочетающие DDoS‑мощность и возможности прокси‑серверов, а также более изощрённые методы обхода гео‑блокировок.

Для защиты от подобных угроз необходимо сочетать технические меры (фильтрация, rate‑limiting, IDS/IPS) с процессуальными (сообщения в CERT, сотрудничество с провайдерами) и постоянным мониторингом. Чем быстрее вы обнаружите аномалию, тем меньше ресурсов будет потрачено на её обработку.

Практический пример (Python) – автоматический монитор и блокировка подозрительных IP

import requests
import json
import time

# Параметры
GREYNOISE_API = "https://api.greynoise.io/v3/community/"
API_KEY = "YOUR_GREYNOISE_API_KEY"   # замените на ваш ключ
BLOCKED_COUNTRY = "BR"               # код страны для блокировки
CHECK_INTERVAL = 300                # проверять каждые 5 минут

def is_noise_ip(ip):
    """
    Проверяет, помечен ли IP как «noise» в GreyNoise.
    Возвращает True, если IP участвует в сканировании.
    """
    headers = {"key": API_KEY}
    try:
        resp = requests.get(GREYNOISE_API + ip, headers=headers, timeout=5)
        if resp.status_code == 200:
            data = resp.json()
            return data.get("noise", False)
    except requests.RequestException:
        pass
    return False

def block_ip(ip):
    """
    Добавляет правило в iptables для блокировки IP.
    Требует прав root.
    """
    import subprocess
    cmd = ["iptables", "-A", "INPUT", "-s", ip, "-j", "DROP"]
    subprocess.run(cmd, check=False)

def monitor_and_block():
    """
    Основной цикл: читает список IP из лог‑файла,
    проверяет их в GreyNoise и блокирует при необходимости.
    """
    while True:
        # Читаем последние 1000 строк из файла flow.log
        with open("/var/log/flow.log", "r") as f:
            lines = f.readlines()[-1000:]

        # Выделяем уникальные IP‑адреса-источники
        ips = {line.split()[2] for line in lines}  # предположим, что 3‑й столбец – source IP

        for ip in ips:
            if is_noise_ip(ip):
                print(f"Блокируем подозрительный IP: {ip}")
                block_ip(ip)

        # Ждём перед следующей проверкой
        time.sleep(CHECK_INTERVAL)

if __name__ == "__main__":
    monitor_and_block()

Скрипт периодически (каждые 5 минут) читает последние записи из файла flow.log, выделяет уникальные IP‑адреса‑источники, проверяет их через API GreyNoise и, если IP помечен как «noise», добавляет правило в iptables для блокировки. Это простой, но эффективный способ автоматизировать реакцию на массовые сканирующие атаки.