Утечки DNS и сетевых отпечатков в ZennoPoster: как обнаружить и устранить

В ZennoPoster DNS может раскрыть подсеть клиента через ECS, а HTTP-клиент — выдать собственный сетевой отпечаток. Разбираем реальные тесты и показываем, как настроить BlankTrail.

Привет! Сегодня мы на реальных примерах разберём сетевые утечки в Zennoposter, где zennoposter выдаёт его сетевой отпечаток, а где и вовсе утекает ваш ip адрес мимо прокси и как это устранить.

Ниже разберём конкретные наблюдения на скриншотах, объясним их причины и покажем, как самостоятельно сравнить работу с BlankTrail Proxy и без него.

1. Браузер Zenno и HTTP-клиент - разные сетевые клиенты

Встроенный Chromium в ZennoPoster сам формирует корректный сетевой отпечаток своей версии. Когда профиль соответствует этому движку и его точной версии, то менять отпечаток только ради подмены не требуется.

Проблема возникает при рассогласовании: например, профиль заявляет Safari на iPhone, а соединение сохраняет признаки исходного Chromium. Сайт может сравнить User-Agent и Client Hints с параметрами TLS и HTTP/2 и увидеть, что они относятся к разным клиентам.

У HTTP-клиентов ситуация другая. Возможность отправить заголовок Chrome не превращает HTTP-библиотеку в Chrome: рукопожатие TLS, настройки HTTP/2 и особенности протокольного обмена формирует сам клиент.

Как выглядит контрольный запрос реального браузера

На снимке ниже обычный Chrome 154 обращается к нашему JSON-тесту audit.blanktrail.com/client. Ответ содержит client: "Chrome 154", client_kind: "browser", matches_browser: "Chrome 154", contradicts_declared: false и пустой массив findings.

Реальный Chrome 154: сетевой клиент соответствует заявленному браузеру, findings пуст.
Рис. 1. Контрольный пример реального Chrome 154. В копии для публикации скрыт только IP-адрес; поля результата сохранены.

Что показывают HTTP-клиенты ZennoPoster

В показанных запусках тест различает следующие варианты:

Как отправлен запрос Что вернул тест Что это означает
Альтернативный HTTP-клиент ZennoPoster client: "ZennoPoster", client_variant: "plain_client", client_kind: "client" Соединение распознано как HTTP-клиент ZennoPoster
TLS-клиент ZennoPoster client: "ZennoPoster", client_kind: "client" В этой конфигурации признаки реализации всё ещё позволяют распознать клиент
Альтернативный клиент через BlankTrail client: "Chrome 152", client_kind: "browser", matches_browser: "Chrome 152" На стороне теста соединение соответствует выбранному сетевому профилю Chrome
Альтернативный HTTP-клиент ZennoPoster: тест определяет ZennoPoster и вариант plain_client.
Рис. 2. Режим «Альтернативный»: изменение заголовков само по себе не скрывает сетевую реализацию клиента.
TLS-клиент ZennoPoster: тест по-прежнему возвращает client ZennoPoster.
Рис. 3. Режим «Tls клиент»: в показанном результате клиент распознаётся как ZennoPoster.
Альтернативный HTTP-клиент через BlankTrail: тест определяет Chrome 152 и browser.
Рис. 4. Тот же тип HTTP-клиента в сценарии с BlankTrail. На снимке сохранён режим «Альтернативный», а сетевой профиль определён как Chrome 152. Контрольный браузер выше имеет другую версию — 154; Дело в том что zennoposter проверяемой версии заявлял в UA версию 152 и профиль подстроился под его отпечаток. При этом можно выбрать любую версию, или другой браузер, в том числе мобильный, и отпечаток будет в точности соответствовать ему.

Это распознавание клиента по сетевому отпечатку, а не утечка вашего IP. Случай с утечкой рассмотрим ниже.

Что меняет BlankTrail

Схема подключения: Zenno, локальный порт BlankTrail, прокси или VPN, сайт.
Браузер и HTTP-клиент подключаются к локальному порту BlankTrail; выход и сетевой профиль задаются в его настройках.

BlankTrail формирует соединение с сайтом по выбранному профилю. В базе — отпечатки реальных Chrome, Firefox, Edge и Safari разных версий, устройств и операционных систем. Собственный механизм эмуляции воспроизводит параметры TLS и HTTP/2; User-Agent и Client Hints можно согласовать с этим профилем.

