Зачем нужны прокси с UDP и при чём тут протечка WebRTC в Антике?

[Zl0y]

Зачем нужны прокси с UDP и при чём тут протечка WebRTC в Антике?
Автор: Zl0y
Дата: December 19, 2024

Как любая антифрод-система обнаружит подмену IP-адреса даже при работе через прокси + VPN (или просто прокси)? Зачем нам нужны прокси с поддержкой UDP? Почему «Антик» (антидетект-браузер) не поможет при проверке WebRTC, даже если все сервисы показывают, что у вас всё в порядке?

В этой статье мы разберёмся, как WebRTC может «выдавать» ваш настоящий IP-адрес, почему обычные прокси часто не решают эту проблему и как с этим бороться.

Proof​

Что такое WebRTC и как его использует Антифрод системы?
WebRTC — это протокол для передачи потоковых данных. Чаще всего его используют в JavaScript.

• Антифрод-системы применяют WebRTC для детекта различных характеристик вашей системы. Например, в WebRTC (особенно в Chrome) по умолчанию может использоваться UDP-протокол, который позволяет делать запрос напрямую от настоящего IP-адреса пользователя.
• Если вы используете прокси без поддержки UDP (а таких прокси большинство), WebRTC-запросы будут идти в обход прокси и «светить» ваш реальный IP. Даже если все остальные соединения идут через прокси, именно WebRTC-трафик может «пробить» NAT и показать истинный IP.
• Если вы подключены через VPN без прокси, WebRTC выдаст IP-адрес VPN. Но для антифрод-систем это тоже повод «накинуть» очков фрод-скор, поскольку они видят, что вы используете VPN-подключение вместо обычного провайдера.
• На рынке мало прокси-сервисов, предоставляющих полноценную поддержку UDP. Надеемся, что разработчики прокси-сервисов тоже прочитают эту статью и расширят функционал, но пока таких решений единицы.

Как именно WebRTC «сливает» ваш реальный IP?

Схема. Как браузер сливает реальный IP по UDP​

Когда мы заходим на сайт (например, antifraud.com), антифрод-система подгружает в браузер специальные JavaScript-скрипты. Обычно эти скрипты сильно зашифрованы (обфусцированы), так что прочитать их невооружённым глазом крайне затруднительно.

Шаги детекта:

1. Сайт делает запрос к своему внутреннему серверу по TCP (обычный запрос fetch).
2. Антифрод-система отвечает и «говорит» браузеру: «Сделай-ка ещё дополнительный запрос на мой STUN-сервер по такому-то порту». Так инициируется дополнительная проверка.
3. Браузеру ничего не остаётся, как выполнить этот запрос. И никакие антики не смогут этому помешать, поскольку невозможно выловить и заблокировать все адреса.
4. Браузер выполняет UDP-запрос — ведь к STUN-серверу нужно обращаться именно по UDP.
5. Антифрод легко сопоставляет ваш «обычный» TCP-запрос (через прокси) и UDP-запрос (напрямую) в рамках одной сессии.

• Если IP-адреса разные — значит, вы используете прокси или VPN.
• Таким образом можно определить ваш реальный IP (или хотя бы VPN-IP).

Пример: можете проверить работу этой схемы через наш тестовый сервис:
http://172.86.65.208:8080/
Алгоритм там реализован таким же образом, как описано выше.

Что делать?
Первое и самое важное: Прокси должен поддерживать работу по протоколу UDP.

Если поддержки UDP на уровне самой прокси нет, то ни Антик, ни Роутер, ни Гудвин (¬‿¬) не смогут «прикрутить» её за вас — она должна быть изначально.

Важно также понимать, что поддержка UDP может быть только в SOCKS5 (в HTTP / HTTPS / SOCKS4 её просто нет). Кроме того, далеко не все SOCKS5-прокси корректно работают с UDP. Проверить поддержку SOCKS5 на UDP можно через наш софт (ZloyRouter).

В нашей группе мы также тестировали многие прокси-сервисы на предмет поддержки UDP — но лишь единицы реально её обеспечивают.

А что с VPN?
На VPN (OVPN, PPTP, WireGuard) всегда реализована поддержка UDP «из коробки», поэтому наш тест будет показывать:

TCP IP = UDP IP, как и у обычного среднестатистического пользователя.

Это связано с тем, что VPN и прокси принципиально по-разному работают и по-разному подключаются:

• VPN туннелирует весь ваш трафик,
• Прокси (включая SOCKS5) работает на уровне приложения (в нашем случае — антидетект-браузера).

