Шифрование есть, анонимности нет: как DarkForums сдали IP через Censys

Представьте: вы поднимаете приватный XMPP-сервер для внутренних коммуникаций. Шифрование настроено, TLS включён, посторонние не могут читать переписку. Вы справедливо считаете что сервер защищён. Но один простой запрос в Censys — и любой желающий видит реальный IP-адрес вашего сервера, хостинг-провайдера, физическое расположение датацентра и список открытых портов. Без взлома, без эксплойтов, без специальных знаний — просто публичные DNS-данные, прочитанные в правильном порядке.

Именно это произошло с DarkForums — одним из крупнейших англоязычных хакерских сообществ даркнета. Форум предлагал участникам собственный XMPP-сервис под двумя доменами — darked.im и darkforums.im — как «приватный, зашифрованный, неотслеживаемый канал для тех кто не хочет чтобы их коммуникации отслеживались или цензурировались». 17 июня 2026 года аналитики компании Covert Security из Таллина опубликовали разбор: оба домена ведут на один и тот же публичный IP 172.234.115.5, сервер работает на Linode под Akamai Connected Cloud в Стокгольме, и обнаруживается стандартным Censys-запросом за несколько минут. Никакого Tor. Никакого hidden service. Никакой анонимизирующей прослойки — стандартный облачный сервер, проиндексированный как любой другой.

Это не уязвимость в XMPP и не ошибка в шифровании. Это операционный провал: люди, которые обещали анонимность, решили одну задачу (зашифровать содержимое) и полностью проигнорировали другую (скрыть инфраструктуру). Для сисадмина который поднимает любой приватный сервис — матрицу, VPN-шлюз, внутренний чат, корпоративный мессенджер — этот случай показывает ровно ту ошибку, которую легко совершить самому.

КАК ЭТО НАШЛИ

Методология Covert Security полностью прозрачна и воспроизводима. Шаг первый: запрос к Censys по доменам связанным с DarkForums-инфраструктурой. Censys — это поисковик по интернет-инфраструктуре, который непрерывно сканирует весь адресный IPv4-диапазон, собирает баннеры сервисов, TLS-сертификаты, DNS-записи и индексирует результаты. Шаг второй: просмотр forward DNS для найденного IP-адреса. Шаг третий: перекрёстная проверка всех доменов которые резолвятся в тот же адрес. Шаг четвёртый: анализ неожиданных или необъяснённых доменов в результатах.

Результаты говорили сами за себя. IP 172.234.115.5 принадлежит Linode/Akamai (AS172.234.96.0/19), геолокация — Стокгольм, Швеция (координаты 59.32938° N, 18.06871° E). На этом адресе открыты шесть сервисов: SSH на порту 22, HTTP на 80 и 443, и три XMPP-порта — 5222, 5223 и 5269. HTTP/443-ответ, последний раз зафиксированный 14 июня 2026 в 07:09 UTC, возвращает HTML-заголовок «Darked.IM | Free Secure XMPP for the DarkForums Community» — что окончательно идентифицирует сервер без какого-либо активного зондирования.

Дополнительно на том же IP обнаружился публичный XMPP-сервис xmpp.sg — сторонний сервис без видимой связи с DarkForums, чьи пользователи и не подозревали что делят инфраструктуру с одним из крупнейших хакерских форумов. Там же нашёлся поддомен jdrtyipau.er18.mobi — оставшийся с истёкшего домена er18.mobi, который сейчас продаётся на китайском регистраторе west.cn. DNS-запись поддомена никто не убрал, и она по-прежнему указывает на тот же сервер. Имя поддомена — автоматически сгенерированная строка, характерная для инструментов мониторинга или CDN-конфигурации. Что это значит — неизвестно, Covert Security намеренно не делает выводов из одной сиротской записи.

ПОЧЕМУ ШИФРОВАНИЯ НЕДОСТАТОЧНО

