Уязвимости WebRTC: почему отключение функции — плохой способ бороться с утечками

В мультиаккаунтинге мало что пугает так, как внезапная утечка реального IP-адреса. Как бы она ни случилась, на кону профили, аккаунты и деньги.

Когда связку аккаунтов неожиданно блокируют, о настройках собственного софта вспоминают в последнюю очередь. Сначала достаётся поставщикам прокси, разработчикам антидетект-браузера и сотрудникам. Эмоции понятны, но давайте заступимся за посредников и разберём самую частую техническую причину утечки реального IP — WebRTC.

Суть проблемы проще всего объяснить на примере. Вы пишете письмо с рабочего адреса компании, но в подписи по ошибке остался ваш личный номер телефона. Отправитель вроде бы корпоративный, а внимательный получатель всё равно видит, кто вы. С WebRTC происходит то же самое: запросы идут через прокси, а система защиты платформы всё равно узнаёт ваш настоящий IP-адрес.

Для того, кто ведёт несколько профилей, это особенно опасно: антифрод-системы могут связать разные сессии по общему цифровому следу и ограничить все профили сразу.

Как устроен WebRTC

WebRTC (Web Real-Time Communication) — стандарт, встроенный в движок браузера. С его помощью браузер обменивается данными с другим устройством напрямую, по схеме P2P, без обязательного промежуточного сервера. На WebRTC держатся голосовые каналы Discord, видеозвонки в Google Meet, веб-версии мессенджеров, демонстрация экрана и передача файлов прямо во вкладке. Пользователю ничего не нужно ставить: всё работает из коробки.

Сравним два способа передачи данных:

• Обычный веб-серфинг через посредника. Браузер обращается к сайту по HTTP или HTTPS поверх TCP. Если прокси настроен правильно, весь этот трафик идёт через арендованный сервер.
• Пиринговый сеанс WebRTC. Для живого звука и видео лишние узлы на пути вредны: каждая задержка пакетов превращается в фризы, лаги и рассинхрон. Поэтому браузер ищет самый короткий прямой маршрут до собеседника и использует протокол UDP.

Быстрое решение, которое вредит

Раньше проблемы с WebRTC решали самым прямолинейным способом — отключали функцию целиком. Логика простая: нет работающего протокола — нет и утечки. Для этого меняли скрытые флаги браузера или ставили расширения-заглушки.

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

У обычных пользователей WebRTC включён почти всегда, больше чем в 99% случаев. Браузер задействует его не только для звонков, но и для фоновых сетевых проверок. Профиль с полностью выключенным WebRTC выделяется на общем фоне: так бывает, но выглядит подозрительно.

Отключение сводится к удалению или принудительной блокировке интерфейса RTCPeerConnection. Обычный человек не заходит в chrome://flags, чтобы ради приватности выключить базовые мультимедийные модули, и большинство даже не знает о таких настройках. Поэтому для антифрода это нетипичное поведение.

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

Как STUN и ICE обходят прокси

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

Как работает STUN-запрос

Чтобы найти короткий путь до другого участника, браузер отправляет служебный UDP-пакет на публичный STUN-сервер (Session Traversal Utilities for NAT). Сервер смотрит на заголовок пакета, видит внешний IP-адрес и порт отправителя и возвращает их браузеру в виде ICE-кандидата (Interactive Connectivity Establishment).

В описании сессии (SDP — Session Description Protocol) такие маршруты помечаются атрибутами:

• host — внутренний адрес сетевой карты в локальной сети;
• srflx (Server Reflexive) — внешний адрес, который увидел удалённый STUN-сервер.

Слежки за пользователем в этом механизме нет: это обычный способ пройти через NAT.

Почему обычный прокси здесь не помогает

Большинство серверных и мобильных прокси работают поверх TCP. Они передают HTTP- и HTTPS-запросы, но не пропускают UDP-датаграммы.

Когда браузер поднимает WebRTC-сессию, он формирует именно UDP-пакет для STUN-сервера. TCP-прокси не может провести его через свой канал, поэтому операционная система отправляет пакет обычным маршрутом — через шлюз вашего провайдера, мимо прокси. STUN-сервер видит домашний IP и возвращает его в кандидате srflx.

Передать UDP через посредника можно только через SOCKS5-прокси с поддержкой команды UDP ASSOCIATE. Ротируемые резидентские прокси Node Proxy поддерживают UDP: для этого достаточно включить переключатель в личном кабинете при настройке. В остальных случаях, а это большинство рабочих задач с обычными TCP-прокси, нужна подмена сетевых ответов на уровне ядра браузера.