Мы сравниваем соединения глубже значений JA3/JA4: совпадение короткого идентификатора ещё не означает совпадения всего протокольного поведения. В наших сравнительных проверках популярные библиотеки, в том числе uTLS, curl_cffi и TLS-Cloak, сохраняли отличия от эталонных браузеров. Конкретную используемую версию клиента лучше проверять на стенде, а не судить о ней по названию библиотеки.

При этом сетевой профиль не заменяет JavaScript-окружение: если вы работаете настоящим браузером Zenno, его настройки должны соответствовать выбранной сетевой личности. Для API мобильных приложений BlankTrail также позволяет снять сетевой отпечаток приложения и использовать его при последующей эмуляции.

2. Реальные примеры DNS-утечек: прокси установлен, маршруты расходятся

DNS — это отдельный сетевой обмен. Браузер или его служебные механизмы могут разрешать имена самостоятельно, даже если основной запрос страницы идёт через прокси. Установка прокси и галочки эмуляции WebRTC сами по себе ещё не доказывают, что все DNS-запросы пошли тем же маршрутом.

Пример: домашняя подсеть раскрывается через ECS

На следующем снимке в ZennoPoster установлен SOCKS5-прокси, включены эмуляция геопозиции, часового пояса и WebRTC. Настройка DNS-over-HTTPS не включена. Стенд показывает ecs_foreign, mixed_ecs и mixed_egress.

ZennoPoster с SOCKS5-прокси: обнаружены ecs_foreign, mixed_ecs и mixed_egress.
Рис. 5. Стенд сообщает о подсети, не соответствующей измеренному выходу. На самом экране указано: «точный адрес не измерен». Кадр снят на этапе collecting observations.

Здесь важно правильно читать результат:

  • ecs_foreign — DNS передал подсеть, противоречащую адресу основного соединения. В этом примере стенд выводит реальную подсеть, не точный домашний IP, но уже весомая утечка, выдающая вас на каждом запросе и объединяющая все ваши сессии во всех инстансах, какие бы вы прокси при этом не использовали, и как бы не меняли браузерный профиль. И подсеть с маской /24 это всего 256 адресов, то есть это достаточно узко выдаёт вас.
  • mixed_ecs — в одной проверке замечены разные значения ECS. Разрешение имён не выглядит как один согласованный маршрут.
  • mixed_egress — серверные запросы одной проверки пришли с разных выходных адресов. Это повод проверить маршрутизацию и ротацию прокси; само по себе различие двух выходов ещё не доказывает, что один из них домашний.

ECS, или EDNS Client Subnet, передаёт информацию о сети клиента в DNS-запросе. Если запрос к резолверу ушёл через домашнее подключение, резолвер видит его реальный источник и может передать дальше префикс этого адреса. Веб-запрос приходит с IP прокси, а DNS указывает на другую сеть. Механизм и его последствия для приватности описаны в RFC 7871.

Пример: включение публичного DoH не гарантирует согласованный маршрут

На другом снимке в штатном действии Zenno указан DoH Cloudflare. В показанной части результата остаются mixed_egress, mixed_ecs и предупреждение h3_refused.

ZennoPoster с публичным DoH Cloudflare: сохраняются разные выходы и разные ECS.
Рис. 6. Публичный DoH включён, но в этом запуске стенд по-прежнему видит несогласованность маршрутов. Кадр также снят во время сбора наблюдений.

Этот пример не означает, что Cloudflare передал домашнюю подсеть: на данном кадре такого вывода нет. Он показывает другое — сам выбор публичного DoH ещё не подтверждает, что весь обмен привязан к нужному выходу. Шифрование DNS и выбор маршрута DNS решают разные задачи. При этом DoH сервера Google к примеру замечены в том что периодически выдают подсеть ECS, но не стабильно в каждом запросе. 

3. Как vDNS, собственный DoH и TUN закрывают разные части проблемы

vDNS: резолвер соответствует провайдеру и географии выхода

vDNS: более 4000 провайдеров и 10000 DNS-серверов; подбор по провайдеру и географии выхода.
vDNS подбирает резолвер под сеть и географию выхода, чтобы IP и DNS относились к согласованной сетевой среде.

Публичные резолверы используются обычными людьми и сами по себе не являются признаком автоматизации. Но  при сборе нашей собственной  базы DNS провайдеров, мы проверили что менее 20% реальных пользователей использую публичные DNS сервера Google или Cloudflare или другие. Подавляющее число абонентов оставляет настройки DNS своего провайдера. То есть для сайтов и их антифрода гораздо правильнее выглядит когда запрос резолва приходит от DNS серверов провайдера соответствующего ip.