Это центральный урок этого инцидента, и его стоит проговорить явно: шифрование трафика и сокрытие инфраструктуры — две разные задачи, которые решаются разными средствами. XMPP с TLS защищает содержимое переписки. Он не скрывает факт существования сервера, его местонахождение, провайдера, список открытых портов и — самое важное — метаданные соединений.

Наблюдатель на сетевом уровне получает разную информацию в зависимости от позиции. Censys и Shodan видят сам сервер: открытые порты, TLS-сертификаты, баннеры сервисов. Хостинг-провайдер — Linode в данном случае — видит сетевой трафик на уровне потоков: какие IP-адреса подключались к серверу, когда, как часто, насколько долго держали соединение. Это и есть метаданные. Для мессенджера это метаданные, а метаданные в криминальных расследованиях часто ценнее содержания. Именно поэтому Signal уже много лет работает над минимизацией метаданных как отдельной инженерной задачей — не потому что их шифрование недостаточно, а потому что шифрование не скрывает сам факт коммуникации.

Linode и Akamai — американские компании. Сервер физически находится в Швеции. Это означает что к данным о соединениях потенциально можно получить доступ через правовую помощь с применением законодательства как США, так и ЕС. XMPP-шифрование здесь ничего не меняет: оно защищает содержимое, но не от запроса к хостинг-провайдеру о том какие IP-адреса подключались к серверу и когда.

ТИПИЧНЫЕ ОШИБКИ ПРИ ЗАПУСКЕ ПРИВАТНЫХ СЕРВИСОВ

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

Первая — и главная — ошибка: сервис слушает на публичном IP. Если сервис не предназначен для публичного доступа, он не должен быть виден из интернета вообще. Даже если на нём работает TLS и сложные пароли — сам факт открытого порта на публичном IP делает сервер обнаруживаемым через Censys, Shodan и аналогичные инструменты за минуты. Исправление: сервис слушает только на loopback (127.0.0.1) или внутреннем интерфейсе, доступ снаружи — только через VPN-туннель.

Вторая ошибка — размещение приватного сервиса на том же IP что и публичные сервисы. В случае DarkForums: xmpp.sg на том же адресе служит дополнительным идентификатором при OSINT-анализе. Увидев xmpp.sg, исследователь связывает два независимых сервиса через общую инфраструктуру. Исправление: приватные и публичные сервисы на разных серверах с разными IP — никакого пересечения на уровне адресации.

Третья ошибка — брошенные DNS-записи. Домен er18.mobi истёк, но поддомен jdrtyipau.er18.mobi продолжает указывать на тот же сервер. Это цифровой след который связывает текущую инфраструктуру с прошлой историей операторов. Перед отказом от домена или IP — проверить все записи которые на него указывают, включая поддомены через crt.sh.

Четвёртая ошибка — иллюзия выбора без реальной изоляции. Два домена darked.im и darkforums.im создавали у пользователей ощущение выбора, но оба вели на один IP. Представьте: пользователь зарегистрировался на darkforums.im — считая его «более приватным» или просто привычным. С точки зрения Censys он подключился к тому же 172.234.115.5 что и все остальные. Реальная изоляция — это отдельные серверы, отдельные хостинг-аккаунты, отдельные юрисдикции. Два домена на одном VPS — это просто два ярлыка на одной папке.

КАК ПРАВИЛЬНО ПРЯТАТЬ ИНФРАСТРУКТУРУ

Правильный подход зависит от того насколько серьёзно требование к сокрытию. Но базовые принципы одинаковы для любого «внутреннего» сервиса — корпоративного мессенджера, VPN-шлюза, административного интерфейса, мониторинга.

Самый надёжный способ — сервис не слушает на публичном интерфейсе вообще. Конфигурация для большинства сервисов сводится к тому чтобы указать конкретный внутренний адрес вместо 0.0.0.0. Проверить что именно слушает сервис и на каком интерфейсе:

