• Вступление
• Архитектура: как это выглядит в реальности
• Многоуровневость: как система экономит ресурсы и позволяет обходить антифрод с минимальными усилиями
• Почему IP больше не идентификатор
• Browser-first: где сегодня основной детект
• Глубокая проверка устройства (как реально ловят антидетекты)
• Automation detection: где палятся даже хорошие антидетекты
• TLS fingerprint: слой, который ломает многие схемы
• Сетевой уровень: что реально анализируется
• Где ломаются прокси (реальная причина)
• Разбор популярных антифрод-систем
• Типичные ошибки, на которых палятся даже хорошие антидетекты
• Почему большинство “чекеров” ошибаются, и как должна работать глубокая проверка среды
• В чем слабость базовых чекеров
• Как должен работать современный чекер
• Что отличает наш чекер
• Как увидеть внутреннюю логику антифрода через скрипты
• Финальный вывод

Вступление

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

Главная цель - не просто детект, а управление риском с минимальным влиянием на UX. Поэтому антифрод - это всегда компромисс: чем больше проверок, тем выше точность, но тем хуже пользовательский опыт.

Ключевая идея всей системы:

Архитектура: как это выглядит в реальности

Любая серьёзная система строится как распределённый pipeline:

• Edge (CDN / WAF)
• Backend (risk engine)
• Client (JS sensor)

На уровне браузера происходит сбор сырых данных: canvas, WebGL, audio, navigator, Intl, performance timing. На уровне сети фиксируются IP, ASN, TLS fingerprint, HTTP поведение. На backend происходит нормализация, агрегация и скоринг.

Важно, что антифрод - это не просто «if (bad) → ban». Это система весов, уверенности и корреляций. Один сигнал редко что-то значит. Значение появляется только в совокупности.

Многоуровневость: как система экономит ресурсы и позволяет обходить антифрод с минимальными усилиями

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

На первом этапе выполняются самые дешёвые и быстрые проверки: валидность payload, базовая консистентность браузера и общий IP/ASN контекст. Эти проверки практически ничего не стоят и позволяют быстро отсеять очевидный мусор.

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

Если же появляются сомнения, антифрод начинает углубляться - подключаются проверки WebGL и Canvas, анализируется TLS fingerprint, ищутся признаки automation. Эти проверки уже значительно дороже и включаются только при наличии подозрений.

И только если риск остаётся неочевидным, система включает самый дорогой уровень - поведенческий анализ и корреляцию (device ↔ IP ↔ аккаунты). Это требует времени, данных и вычислений, поэтому применяется ограниченно.

Из этого вытекает важный практический вывод:
антифрод не видит «всё сразу» - он видит ровно столько, сколько его заставили увидеть.

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

Таким образом, многоуровневость - это одновременно и способ масштабирования системы, и её ограничение.

Почему IP больше не идентификатор

Раньше антифрод строился вокруг IP - он использовался как основной идентификатор пользователя. Сегодня эта модель перестала работать.

Главная причина - изменение самой сетевой инфраструктуры. В условиях CGNAT один публичный IP может одновременно использоваться тысячами пользователей. В мобильных сетях ситуация ещё более выражена: IP динамически переиспользуются, а в крупных городах один адрес может обслуживать десятки тысяч абонентов. При этом один и тот же пользователь может сменить несколько IP за короткую сессию.

В результате IP потерял свою уникальность и больше не может выступать в роли надёжного идентификатора. Он остаётся важным сигналом, но используется как часть контекста, а не как источник истины.

Современная идентичность пользователя строится на комбинации сигналов:

device fingerprint + network context + behavior

Именно их согласованность, а не сам IP, определяет уровень доверия к пользователю.

Browser-first: где сегодня основной детект

Антифрод начинает с браузера, потому что:

• IP легко менять (VPN, прокси, ротация, NAT/CGNAT).
• Браузерный профиль сложно подделать целиком: можно изменить отдельные поля, но трудно сохранить согласованность всех слоев одновременно.

Система проверяет:

• совпадает ли UA с platform и заявленной ОС;
• совпадает ли platform с реальными браузерными API и supported features;
• соответствует ли GPU-идентичность фактическим WebGL/WebGPU возможностям;
• соответствует ли CPU execution timing заявленному классу устройства;
• совпадают ли intl, locale, timezone, language и сетевой контекст;
• есть ли следы автоматизации (CDP/WebDriver/headless/stack artifacts);
• нет ли внутренних противоречий между несколькими “независимыми” источниками одного и того же сигнала.