Подробнее о «уровнях» можно почитать в наших предыдущих материалах. Наш тест, как мы уже выяснили, может задействовать транспортный уровень (UDP), поэтому VPN обычно «проходит» проверку без проблем, а вот прокси — только если он поддерживает UDP и правильно подключён.

Проблемы с Chrome при работе через SOCKS5
Даже если ваш прокси грамотно поддерживает UDP, и вы запускаете браузер с хорошим SOCKS5, пройти наш тест всё равно не получится. Причина в том, что «наш любимый» Chrome (и любые антидетект-браузеры на базе Chromium) не поддерживает полноценную работу WebRTC-трафика (UDP, STUN и проч.) через SOCKS5-прокси.

Chrome и антидетект-браузеры на базе Chromium не пускают WebRTC-трафик (UDP, STUN и пр.) через SOCKS5. Это давняя «особенность» (или ограничение), связанная с тем, что WebRTC по умолчанию пытается напрямую «пробить» NAT, минуя любой прокси. В Firefox эти запросы попросту блокируются.

Вывод: все антидетект-браузеры на базе Хрома (а их большинство) подвержены этой проблеме.
Пишите в комментах, если интересно, почему так происходит

Как это обойти?

ZloyRouter​

Побороть проблему можно, правильно «раздав» SOCKS5. У нас это решается с помощью программы ZloyRouter. Вы просто вставляете в неё свой SOCKS5. Если SOCKS5 действительно поддерживает UDP, трафик WebRTC пойдёт как нужно — через прокси, и тест не заподозрит подвох.

[SOCKS5 (поддержка UDP)] --> [ZloyRouter] --> [Chrome/Антидетект]

1. Сразу видно, есть ли у вас проблема с UDP.
2. Если проблема была, вы автоматически её решаете.

--------------------------------------------------------------------------​

Если блокировать UDP — будет ОК?
Это, безусловно, лучше, чем «сливать» свой реальный IP-адрес. Если где-то в «дикой природе» встретится подобная WebRTC-проверка, есть шанс, что вы её пройдёте.

Однако у подавляющего большинства обычных пользователей WebRTC не заблокирован, и для них TCP IP = UDP IP. Если у вас WebRTC/UDP заблокирован, антифрод-система может заподозрить что-то неладное и начислить дополнительные «очки фрода».

--------------------------------------------------------------------------​

Почему во всех «антиках» не показывается утечка?
Вы можете проверить себя на browserleaks.com/webrtc или аналогичных сервисах и не увидеть утечки реального IP. Но эти сервисы известны антидетект-браузерам и их разработчикам:

• Они просто подменяют нужные данные и говорят: «Проблемы не существует».
• Тем самым усыпляют бдительность пользователя.
• На деле техника «пробития» IP через WebRTC-UDP известна с 2019 года, и любая антифрод-система может (и будет) её использовать.

Проблему можно решить, правильно пробросив прокси. Сделать это помогут наш продукт (ZloyRouter) и наша группа.

Кстати, если в Chrome не открывается наш сайт для теста, это значит, что провайдеры прокси просто заблокировали его, чтобы скрыть отсутствие у них поддержки UDP. Так поступили, например, Astraproxy и IPRoyal. Они заявляют «у нас есть UDP», но почему-то тестовый сайт недоступен. Делайте выводы сами.

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

--------------------------------------------------------------------------​

Итог
Пользуйтесь хорошим софтом, подписывайтесь на группу (https://t.me/Zl0yTeam) и не унывайте. Всем успехов! Победить это можно — нужно лишь правильно раздать ваш SOCKS5. У нас эта проблема решена с помощью программы ZloyRouter. Вы просто вставляете в него ваш SOCKS5 и, если он поддерживает UDP, трафик пойдёт как нужно через прокси, и тест ничего не заподозрит. Во-первых, вы хотя бы узнаете сразу, есть ли у вас эта проблема. Во-вторых, вы автоматически её решаете, если она есть.

 

[n0n3mi1y]

В случае с ZennoPoster - утечка на стороне прокси или зенки?
На вашем тесте виден в TCP реальный IP машины
На browserleaks.com/webrtc утечку не видно

В случае с Dolphin - просто блокируют, хотя в настройках стоит подмена.
Прокси точно с UDP (через зенку же видно...)

 

[n0n3mi1y]

Интересно, поможет ли это с утечкой в моем случае при реализации Монитор трафика?