ss -tlnp

Вывод покажет все TCP-порты в состоянии LISTEN. Колонка Local Address покажет на каком адресе слушает каждый сервис: 0.0.0.0:5222 — слушает на всех интерфейсах, виден из интернета. 127.0.0.1:5222 или 10.0.0.1:5222 — слушает только на loopback или внутреннем интерфейсе, не виден снаружи.

Если сервису нужен доступ снаружи, но только для определённых пользователей — правильное решение это nftables с ограничением по IP или VPN-туннель. Правило nftables которое разрешает XMPP-порт только с конкретного IP или подсети:

nft add rule inet filter input tcp dport 5222 ip saddr 10.0.0.0/24 accept
nft add rule inet filter input tcp dport 5222 drop

Первое правило разрешает подключения на порт 5222 только из подсети 10.0.0.0/24. Второе — сбрасывает все остальные. Порядок важен: nftables обрабатывает правила последовательно, первое совпадение побеждает.

Для случаев когда нужен публичный доступ без раскрытия реального IP — Cloudflare Tunnel. Он устанавливает исходящее соединение от вашего сервера к Cloudflare, после чего трафик идёт через инфраструктуру Cloudflare. Реальный IP сервера при этом не раскрывается клиентам — они подключаются к Cloudflare, а не к вашему серверу напрямую. Для HTTP-сервисов — через стандартный Tunnel. Для XMPP и других нестандартных TCP-протоколов — через Cloudflare Spectrum, но здесь важен нюанс: Spectrum доступен на планах Pro и Business, однако поддерживает только избранные протоколы (SSH, FTP, Minecraft). Произвольные TCP-порты включая XMPP (5222, 5223, 5269) требуют Enterprise-плана по данным официальной документации Cloudflare. Для большинства частных установок это нереалистично — WireGuard-туннель как описано ниже решает задачу проще и дешевле.

Если сервис предназначен для ограниченного круга пользователей — VPN-туннель это самый чистый вариант изоляции. Классическая схема: WireGuard или AmneziaWG поднимается на сервере, XMPP или другой приватный сервис настраивается слушать только на WireGuard-интерфейсе (обычно wg0, адрес вида 10.0.0.1). Снаружи видны только UDP-порт WireGuard и SSH — ничего больше. Пользователь сначала подключается к VPN, и только тогда получает доступ к приватным сервисам. Censys видит открытый UDP-порт WireGuard, но не видит ни XMPP-портов, ни любых других сервисов за ним — они существуют только в контексте VPN-сети.

WireGuard скрывает сервис от сканеров — но не стирает историю. Если сервер когда-то был привязан к домену, если DNS-записи остались висеть после смены IP, если истёкший домен не убран — цифровой след существует независимо от того насколько хорошо спрятан сам сервис. Именно поэтому DNS-гигиена — отдельная обязательная практика, которая дополняет сетевую изоляцию, а не заменяет её. Перед тем как отказаться от домена или IP: проверьте все DNS-записи которые на него указывают, включая поддомены. Для быстрой проверки конкретных записей которые вы знаете:

dig +short @8.8.8.8 example.com
dig +short @8.8.8.8 www.example.com
dig +short @8.8.8.8 mail.example.com

Но вручную это ненадёжно — вы не знаете о всех поддоменах которые когда-либо создавались. Лучше использовать Certificate Transparency логи: все когда-либо выданные TLS-сертификаты на ваш домен видны на crt.sh. Запрос для домена example.com: открыть https://crt.sh/?q=%.example.com и изучить список — он покажет все поддомены для которых когда-либо выпускался сертификат. Это даст полную картину того что существовало даже если DNS-записи уже убраны.

