Как один исследователь удалил 300+ вредоносных Tor exit-узлов

Представьте: вы подключаетесь через Tor к своему серверу по SSH. Соединение выглядит нормально. Но на самом деле кто-то в этот момент читает каждую введённую вами команду, перехватывает пароль и тихо устанавливает на ваш сервер бэкдор. Именно это происходило 2 октября 2026 года — и именно это остановил один независимый исследователь.

Эта история — не про сложную zero-day уязвимость и не про государственные спецслужбы. Это история о внимательности, правильном инструменте и быстрой координации с командой Tor Project. Разберём всё по шагам.

Что такое exit-узел и почему он опасен

Tor exit-узлы — это финальное звено в цепочке Tor-ретрансляторов: именно здесь зашифрованный трафик покидает сеть Tor и выходит в обычный интернет. Это делает exit-узлы одновременно критически важными и наиболее уязвимыми точками всей сети.

Любой желающий может запустить exit-узел — исследователи, активисты в защиту приватности и, к сожалению, злоумышленники. Именно этот факт создаёт системный риск.

ℹ Как работает Tor
Трафик в Tor проходит через три узла: входной (guard), промежуточный (middle) и выходной (exit). Только exit-узел видит, куда именно идёт трафик. При использовании HTTPS содержимое остаётся зашифрованным, но при незащищённых протоколах (HTTP, незашифрованный SSH и почта) exit-узел видит всё.

История знает прецеденты масштабных атак через exit-узлы. В 2020 году исследователь Nusenu обнаружил, что злоумышленник контролировал около 23% всех exit-узлов сети Tor — это был первый зафиксированный случай, когда один актор захватил столь значительную долю сети. Но атака октября 2026 года отличалась принципиально: она была хирургически точной, технически изощрённой и почти незаметной.

Анатомия атаки: операция Ebury на 10% сети

В пятницу, 2 октября, в 09:35, 333 заражённых exit-узла начали скоординированную кампанию по перехвату SSH-соединений и сбору как можно большего объёма незашифрованных данных.

Для понимания масштаба: во всей сети Tor насчитывается около 3000 exit-реле, то есть примерно 10% оказались под контролем атакующих.

Подготовка: два месяца в тени

Атакующие получили доступ к серверам ещё двумя месяцами ранее — в августе — и тихо развернули свою полезную нагрузку Ebury 1.8.3 (OpenSSH-бэкдор и похититель учётных данных для Linux).

Ebury — это OpenSSH-бэкдор и похититель учётных данных, нацеленный на Linux-системы. В этой кампании атакующие развернули версию Ebury 1.8.3, получив доступ к серверам Tor-реле за два месяца до начала активной фазы атаки.

Ebury существует с 2009 года. По данным исследователя Marc-Etienne M. Léveillé, приблизительно 400 000 серверов были заражены Ebury в период с 2009 по 2023 год — масштаб, говорящий сам за себя.

Два вектора: почта и SSH

Атака преследовала две основные цели: собрать как можно больше незашифрованного почтового трафика и перехватить SSH-соединения (MITM). Для этого злоумышленники блокировали определённые порты, вынуждая свои exit-узлы обрабатывать только незашифрованный почтовый трафик.

Механизм SSH-атаки был особенно коварен:

Если ваш трафик проходил через один из 333 заражённых exit-узлов, поначалу вы ничего не замечали. Зашифрованный веб-трафик перенаправлялся как обычно, но при попытке SSH-соединения через порт 22 вы незаметно перенаправлялись на один из 12 серверов-перехватчиков.

⚠ Красный флаг, который легко проигнорировать
SSH-соединение, проходящее через скомпрометированный exit-узел, перенаправлялось на сервер-перехватчик под контролем атакующего, вызывая предупреждение о несовпадении SSH-ключа хоста, поскольку fingerprint больше не совпадал с реальным сервером. Именно это предупреждение — единственный видимый признак атаки. Но многие пользователи привыкли его игнорировать.

Если пользователь игнорировал предупреждение и всё равно входил в систему, атакующий выполнял три действия:

  1. Крал пароль; 2. Открывал соединение с сервером жертвы и наблюдал за каждой введённой командой (MITM); 3. Открывал второе соединение и заражал сервер жертвы бэкдором Ebury.

sequenceDiagram
    participant User as Пользователь
    participant ExitNode as Заражённый Exit-узел
    participant Interceptor as Сервер-перехватчик (×12)
    participant Target as Сервер жертвы

    User->>ExitNode: SSH-соединение (порт 22)
    ExitNode->>Interceptor: Перенаправление трафика
    Interceptor-->>User: Фальшивый fingerprint (предупреждение!)
    User->>Interceptor: Игнорирует предупреждение, вводит пароль
    Interceptor->>Target: MITM-сессия (наблюдение за командами)
    Interceptor->>Target: Установка Ebury
    Note over Interceptor: Пароль украден, сервер заражён

Как исследователь их обнаружил: инструмент exitmap

Ключевым инструментом расследования стал exitmap — специализированный сканер для проверки поведения Tor exit-узлов.