Другие каналы утечки сетевых данных

Кроме внешнего адреса, WebRTC может выдать ещё два типа данных.

Внутренняя структура сети

У каждого устройства, кроме внешнего, есть локальный IP-адрес, который выдал роутер или сетевой адаптер. Он тоже может утечь.

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

В браузерах есть защита: внутренний адрес подменяется случайным mDNS-именем с окончанием .local, которое ничего не говорит внешнему сайту. Но она перестаёт работать, когда сайт запрашивает доступ к камере или микрофону (вызов getUserMedia). Как только пользователь разрешает доступ в системном окне, сайт считается доверенным и видит настоящий внутренний IP вместо заглушки.

Утечка через IPv6

Интернет сейчас работает сразу на двух поколениях протокола:

• IPv4 — привычный формат адресов;
• IPv6 — новый, более широкий пул адресов.

Многие домашние провайдеры и мобильные операторы выдают устройству оба адреса. А большинство коммерческих прокси работают только с IPv4. Подробнее о разнице — в статье IPv4 или IPv6.

Получается перекос:

• IPv4-прокси обслуживает только свой поток трафика;
• канал IPv6 на сетевом адаптере никто не контролирует;
• WebRTC опрашивает все сетевые интерфейсы: по IPv4 он видит адрес прокси, а по IPv6 выходит в сеть напрямую через провайдера и добавляет ваш домашний IPv6 в список кандидатов.

По каким признакам антифрод видит плагины и блокировщики

Вот признаки, по которым защитные системы замечают вмешательство в окружение:

• API удалён целиком. Если отключить протокол флагом (например, media.peerconnection.enabled = false), обращение к RTCPeerConnection падает или возвращает undefined. Для антифрода это признак нестандартной среды.
• Методы подменены через JavaScript. Блокировщики заменяют родные методы своими функциями. Проверочный скрипт вызывает Function.prototype.toString.call(window.RTCPeerConnection): родной объект возвращает строку вида function RTCPeerConnection() { [native code] }, а код расширения выдаёт изменённый профиль.
• Забытые воркеры. Многие расширения меняют окружение только в основном окне (window) и не трогают отдельные контексты Web Workers и Service Workers. Внутри воркера RTCPeerConnection продолжает работать как обычно и отдаёт ваш настоящий IP.

Сравнение способов защиты:

Как проверить сетевые параметры профиля

Надёжность профиля можно проверить доступными инструментами:

• Сетевой тест. Откройте профиль и зайдите на чекер вроде BrowserLeaks или Pixelscan. В разделе WebRTC проверьте, что:
  • показанный IP совпадает с адресом прокси;
  • в списке кандидатов нет домашнего IPv6 и адресов локальной сети;
  • атрибут srflx и порт соответствуют сетевой среде прокси.
• Целостность API и воркеров. Прогоните профиль через CreepJS: в отчёте не должно быть признаков подмены прототипов, методы должны возвращать нативный код, а проверки в воркерах — проходить без ошибок и задержек.
• Проверка через консоль. Откройте DevTools внутри профиля и выполните скрипт:

// 1. Родной ли конструктор и ключевой метод
console.log('Конструктор:', Function.prototype.toString.call(window.RTCPeerConnection));
console.log('createOffer:', Function.prototype.toString.call(RTCPeerConnection.prototype.createOffer));

// 2. Собираем ICE-кандидатов через публичный STUN
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('leak_test');
pc.onicecandidate = (e) => { if (e.candidate) console.log('Кандидат:', e.candidate.candidate); };
pc.onicegatheringstatechange = () => console.log('Сбор маршрутов:', pc.iceGatheringState);
pc.createOffer().then((offer) => pc.setLocalDescription(offer));

В правильно настроенной среде вывод выглядит примерно так (адреса условные):

Сбор маршрутов: gathering
Кандидат: candidate:1982170229 1 udp 2113937151 20ad41a3-a899-4802-9f77-6dfc171a9518.local 59452 typ host generation 0
Кандидат: candidate:2202552712 1 udp 1677729535 203.0.113.90 7172 typ srflx raddr 0.0.0.0 rport 0 generation 0
Сбор маршрутов: complete

Локальные адреса скрыты за именами .local, а в кандидате srflx стоит адрес прокси. Посторонние строки в стеке вызовов, ошибки или признаки JavaScript-обёртки Proxy выдают вмешательство в окружение.

Итог

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

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

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