Проверить видимость вашего сервера через публичные сканеры — хорошая регулярная практика. Censys позволяет искать по IP-адресу, домену и TLS-сертификатам. Для своего сервера: зайти на https://search.censys.io/hosts/YOUR_IP и посмотреть что видно снаружи. По данным Covert Security, для такой проверки достаточно бесплатного тарифа Censys — никаких специальных полномочий или платной подписки не требуется. Это займёт минуту и покажет ровно то что видит любой внешний наблюдатель.

ХРОНОЛОГИЯ

14 июня 2026, 07:09 UTC — последний зафиксированный Censys HTTP-ответ от сервера 172.234.115.5 с HTML-заголовком «Darked.IM | Free Secure XMPP for the DarkForums Community». Это момент до публикации — сервер уже был проиндексирован, данные уже были в базе Censys. Covert Security нашли их позже, просматривая архивные данные.

17 июня 2026 — Covert Security публикует разбор «Dark Forums Jabber — IP Leak by Design». Вся методология открыта и воспроизводима: DNS-запросы + Censys, без активного зондирования сервиса. Подчёркнуто особо: весь процесс занял минуты, бесплатный тариф Censys достаточен для полного воспроизведения.

20 июня 2026 — история получает широкое освещение. На момент публикации DarkForums не выпустили публичных комментариев. Сервер по данным открытых источников продолжает работу — инфраструктура не изменилась.

ПОЧЕМУ ЭТО ВАЖНО

DarkForums — не первый случай деанонимизации через инфраструктурный анализ, и далеко не последний. Freedom Hosting — крупнейший хостинг даркнета — был идентифицирован ФБР через анализ сетевой инфраструктуры задолго до технического взлома. AlphaBay, крупнейший наркорынок даркнета на момент закрытия в 2017 году, был деанонимизирован в том числе через операционные ошибки: администратор Alexandre Cazes использовал один и тот же email ([email protected]) и для настройки маркетплейса, и в личных аккаунтах LinkedIn и PayPal. Шёлковый путь пал по схожей причине — Ross Ulbricht искал технических специалистов на публичных форумах под своим настоящим именем. Паттерн один и тот же: криптография работала безупречно, содержимое было защищено, но операционные ошибки в инфраструктуре и поведении выдали всё остальное.

Та же ошибка встречается у корпоративных команд которые поднимают «внутренние» инструменты на облачных серверах с публичными IP. Матрица для внутренних коммуникаций, Gitea для приватных репозиториев, Grafana для мониторинга, панель администрирования — всё это часто запускается на 0.0.0.0 с предположением что «снаружи никто не знает адреса». Censys знает. Shodan знает. FOFA знает. Все эти инструменты индексируют весь IPv4-диапазон непрерывно — ваш «внутренний» сервис попадает в их базу в течение нескольких часов после запуска.

Для тех кто планирует приватный сервис — VPN, Matrix, XMPP, административный интерфейс — этот случай даёт конкретный чеклист: не публичный IP для сервисов которые не должны быть публичными; не один IP для публичной и приватной инфраструктуры; не забытые DNS-записи; не иллюзия выбора домена без реальной изоляции. Шифрование трафика — это одна задача. Сокрытие самого факта существования сервиса — это другая. История показывает: решать нужно обе.

ВЫВОДЫ

Случай DarkForums хорош тем что он полностью воспроизводим и поучителен без каких-либо уязвимостей. Ничего не взломали. Никакого CVE. Просто DNS + Censys + пять минут времени — и полная инфраструктурная картина у любого кто захочет её составить.

Аналитики Covert Security нашли DarkForums за время кофе-брейка — их слова, не преувеличение. Столько же займёт проверка вашего сервера. Выполните ss -tlnp и посмотрите на каких адресах слушают ваши сервисы. Зайдите на https://search.censys.io/hosts/YOUR_IP — посмотрите что видит Censys прямо сейчас. Проверьте crt.sh на поддомены которые вы, возможно, забыли. Если результаты вас не удивят — отлично. Если удивят — лучше узнать об этом самому, чем ждать пока кто-то другой напишет про вас разбор.