Принцип простой:

браузер может соврать в метаданных, но плохо врет в физике исполнения.
Под “физикой” здесь понимаются результаты вычислений, тайминги, ограничения железа и поведение API под нагрузкой.
Именно поэтому в browser-first антифроде главный фокус - не на одном поле, а на кросс-валидации: “что браузер заявил” vs “что реально показали вычисления и capability-тесты”.

Если эти два слоя расходятся, это самый ценный сигнал риска.

Глубокая проверка устройства (как реально ловят антидетекты)

Антифрод не ограничивается чтением “паспортных” полей браузера.
Главный детект начинается там, где система делает активные проверки и смотрит не на заявление клиента, а на фактическое поведение среды.

Что обычно тестируют:

• WebGL/WebGPU: renderer, vendor, limits, extensions, feature flags, shader-capabilities, compute/rt профили;
• Canvas: стабильность и воспроизводимость рендера, хэши, различия между контекстами;
• Audio: floating-point особенности и дрейф в обработке (а не только “поддерживается/не поддерживается”);
• Intl/Locale: реальные результаты форматирования дат/чисел/языковых данных;
• Performance: execution timing, стабильность и профиль задержек в контрольных вычислениях;
• API coherence: согласованность между независимыми источниками (navigator, графический стек, capability probes).

Ключевая логика:

• если браузер заявляет одно, а вычислительные тесты показывают другое - это сильный риск-сигнал;
• если противоречий несколько и они независимы, уверенность в детекте резко растет.

Примеры конфликтов:

• браузер заявляет: GPU = Intel UHD 630,
  а GPU-профиль/лимиты/поведение ближе к дискретной AMD/NVIDIA карте или к другому поколению Intel GPU - конфликт;
• браузер заявляет: 8 CPU cores,
  а execution timing и scaling в контрольных задачах похожи на слабый пк/эмуляцию - конфликт.

Почему это работает:

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

Automation detection: где палятся даже хорошие антидетекты

Современные антифроды действительно проверяют “классический набор”:

• navigator.webdriver;
• признаки CDP и remote debugging;
• patched/native API consistency;
• stack traces и execution frames;
• следы automation-runtime в окружении страницы.

Но сильные системы на этом не останавливаются.
Главный детект смещается из “что браузер говорит” в “как среда исполняет код”.

Что анализируют глубже:

• event loop поведение: джиттер, характерные задержки, блокировки;
• microtask/macrotask timing: очередность и стабильность исполнения;
• async semantics: цепочки Promise, postMessage, requestAnimationFrame, таймеры;
• scheduler profile: как распределяется нагрузка в JS runtime;
• consistency under stress: как среда ведет себя при сериях активных probe-тестов.

Почему это важно:

• метаданные можно подправить;
• один-два API можно замокать;
• но сложно синхронно подделать весь тайминговый и планировочный профиль исполнения без побочных артефактов.

Типичный паттерн палева “хорошего” антидетекта:

1. пассивные проверки выглядят чисто;
2. активные timing-пробы дают нестабильный или “нечеловеческий” профиль;
3. при повторе теста распределение задержек не соответствует нативной среде.

Именно поэтому системы уровня Kasada считаются сложными:
они делают ставку не на отдельные флаги, а на поведенческую физику runtime - то есть на то, как код реально живет во времени, а не на косметику отпечатка.

TLS fingerprint: слой, который ломает многие схемы

TLS fingerprint - один из самых сильных сигналов сетевого уровня, потому что он отражает не “что заявлено”, а как клиент реально строит защищенное соединение.

Обычно анализируют:

• набор cipher suites;
• TLS extensions;
• порядок и структура параметров в ClientHello;
• версии протокола, ALPN, key share и связанные negotiation-детали.

Почему это важно:

если клиент заявляет себя как “обычный Chrome”, но TLS-поведение похоже на Go/OpenSSL/нестандартный HTTP-стек, это сильное противоречие.
В живом трафике такие несовпадения часто являются признаком скриптовой автоматизации, прокси-прослоек или кастомного транспорта.

Именно поэтому TLS-слой активно используется крупными edge-платформами и бот-защитой (включая Cloudflare/Akamai):
он хорошо отделяет нативный браузерный трафик от эмулированного, даже когда заголовки и JS-фингерпринт “причесаны”.

Практический момент, который многим знаком:

многие сталкивались с ситуацией, когда запрос “вроде правильный” (с теми же URL, headers, cookies) отправляется через обычный HTTP-клиент и все равно получает challenge/403 на сайтах под Cloudflare.
Причина часто как раз в том, что header-уровень похож на браузер, а TLS-отпечаток - нет.