В BlankTrail есть собственная база более 4 000 провайдеров и более 10 000 DNS-серверов. Это база резолверов интернет-провайдеров, в основной массе которой серверы, доступные только их абонентам, а не подборка общедоступных DNS.

BlankTrail определяет провайдера выхода, учитывает географию, подбирает подходящий доступный резолвер и обращается к нему через этот выход. Так сочетание IP, DNS и локации становится идентичным обычному абоненту. Это устраняет часть противоречий при строгих проверках.

Доступны и другие режимы:

  • Публичный DNS с ECS выхода — например, Google DNS с подсетью прокси вместо домашней сети, подойдёт для серверных прокси, где нет нативного DNS сервера провайдера.
  • Самостоятельный резолвинг через выход — BlankTrail сам проходит цепочку DNS, обращаясь к корневым серверам, серверам зон и авторитетным серверам доменов. Промежуточный публичный или провайдерский рекурсивный резолвер не используется; источником запросов служит IP выхода. Сам прокси при этом не превращается в отдельный DNS-сервис. Такой резолвинг даст идеальную точность географии по CDN и обойдёт возможные фильтры и ограничения на DNS провайдера или публичных DNS, то выглядит он менее естественно и соответствует только очень малой части пользователей который подняли свой DNS на роутере например.
  • Делегирование резолвинга прокси — разрешение имён средствами самого прокси.

Собственный DoH: DNS браузера через BlankTrail без TUN

vDNS может обработать только те вопросы, которые до него дошли. Поэтому в BlankTrail есть собственный сервер DNS-over-HTTPS на порту продукта: его адрес можно указать в настройках защищённого DNS браузера.

Браузер передаёт самостоятельные DNS-запросы в BlankTrail, а дальше они обрабатываются через выход и по DNS-политике выбранного порта. Входящий ECS клиента удаляется: дальнейшее использование подсети определяют настройки порта. Для разных браузерных профилей можно назначить DoH разных портов — со своими выходами и параметрами.

Так можно закрыть DNS-утечки браузерного резолвинга без TUN-перехвата. Нужен строгий режим DoH без автоматического возврата к системному DNS при ошибке. Различие между автоматическим и строгим поведением важно и для обычных браузеров — см. настройки Chrome и Firefox. 

Наш плагин для Zennoposter помогает применить прокси и DoH более удобно.

TUN: если приложение не умеет настраивать DNS или прокси

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

Любое приложение может отправить DNS через системную службу, обходя собственные настройки прокси. В Zenno сетевое поведение можно настраивать через C# и плагин. Для другого софта такой возможности может не быть.

В этом случае используется TUN-перехват на уровне системы. Он направляет трафик в выбранный порт BlankTrail и предусматривает обработку обычных DNS-запросов, в том числе исходящих от системных служб резолвинга.

Можно перехватывать всю систему или отдельные приложения, включая их дочерние процессы. Разные программы могут работать через разные порты: например, ZennoPoster — через один прокси и профиль, другая программа — через другой выход. В режиме отдельных приложений отдельно включается обработка системного DNS; для общего системного резолвера выбирается обслуживающий порт.

DoH подходит для DNS поддерживающего его браузера. TUN нужен для более широкого контроля сетевого трафика. Одна лишь настройка DoH не перенаправляет все соединения компьютера.

4. HTTP/3 и QUIC: почему зелёный DNS-тест ещё не закрывает вопрос протокола

Браузер Zenno передаёт HTTP/2 в BlankTrail, который подключается к сайту по HTTP/3 поверх QUIC.
HTTP/2 со стороны браузера и HTTP/3 со стороны сайта: для QUIC нужны поддержка HTTP/3 сайтом и UDP выбранным выходом.

Многие крупные сайты и CDN поддерживают HTTP/3 — HTTP поверх QUIC и UDP. При работе через обычный HTTP/SOCKS5-прокси браузер Zenno, как и стандартный Chrome, не использует такой прокси для HTTP/3 к сайту. В документации Chromium отдельно отмечено, что SOCKS5 используется для TCP-запросов, а не для передачи UDP. Документация Chromium.

Отсутствие HTTP/3 само по себе не раскрывает IP и не доказывает автоматизацию. UDP может быть недоступен и в обычной сети. Но это ещё одна характеристика соединения, которую сайт может сопоставить с остальным профилем.