Исследователь использовал exitmap, чтобы «пропинговать» каждый из примерно 3000 exit-реле и открыть SSH-соединения между двумя собственными серверами, проверяя полученный fingerprint и исходящий IP на каждом конце. Около дюжины реле отдавали поддельный fingerprint, а более 300 других перенаправляли трафик через те же 12 серверов-перехватчиков, не меняя fingerprint, — что и подтвердило факт заражения.

Логика детекции

Метод обнаружения строился на двух проверках:

Тип аномалииЧто происходитЧто это значит
Поддельный fingerprintExit-узел возвращает чужой SSH-ключЯвный MITM, грубая подмена
Перенаправление трафикаIP источника на стороне сервера ≠ IP exit-узлаТихое проксирование через сервер-перехватчик
Нормальное поведениеFingerprint совпадает, IP совпадаетУзел чист

Именно комбинация двух паттернов позволила выявить все 333 скомпрометированных узла: одни «сломались» грубо (поддельный ключ), другие работали тонко (прозрачное проксирование), но оба метода поймал один и тот же тест.

💡 Совет для операторов SSH-серверов
Никогда не игнорируйте предупреждение WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!. Это не ложная тревога — это красный флаг, требующий немедленной проверки. Используйте SSH-ключи вместо паролей: аутентификация на основе ключей не подвержена этой атаке.

Координация с Tor Project: от открытия до удаления за 72 часа

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

Хронология событий:

Пятница, 2 октября — начало перехвата.

Воскресенье, 4 октября — команда сетевого здоровья Tor сделала объявление операторам, которые начали отключать свои exit-узлы.

Воскресенье, 4 октября — реле были помечены как BadExit, и клиенты перестали использовать их для выходящего трафика.

Команда сетевого здоровья Tor пометила реле как BadExit начиная с 4 октября, и все заражённые серверы были отключены к 5 октября.

На metrics.torproject.org чётко виден провал на графике 4 октября, который так и не восстановился.

📝 Механизм BadExit
Помета BadExit — это флаг в консенсусе директорий Tor. Клиенты получают список всех реле вместе с их флагами и автоматически исключают узлы с флагом BadExit из возможных путей. Это позволяет оперативно нейтрализовать угрозу даже без физического отключения серверов.

Провайдеры под ударом: скомпрометированная инфраструктура

Важный вопрос: как атакующим удалось получить доступ к сотням серверов ещё в августе?

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

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

Это меняет модель угрозы: скомпрометирован может быть не сам оператор Tor-реле, а его хостинг-провайдер. Оператор при этом — жертва, а не соучастник.

Уроки и выводы: что это значит для каждого

История с 333 вредоносными exit-узлами — это поучительный кейс сразу в нескольких измерениях.

Для пользователей Tor

  • Никогда не игнорируйте предупреждения SSH о смене ключа хоста — даже при использовании Tor.
  • Используйте ключи, а не пароли для SSH: атака украла пароли, но не могла обойти key-based аутентификацию.
  • HTTPS везде: атака на почтовый трафик работала именно потому, что часть почтовых серверов до сих пор использует незашифрованные соединения.

Для операторов Tor-реле

  • Регулярно проверяйте свою инфраструктуру на признаки Ebury и аналогичных бэкдоров.
  • Выбирайте проверенных провайдеров: компрометация VPS на стороне провайдера стала растущей тенденцией в последние годы.
  • Рассмотрите переход на выделенное железо: некоторые эксперты полностью отказались от VPS для размещения всего, что связано с приватностью, в пользу выделенного оборудования.

Для сообщества безопасности

  • Инцидент показал, что скоординированная реакция работает: от обнаружения до нейтрализации прошло менее 72 часов.
  • Exitmap и аналогичные инструменты — недооценённая линия обороны. Один исследователь с правильным скриптом смог обнаружить 10% скомпрометированной сети.
  • Инцидент — ещё один аргумент в пользу того, чтобы больше людей запускали честные реле: community.torproject.org/relay/setup/.

Безопасность Tor — это общественное благо. Его сила зависит от количества честных участников. Каждый добросовестный exit-узел разбавляет влияние потенциально скомпрометированных.

💡 Как защититься прямо сейчас
  1. Проверьте свои SSH-серверы на признаки Ebury: rootkit использует характерные паттерны в памяти процесса sshd.
  2. Если вы Tor-оператор — сравните трафик своего реле с ожидаемым поведением.
  3. Подпишитесь на рассылку Tor network health: именно там первыми появляются подобные оповещения.

Итог

Один исследователь, инструмент exitmap, несколько часов работы и оперативная команда Tor Project — этого оказалось достаточно, чтобы нейтрализовать скоординированную атаку, затронувшую 10% всех exit-узлов крупнейшей анонимной сети мира.

Эта история напоминает: анонимность — не панацея, а инструмент. И как любой инструмент, он требует понимания его ограничений. SSH через Tor без key-based аутентификации, игнорирование предупреждений о смене ключей, незашифрованная почта — всё это превращает инструмент защиты в вектор атаки.

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