Сетевой уровень: что реально анализируется

Система смотрит:

• ASN и провайдера
• тип сети (mobile / residential / DC)
• репутацию подсети
• скорость смены IP
• географию

Дополнительно:

• fake ISP проверки (см. статью: [ссылка])
• исторические данные

Важно: один IP ничего не значит, но его поведение во времени - значит.

Где ломаются прокси (реальная причина)

Современный антифрод ловит не прокси, а невозможные комбинации.

Типичный кейс:

• IP → residential
• TLS → не браузерный
• WebGL → отличается от заявленного GPU
• behavior → слишком идеальный

Каждый сигнал сам по себе допустим.
Но вместе - нет.

Именно это и есть детект.

Разбор популярных антифрод-систем

Современные антифрод-системы, несмотря на схожую архитектуру, сильно отличаются по тому, на каком уровне они принимают основные решения. Это напрямую влияет на то, какие атаки они ловят лучше всего.

Сетевые решения, такие как Cloudflare и Akamai, делают основной упор на инфраструктуру. Они анализируют TLS fingerprint, HTTP-поведение, ASN и репутацию IP. Такие системы хорошо ловят несоответствия между заявленным браузером и реальным сетевым стеком, а также массовые аномалии трафика.

В отличие от них, системы вроде DataDome и Kasada смещают фокус на браузер. Они проверяют не только значения fingerprint, но и реальное поведение среды: WebGL, canvas, execution timing, наличие automation-артефактов. Особенно это заметно в Kasada, где ключевую роль играет не то, что браузер возвращает, а как он выполняет код.

Отдельный класс - поведенческие системы, такие как PerimeterX. Они могут пропустить пользователя с идеальным fingerprint, но зафиксировать неестественные паттерны: одинаковую скорость действий, отсутствие вариативности, повторяемость сценариев. Здесь детект происходит не на уровне устройства, а на уровне действий.

Наконец, есть системы, ориентированные на корреляцию, например ThreatMetrix. Они строят граф связей между устройствами, IP и аккаунтами и выявляют аномалии на уровне всей экосистемы. Даже если отдельная сессия выглядит чистой, связь с другими подозрительными активностями может привести к детекту.

В реальности эти подходы не существуют изолированно. Крупные сервисы комбинируют несколько типов антифрода, чтобы покрыть разные уровни: сеть, браузер, поведение и историю.

Если обобщить, все системы сходятся в одном:

• сетевой слой проверяет откуда пришёл пользователь
• браузерный слой проверяет насколько он реалистичен
• поведенческий слой проверяет как он действует
• корреляционный слой проверяет с кем он связан

Именно комбинация этих уровней даёт итоговый риск.

Главная причина, почему антифрод стал настолько сложным - это распределение детекта по разным слоям. Больше не существует одной точки, которую можно «починить».

Можно пройти сетевой уровень, но завалиться на браузере.
Можно пройти браузер, но спалиться на поведении.
Можно пройти всё это, но попасться на корреляции.

Именно поэтому современный антифрод - это не про поиск одного сигнала, а про проверку целостности всей системы пользователя.

| Антифрод | Browser fingerprint | WebGL / GPU | Automation | TLS fingerprint | IP / ASN | Behavior | Correlation | Execution timing | Основная сила |
|----------|-------------------|------------|------------|----------------|----------|----------|-------------|------------------|--------------|
| Cloudflare | базовый | частично | базовый | очень сильный (JA3/JA4) | очень сильный | средний | средний | слабый | сеть + TLS |
| Akamai | средний | частично | средний | сильный | очень сильный | сильный | сильный | средний | глобальная аналитика |
| DataDome | очень сильный | сильный | сильный | средний | сильный | средний | средний | средний | browser fingerprint |
| Kasada | очень сильный | средний | очень сильный | слабый | слабый | сильный | слабый | очень сильный | execution env |
| PerimeterX | средний | слабый | средний | слабый | средний | очень сильный | средний | средний | behavior |
| ThreatMetrix | средний | слабый | слабый | слабый | сильный | средний | очень сильный | слабый | identity graph |

Типичные ошибки, на которых палятся даже хорошие антидетекты

Большинство детектов происходит не из-за слабого прокси или конкретного инструмента, а из-за несогласованности между слоями.