Пример: DNS согласован, HTTP/3 пока не используется

На следующем снимке после подключения BlankTrail стенд отмечает резолвер провайдера, ECS только подсети выхода и согласованный User-Agent. Одновременно сохраняется h3_refused.

BlankTrail: DNS провайдера и согласованный профиль, но предупреждение h3_refused остаётся.
Рис. 7. В этом запуске DNS выглядит согласованно, а HTTP/3 не использован. Снимок сделан до завершения сбора наблюдений. По одному кадру нельзя определить, мешают ли возможности выхода, настройки или иной фактор.

Пример: завершённая проверка с HTTP/3

На другом выходе показана завершённая проверка. Стенд сообщает, что утечек IP не обнаружено, ECS относится только к подсети выхода, HTTP/3 работает и его движок согласуется с TLS, а User-Agent — с отпечатком соединения. Но т.к. это серверный прокси, то здесь нет отметки о DNS сервере провайдера, но запрос при этом пришёл с согласованным ECS  даже для серверного прокси.

Завершённая проверка через BlankTrail: утечек IP не обнаружено, HTTP/3 и TLS согласованы.
Рис. 8. Завершённый результат конкретного запуска через BlankTrail. Строки WebRTC описывают сведения, сообщённые браузером; серверные наблюдения STUN вынесены на стенде отдельно.

BlankTrail принимает запросы Zenno по HTTP/2 и может установить с сайтом HTTP/3-соединение поверх QUIC, учитывая сетевой профиль выбранного браузера и на этом уровне.

Для этого сайт должен поддерживать HTTP/3, а выбранный выход — передавать UDP, например через рабочий SOCKS5 UDP-relay. При недоступности UDP используется HTTP/2. BlankTrail не отправляет QUIC напрямую в обход настроенного прокси, чтобы получить зелёную отметку ценой другого выходного IP.

5. Независимые сессии требуют изоляции сетевого состояния

В наших проверках ZennoPoster встречается сценарий, когда новый браузерный инстанс сохраняет сетевую связь с предыдущей сессией при повторном использовании одной строки прокси. Даже если IP за этим адресом сменился, перезапуска инстанса может оказаться недостаточно. Напирмер вы используете прокси где выходной ip меняется по api запросу, вы работаете в одной сессии zennoposter, завершаете ещё, меняете ip выхода по api прокси сервиса и начинатете новую сессий. Cookie, кеш, ip браузерный профиль - всё сменилось, но вот на сетевом уровне утечка осталась и сайт видит это и склеивает все ваши сессии, аккаунты и т.п.

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

В BlankTrail состояние сетевых соединений изолировано по портам. Для независимых задач выделяются отдельные порты со своими профилями и маршрутами. Если же нужно продолжить именно прежнюю задачу, можно экспортировать и импортировать сессию порта вместе с профилем, отпечатком и TLS-сессией.

6. Smart Cache и маршруты: меньше повторных загрузок, больше контроля

Smart Cache: одна загрузка статики для нескольких потоков с фильтрацией меток сессии.
В общий кэш попадает подходящая статика; персонализированные ответы исключаются, а метки кэширования обрабатываются.

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

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

Для выхода можно использовать HTTP/SOCKS5-прокси, OpenVPN, WireGuard, VLESS (включая REALITY), Trojan, Shadowsocks, VMess и Hysteria 2. VPN и туннельные подключения доступны приложениям через обычный локальный прокси-порт BlankTrail.

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

7. Каптчи и браузерные проверки — в том числе на Linux без GPU

Challenge Breaker решает поддерживаемые каптчи на Linux с локальными моделями на CPU и программной графикой.
Для поддерживаемых проверок физическая видеокарта не обязательна: доступны вычисления на CPU и программная графика.

В BlankTrail так же есть Challenge Breaker: собственный браузерный компонент на базе качественно модифицированного Chromium, который выдаёт эталонный профильный отпечаток даже если запущен на linux без gpu и локальные механизмы решения поддерживаемых каптч.

Среди поддерживаемых сценариев — проверки Cloudflare/Turnstile, reCAPTCHA v2, AWS WAF, слайдеры Geetest, avito, ozon и текстовые каптчи Google. Решение выполняется на машине, где работает BlankTrail. Для задач, требующих распознавания изображений, используются локальные модели без отправки на внешние сервисы и дополнительных оплат.