Один из самых простых и показательных кейсов - несоответствие TLS и браузера. Пользователь может заходить с Chrome, но TLS fingerprint при этом соответствует другому стеку, например OpenSSL или кастомному клиенту. Такая комбинация не встречается в реальной среде и детектится практически мгновенно. На практике это часто связано с тем, что многие антидетект-браузеры при работе с прокси используют локальную прослойку - промежуточный клиент или туннель, через который проходит трафик. В этом случае TLS формируется не самим браузером, а этой прослойкой, и чаще всего там не воспроизводится нативный TLS стек Chrome. В результате возникает рассинхрон между тем, что заявляет браузер, и тем, как выглядит реальное соединение.

Похожая ситуация возникает с GPU. Браузер может заявлять один рендер и характеристики устройства, но реальные результаты WebGL или WebGPU тестов показывают другое поведение: отличаются доступные возможности, лимиты, точность вычислений или поддержка функций. Это часто происходит в антидетектах, где отпечатки подставляются статически, без привязки к реальному поведению среды. В итоге значения выглядят правдоподобно по отдельности, но не совпадают с тем, что браузер реально способен воспроизвести.

На уровне CPU и производительности логика аналогичная. navigator может показывать ожидаемые параметры - количество ядер, память - но execution timing не соответствует этим значениям. Антифрод в этом случае сравнивает не сами цифры, а фактическое время выполнения операций и выявляет расхождение между заявленным и реальным поведением.

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

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

Ещё один частый сценарий - повторное использование одного и того же окружения. Когда один fingerprint появляется на разных аккаунтах, с разными IP и в короткий промежуток времени, это фиксируется на уровне корреляции. Здесь не важно, насколько «чистый» каждый отдельный сигнал - важна связь между ними.

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

Во всех этих случаях проблема не в конкретном параметре, а в их сочетании. Можно иметь корректный IP, правдоподобный браузер и аккуратно собранный fingerprint, но если они не согласованы между собой, это фиксируется как несоответствие.

Почему большинство “чекеров” ошибаются, и как должна работать глубокая проверка среды

Большая часть публичных чекеров проверяет только базовый слой: пару полей из navigator, тип IP, иногда WebRTC и простые флаги автоматизации.
Проблема в том, что такой подход часто создает ложное ощущение точности: пользователь видит “чисто” или “подозрительно”, но не понимает, насколько вывод вообще надежен.

В чем слабость базовых чекеров

Многие чекеры:

• смотрят только “паспортные” данные браузера (UA, platform, language);
• не делают активных вычислительных тестов;
• не сверяют данные между независимыми слоями;
• не учитывают NAT/CGNAT и ограничения IP-аналитики;
• выдают результат без нормальной объяснимости.

Из-за этого пользователь может быть введен в заблуждение в обе стороны:

• получить “ок” при реально поддельной среде;
• получить “риск” на легитимной конфигурации (VPN, роуминг, корпоративная сеть, нестандартный драйвер и т.д.).

Как должен работать современный чекер

Сильный чекер оценивает не отдельные флаги, а внутреннюю согласованность среды:

• browser/device слой: API-consistency, WebGL/WebGPU, execution timing, automation-артефакты;
• network слой: ASN, тип сети, VPN/Tor/datacenter, провайдерный контекст;
• межслойная корреляция: совпадает ли то, что среда “заявляет”, с тем, что она реально “показывает”;
• риск-модель: не бинарный ярлык, а накопление независимых конфликтов с объяснением.

Что отличает наш чекер

Наш чекер построен именно как глубокая антифрод-проверка:

• проверяет среду по уровням, а не по одной метке;
• делает активные тесты, а не только читает поля;
• учитывает межслойные конфликты (browser ↔ network ↔ execution);
• снижает ложные срабатывания за счет нормализации и контекстной логики;
• отдает объяснимый результат: какие сигналы сработали и почему.

Итог простой:
обычные чекеры часто проверяют “витрину”, а не реальную среду.
Наш чекер проверяет именно поведение и согласованность системы, поэтому дает более надежную картину риска и меньше вводит пользователя в заблуждение.

Примеры результатов с чекера

Как увидеть внутреннюю логику антифрода через скрипты

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

Практически это делается через готовый скрипт (например, размещённый в Gist), который логирует обращения к WebGL, Canvas, Audio, navigator и другим API. После установки достаточно открыть сайт, обновить страницу и выполнить обычные действия пользователя - все вызовы будут фиксироваться в консоли DevTools.

Команды для анализа

• __afProbe.dumpTop()
  Показывает, какие API вызываются чаще всего - основной инструмент для понимания приоритетов антифрода.
• __afProbe.recent(50)
  Выводит последние события в порядке выполнения, помогает понять последовательность проверок.
• copy(__afProbe.exportJson())
  Копирует полный лог для анализа или сохранения.
• __afProbe.clear()
  Очищает данные перед новым прогоном.

Как читать результат

• Частые webgl.getParameter / webgl2.getParameter
  → активная проверка GPU и WebGL fingerprint
• Частые canvas.toDataURL / canvas.getContext
  → используется canvas fingerprint
• Частый Intl.DateTimeFormat.resolvedOptions
  → проверка timezone и locale
• Обращения к navigator.webdriver
  → базовый детект automation
• Вызовы offlineAudio.startRendering
  → используется audio fingerprint
• rtc.createOffer / rtc.createDataChannel
  → задействован WebRTC слой

Пример интерпретации результата

• В топе WebGL + Canvas + Intl
  → многоуровневый антифрод с глубокой проверкой среды
• В основном только navigator.*
  → простой уровень детекта
• Есть WebGL + Audio + Timing
  → продвинутый fingerprinting (уровень DataDome / Kasada)
• Добавляется WebRTC
  → проверяется сетевая согласованность

Финальный вывод

Современный антифрод - это не про прокси, не про браузер и не про ботов.

Это система, которая отвечает на один вопрос: может ли вся эта среда существовать в реальности?

Если ответ «нет» - пользователь получает риск.

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

• Что такое WebRTC?
• Как антифрод системы используют WebRTC для детекта прокси?
• Почему практически все чекеры на утечку WebRTC бесполезны, как антидетект браузеры обманывают вас благодаря им и могут и почему некоторые антидетект браузеры сдают вас антифродам?
• Какие сервисы используют проверки WebRTC и как определить есть ли она там или нет?
• 1. Сканирование сети через TCPdump, Wireshark и подобное ПО
• 2. Проверка сурсов сайта через DevTools
• 3. Инжект в страницу скрипта, который будет присылать аллерты
• Сервисы которые используют новый вид проверки WebRTC через SRTP
• Как полноценно защититься от утечки WebRTC и не вызывать подозрения у антифрода его блокировкой.

Что такое WebRTC?

WebRTC - это P2P-соединение, которое было создано для передачи любых данных в реальном времени между большим количеством кандидатов (клиентов), в основном для аудио. Для быстрой передачи данных был выбран UDP-протокол из-за того, что он позволяет отправлять данные без хендшейка и прочих механизмов компрессии, которые добавляют дополнительный оверхед.

Как антифрод системы используют WebRTC для детекта прокси?

Ответ на данный вопрос максимально прост - из-за того, что в основе WebRTC лежит UDP, а если немного подробнее, то из-за того, что многие антидетект-браузеры не поддерживают проксирование UDP, и вообще малая часть прокси умеет работать с ним.

Данная история тянется примерно с 2013 года: тогда были интегрированы первые максимально простые способы для детекта WebRTC, и в то же время были запущены чекеры на утечку DNS. Один из них знают многие - Browserleaks, к нему вернёмся немного позже.

Первые способы детекта были максимально примитивные, проверка выглядела так

var pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});

pc.createDataChannel("");

pc.onicecandidate = function(e) {
  if (!e.candidate) return;

  console.log(e.candidate.candidate);
};

pc.createOffer().then(o => pc.setLocalDescription(o));

Сайт просил клиента вернуть список кандидатов для P2P-адресов без какой-либо валидации на стороне сервера. Тогда и был придуман способ для обмана данной проверки, который до сих пор используется во многих антидетект-браузерах либо в немного модифицированной версии:

const Orig = window.RTCPeerConnection;

window.RTCPeerConnection = function(cfg) {
  const pc = new Orig(cfg);

  pc.addEventListener("icecandidate", e => {
    if (e.candidate) {
      e.candidate.candidate =
        e.candidate.candidate.replace(
          /\d+\.\d+\.\d+\.\d+/,
          "127.0.0.1"
        );
    }
  });

  return pc;
};

Способ обхода, как и сама проверка, были максимально примитивными: достаточно было заинжектить на страницу скрипт, который при вызове icecandidate (это метод, который получает и возвращает список всех кандидатов) устанавливал любые адреса в ответ.

Некоторое время такая подмена работала, но антифроды не стоят на месте: в ход пошли двусторонние SRTP-проверки с валидацией на стороне сервера, и тогда же начались огромные волны банов, о которых, возможно, даже кто-то слышал. Например: Ticketmaster в 2018, Facebook в 2017–2018, Google в 2018–2019 и куча других сервисов.