В сценарии работы на запросах Challenge Breaker открывает нужную страницу, проходит поддерживаемую проверку и предоставляет рабочее состояние сессии для дальнейших обращений через BlankTrail. Выход и сетевой профиль должны оставаться согласованными: перенос полученного результата в произвольный клиент с другим IP не равнозначен продолжению той же сессии.

Есть и API по стандарту Anti-captcha (Antigate V2): RecaptchaV2Task, ImageToTextTask и AntiGateTask.  Вы можете использовать его вместо внешнего сервиса распознавания каптч, просто сменив в нужном софте адрес сервиса на адрес и порт указанный в настройке вашего локального BlankTrail Proxy. Используйте этот api например для получения токена reCAPTCHA v2 или v3, распознавание поддерживаемых текстовых каптч или получение сессии после браузерной проверки Cloudflare и подобных, если автоматическая обработка через Challenge Breaker для вашей задачи не подходит. 

Физическая видеокарта не обязательна. BlankTrail решает поддерживаемые каптчи и на Linux-сервере без GPU: распознавание может выполняться на CPU, браузерный компонент - использовать программную графику. Скорость и допустимое число параллельных задач зависят от процессора, памяти и сложности проверки.

8. Плагин ZennoPoster: подключение через привычный кубик

Плагин BlankTrail: открыть порт, дождаться опознания провайдера, применить прокси и DoH, запустить шаблон.
Действие «Открыть порт и применить» связывает настройки порта с браузером инстанса; независимые потоки могут использовать разные порты.

Чтобы не собирать обращения к API вручную, мы сделали плагин BlankTrail Proxy для ZennoPoster и ProjectMaker. На скриншотах с положительными результатами слева виден его интерфейс и действие «Открыть порт и применить».

Плагин открывает порт с выбранными настройками, ожидает опознания провайдера выхода и применяет прокси вместе с DoH к браузеру инстанса. В форме задаются ключ API, адрес BlankTrail, пресет, протокол, выход через прокси или VPN-шлюз и дополнительные параметры.

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

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

9. Как повторить проверки на своём шаблоне

Для сравнения зафиксируйте версии ZennoPoster и движка, тип HTTP-клиента, выбранный профиль, режим DNS и выход прокси. По возможности используйте стабильный выход: ротация во время проверки затрудняет интерпретацию mixed_egress.

Проверка DNS, ECS, HTTP/3 и связи сессий

  1. Откройте audit.blanktrail.com в новом браузерном инстансе с обычными настройками вашего проекта.
  2. Дождитесь завершения проверки. Надпись collecting observations означает, что результат ещё дополняется.
  3. Сохраните результат: измеренный выход, ECS, резолверы, серверные наблюдения и предупреждения. Отдельно смотрите ecs_foreign, mixed_ecs, mixed_egress и h3_refused.
  4. Подключите BlankTrail через плагин, примените DoH и повторите проверку в новом инстансе. При ручной настройке проверьте строгий режим DoH без возврата к системному DNS.
  5. Сравните маршруты и подсети. HTTP/3 оценивайте с учётом поддержки UDP выходом. Сведения WebRTC, сообщённые браузером, не подменяют серверные наблюдения.
  6. Для проверки связи сессий выполните несколько последовательных заходов из новых инстансов с одной строкой прокси и проверьте наличие соответствующей метки.

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

Проверка отпечатка HTTP-клиента ZennoPoster

  1. Выполните GET-запрос к audit.blanktrail.com/client реальным браузером: это контрольный пример. 
  2. Обратитесь к тому же JSON-адресу HTTP-клиентом ZennoPoster. По очереди проверьте используемые вами режимы, включая альтернативный и TLS-клиент. Сохраните ответы.
  3. Повторите HTTP-запрос через порт BlankTrail с нужным браузерным профилем. Согласуйте User-Agent и остальные настройки с выбранной версией.
  4. Сравните client, client_kind, matches_browser, contradicts_declared и findings, когда эти поля присутствуют в ответе.
  5. Проверяйте соответствие выбранному профилю. Если выбран Chrome 152, ожидаемый эталон - Chrome 152.

Ответ JSON проверяет сетевую сторону запроса. Для оценки JavaScript-окружения и поведения браузера нужны соответствующие браузерные проверки.

Начните с собственного проекта

Тариф Lite бесплатный и доступен всем. Для теста Тарифа Pro / Enterprise с vDNS и Challenge Breaker напишите в поддержу и вам будет предоставлен тестовый доступ на 1 день.

Начать работу с BlankTrail · Плагин ZennoPoster · Проверка DNS и сессий · Проверка HTTP-клиента