Волны банов начались из-за того, что практически все тогда использовали классическую функцию подмены кандидатов на стороне клиента и не блокировали отправку WebRTC. Из-за того, что WebRTC начали проверять на сервере, он просто сопоставлял TCP-IP клиента и UDP-IP. В таком случае TCP-IP будет прокси, а UDP - устройства, с которого производится подключение. Простыми словами - утечка реального IP через WebRTC.

Тогда антидетект-браузеры начали просто блокировать WebRTC на уровне ядра браузера либо ломать стандартные функции для установки WebRTC-соединения, чтобы соединение на сервер не устанавливалось. Для антифрода это, конечно, подозрительно, но если нет других триггеров, подтверждающих подмену железа, использование прокси и т.д., то он просто записывает вас на карандаш.

Сейчас это работает не везде, особенно на посредственных антидетект-браузерах. За последние несколько лет антифрод-системы начали уделять огромное внимание железу, проверяя всё, что возможно - CPU, GPU, шрифты, CSS и т.д. Об этом я подробнее расскажу в следующей статье про виды антидетектов, как именно работает их многоуровневая проверка и почему даже на максимально «грязном» IP можно пройти некоторые антифрод-системы.

Из-за этого в последние годы всё чаще всплывают вопросы:
«Почему не удаётся решить Funcaptcha в Twitter, уже все виды прокси перепробовал?» или аналогичные вопросы по поводу Hcaptcha Enterprise и других антифрод-систем.

В данных ситуациях накладывается всё: грязные отпечатки, плохая подмена данных самим антиком, и заключительным гвоздём в крышку гроба становится WebRTC. Самое простое решение в данной ситуации - отключение прокси и блокировка WebRTC в профиле, а также раздача интернета с телефона или использование интернета с ПК, если нужно произвести действия с одного аккаунта. Если по отпечаткам не всё так плохо, то данный способ поможет, добавив дополнительные «баллы» за WebRTC и QUIC, но также бывают ситуации, когда это не помогает и нужно менять отпечатки.

Способ с раздачей интернета или использованием домашнего плох тем, что у аккаунта резко два раза меняется гео, и антифрод за такие манипуляции может забанить. Для Discord, Twitter и других соцсетей он ещё подходит, но если работа производится с FB Ads или любым другим сайтом, где стоит антифрод от Akamai, с огромной вероятностью аккаунт будет заблокирован. Поэтому единственное правильное решение, максимально минимизирующее шанс блокировки, - это использование прокси с поддержкой UDP и антидетекта с поддержкой его туннелирования.

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

В предыдущей главе был описан максимально старый, примитивный способ детекта и подмены WebRTC из 2013 года. До сих пор практически все чекеры и некоторая часть антидетект-браузеров используют данный способ. Из-за этого сервисы наподобие whoer, browserleaks, ipleak показывают неверную информацию, создавая иллюзию безопасности, но на деле у вас будет утекать реальный IP, если антидетект-браузер его не блокирует, либо он будет заблокирован, что подтолкнёт антифрод к дополнительной слежке и проверке.

Если вы используете антидетект-браузеры и прокси без поддержки UDP, убедитесь, что WebRTC отключён, т.к. до сих пор существует большое количество антидетект-браузеров, которые используют старый способ подмены без блокировки, и у вас будет утекать реальный IP. Пример утечки на скриншоте ниже.

Важно: если вы используете прокси с поддержкой UDP, TCP-IP и UDP-IP у вас могут отличаться, и это нормально, т.к. многие мобильные/домашние провайдеры используют Dual NAT или симметричный/CG-NAT. В таком случае по WebRTC будет получаться не ваш домашний IP, а IP вашего провайдера, который используется как точка входа в NAT. Такой вид NAT особенно распространён в Америке, например у T-Mobile USA.

Какие сервисы используют проверки WebRTC и как определить есть ли она там или нет?

Способов определения наличия проверки WebRTC на сайте несколько:

1. Сканирование сети через TCPdump, Wireshark и подобное ПО

Если на сайте есть вызов WebRTC, то в Wireshark или TCPdump вы увидите отправку STUN-соединений на сервер сервиса (см. скриншот ниже).

У данного способа есть масса минусов:

1. он слишком затратный по времени;
2. если вы ранее не работали с подобным ПО, то в первые разы будет сложно разобраться, как фильтровать и сканировать пакеты;
3. параллельно запущен Discord или другой сайт, использующий WebRTC, вы можете перепутать сервера;
4. сайт может маскировать передачу кандидатов под XMLHttpRequest или WebSocket, тогда вы не увидите отправку запроса к серверу.
   

2. Проверка сурсов сайта через DevTools

Открыв DevTools на сайте, можно через поиск по Sources найти функции для работы с WebRTC по ключевым словам: RTCPeerConnection, RTCIceCandidate, RTCSessionDescription, RTCDataChannel, iceConnectionState, iceTransport, createDataChannel. Также при необходимости можно поставить breakpoints и отдебажить.

Единственный минус этого способа в том, что сайт может быть обфусцирован, и будет тяжело что-то найти, например как у Funcaptcha.

3. Инжект в страницу скрипта, который будет присылать аллерты

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

На примере LinkedIn можно полностью увидеть все этапы, т.к. у них проверка вызывается сразу на главной странице.

На других антифродах может быть всё не так очевидно, т.к. чаще всего происходит инициализация WebRTC, а запрос отправляется только при наличии подозрений по более дешёвым проверкам (отпечатки и т.д.). Эту тему раскрою подробнее в следующей статье.

Инструкцию и сам скрипт для дебага вы можете найти в нашем гитбуке

Сервисы которые используют новый вид проверки WebRTC через SRTP

Arkose Labs (Funcatpcha Enterprise - Twitter, EpicGames, Roblox и тд)
Cloudflare Turnstile
Hcaptcha Enterprise (Discord, CoinBase, OpenSea, Kraken)
Akamai (Linode, Nike, Ticketmaster, Linkedin)
PerimeterX (StockX, Walmart)
DataDome
Kasada
SEON (Revolut, Bitpanda)
ThreatMetrix (PayPal, American Express)
Криптобиржи, неизвестные SaaS-решения (Binance, OKX, MEXC, Bybit и т.д.)

Как полноценно защититься от утечки WebRTC и не вызывать подозрения у антифрода его блокировкой.

Есть только один способ полностью защититься от этого — использовать прокси с поддержкой UDP и антидетект с поддержкой UDP-туннелирования либо стороннее ПО для проксирования процесса/всей системы.

У второго случая есть единственный минус — можно использовать одновременно только одну прокси и, соответственно, один профиль. Также на резидентских прокси будет потребление трафика в несколько раз больше, чем при использовании прокси только в браузере.

Приобрести все виды прокси с подержкой UDP вы можете у нас на сайте, а так же ознакомиться в документации с ПО и антидетектами поддерживающими проксирование UDP.

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

Данной подсети в geofeed нет, первый звоночек есть.

Второй способ - трассировка до адреса (traceroute/mtr)
У многих домашних провайдеров для датацентр услуг используются отдельные маски для маршрутизаторов с типом DCH и меткой router и на таких провайдерах, по последним хопам можно понять, что подсеть анонсируется в датацентре, либо если тот кто поднимал прокси неопытный и не закрыл ICMP пакеты, то можно прозвониться вплоть до сервера, который управляет подсетями. Т.к обычно сервера у провайдеров не арендуются из-за того что цены на их услуги довольно высокие, а просто пробрасывается GRE туннель от маршрутизаторов до любого другого хостинга в датацентре.
У DTAG нет отдельных масок для дц и ICMP закрыт, по этому тут ничего не было найдено

Третий способ - whois по базе регистратора подсети и GeoIP базам
Тут начинается самое интересное, в основном подсети после домашних провайдеров арендуются на IPXO, есть ещё пару других маркетплейсов, но этот самый крупный.

Посмотрев на результаты из RIPE DB сразу всё становится понятно

Подсетью ранее владел SCALEIT, он же выдал права IPXO для управления подсетью - создание route object и тд. В данном случае просто был создан route object на ASN DTAG. Даже старые записи о названии сети не были подтёрты, но если были бы убраны, то это ничего бы не изменило, т.к подделать название организации которая владеет подсетью невозможно.
В данном случае это Private Customer с abuse почтой report@abuseradar.com. Abuseradar это прослойка IPXO

Вот к примеру как должна выглядеть реальная подсеть DTAG

Результат с ip2location подтверждает, что данная подсеть и прокси на ней являются фейк ISP. Опираться только на его результаты не стоит, т.к они проводят полные проверки адресов только 2-3 раза в год и какие-то подсети могли ещё не задетектить. Если подсеть ещё не задетектили, то по ip2loc можно увидеть только максимально явные миссматчи, например - ASN DTAG, а domain ukrtelecom.ua или любого другого провайдера, сейчас urktelecom чаще всего встречается, т.к было много выброшено их подсетей на рынок.

Для полной проверки советуем воспользоваться нашим чекером, который проводит детальную проверку, если айпи анонсирован на ASN домашнего/мобильного провайдера

Есть ещё и четвёртый способ, но обычным смертным он недоступен. Существует так называемый реестр адресов домашних провайдеров, в который все домашние провайдеры подают свои адреса и он используется некоторыми антифродами.

После прочтения всего этого может возникнуть вопрос - а нельзя ли попросить провайдера чтобы он добавил адреса в geofeed или подал заявку на обновление данных?
Нет, ни один тир 1 провайдер не будет такого делать. До недавнего времени с ATT можно было договориться, но их оштрафовали за это и лавочка закрылась.

По этому если видите заголовки, что прокси имеют айпи адреса тир 1 провайдеров, в 99% случаях это будут фейк ISP. Реальные ISP можно получить только работая с тир 2-3 провайдерами, но это очень затратно по времени, либо имея связи с тир 1 провайдером, но стоить это будет обычному пользователю минимум 2.5-3$, и по этому больше половины рынка прокси заполнено фейк ISP прокси.

В обычной работе браузер формирует два типа соединений:

• TCP — для загрузки веб-страниц, статики, файлов, медиа-контента. Здесь ключевым является надёжность: все пакеты должны дойти, быть упорядочены и собраны в правильном порядке.
• UDP — для DNS-запросов, HTTP/3 (QUIC), WebRTC-звонков, потокового вещания и игровых протоколов. В таких сценариях важнее минимальная задержка и высокая пропускная способность, чем абсолютная гарантия доставки каждого байта.

При использовании классического TCP-прокси весь UDP-трафик либо блокируется, либо утекает напрямую в интернет вне прокси, используя основной айпи систему. Анти-фрод-системы (Google, Cloudflare, Discord, Twitter и тд.) анализируют профиль активности клиента:

1. Если нет UDP-запросов (DNS, WebRTC, HTTP/3 (QUIC) и тд), система помечает сессию как «нетипичную» для реального пользователя.
2. Клиент, который виден лишь как источник TCP-пакетов, автоматически получает более строгую фильтрацию (капча, верификация номера или другие дополнительные проверки) или вовсе блокируется как потенциальный бот.

Чтобы устранить это несоответствие и повысить уровень доверия со стороны анти-фрод-систем, в ProxyShard была внедрена полноценная поддержка UDP в протоколе SOCKS5. На текущем этапе эта функциональность доступна в тестовом режиме на дата-центр прокси в Нидерландах, но уже в ближайшее время она будет развёрнута в других регионах и на ISP-прокси, которые скоро будут доступны, сейчас ведутся тесты.

Мы и наши клиенты провели серию сравнительных тестов, которые наглядно демонстрируют эффективность UDP-поддержки:

1. Регистрация Google аккаунтов без номера
• С UDP 15 аккаунтов из 15 попыток.
• Без UDP 0 из 15.
2. Регистрация Discord аккаунтов и вход в каналы
• С UDP 3 аккаунта из 3 с привязкой первого попавшегося номера с сервиса для активации и вход в каналы с анти-бот защитой (OpenSea, IOTA и тд).
• Без UDP на всех аккаунтах не дало привязать номер и не пускало в некоторые каналы.
3. Регистрация Twitter
• С UDP на всех аккаунтах регистрация прошла без капчи, спустя час на все аккаунты прилетел ревериф по почте, везде без каких либо проблем прошёлся.
• Без UDP на этапе регистрации была капча и так же примерно спустя час прилетел ревериф, но уже по номеру.
4. Регистрация Instagram
• С UDP на всех аккаунтах регистрация прошла без капчи, реверифа по номеру не последовало.
• Без UDP на этапе регистрации была капча, спустя минут 15-20 прилетел ревериф по номеру.
5. Регистрация Facebook ADS
• С UDP на всех аккаунтах регистрация прошла без капчи, реверифа по номеру не последовало. На следующий день прилетела верификация по видео, это нормальное поведения для Facebook, в последнее время он всем рассылает его
• Без UDP на этапе регистрации была капча, спустя час заблокировали аккаунт

Подводя итог: для полной маскировки сетевого профиля и обхода детект-механизмов необходимо проксировать не только TCP, но и UDP-трафик. Для работы с UDP-прокси требуются анти-детект браузеры, поддерживающие UDP прокси, о списке которых мы сообщим позже.

Stay turned…