Тайминг-атаки через WebSockets: как антифрод сканирует ваши локальные порты

Хотите попробовать Octo Browser со скидкой?
По промокоду OCTOSCRAPER получите 30% скидку на любую подписку. Предложение действительно только для новых пользователей.

Как WebSocket превращается в локальный сканер

Для начала немного контекста: WebSocket — это протокол связи поверх TCP, предназначенный для обмена сообщениями между клиентом и сервером в режиме реального времени.

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

Как это происходит? Сразу после загрузки целевой веб-страницы или в момент авторизации скрытый антифрод-скрипт начинает асинхронно генерировать попытки подключения. Но он не сканирует все подряд. Скрипт использует адрес 127.0.0.1, перебирая заранее заданный пул портов (9222 для CDP, порты популярных локальных VPN-клиентов или баз данных). И, как правило, это работает.

Почему браузер позволяет так делать 

У современных браузеров и операционных систем есть две архитектурные особенности:

1. Обход жесткого CORS. Если бы антифрод попытался просканировать порты обычным HTTP-запросом (через fetch или XMLHttpRequest), браузер заблокировал бы чтение ответа из-за политики безопасности и правил запрета смешанного контента (mixed content). Однако стандарт WebSocket не использует классическую модель CORS для ограничения чтения ответов, а передает заголовок Origin, который может проверяться сервером. Сам факт установки или ошибки соединения уже дает данные для анализа. 

2. Слепота брандмауэра. Сетевой интерфейс loopback (ваша локальная заглушка 127.0.0.1) обладает колоссальным уровнем доверия со стороны операционной системы. Трафик, идущий от браузера к локальному порту, физически не выходит на сетевую карту. Большинство штатных брандмауэров Windows или macOS по умолчанию вообще не фильтруют такие внутренние соединения, считая их безопасными.

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

Механика тайминг-атаки

Браузерная песочница сильно ограничивает скрипты. Из-за политик безопасности (SOP/CORS) скрипт не может просто прочитать ответ от локального сервиса или получить точный код ошибки соединения. Но в случае тайминг-атак ему это и не нужно. Механика выглядит следующим образом:

1. Скрипт запускает внутренний таймер (чаще всего через performance.now()).

2. Инициируется попытка WebSocket-соединения new WebSocket('ws://127.0.0.1:9222').

3. Скрипт ждет срабатывания обработчика ошибок (onerror).

4. Таймер останавливается при срабатывании ошибки, и вычисляется дельта времени.

Суть в том, как сетевой стек операционной системы обрабатывает TCP-соединения:

• Если порт закрыт: операционная система отклоняет входящий SYN-пакет, отправляя в ответ TCP RST. Браузер закрывает сокет и вызывает onerror. Время отклика в локальной сети минимальное — обычно 1–5 миллисекунд.

• Если порт открыт: происходит полноценное трехстороннее рукопожатие (TCP Handshake). Затем браузер отправляет HTTP-запрос на Upgrade до WebSocket-соединения. Даже если на порту висит не WS-сервер (а, например, база данных или SSH), соединение обрывается не сразу, а из-за неверного протокола. Затраты времени на хендшейк и обмен данными делают временную дельту заметно больше — от 10 до 50 миллисекунд.

• Если порт фильтруется брандмауэром: он отбрасывает SYN-пакет, полученный от сервера. Браузер не получает ответа от ОС и ждет системного тайм-аута. В этом случае временная дельта существенно больше и измеряется секундами.

Современные браузеры округляют значения таймеров до 0,1–1 мс. Но для сетевых тайминг-атак такая точность не нужна. Разница между мгновенным TCP RST и зависанием на открытом порту измеряется десятками миллисекунд. Этого достаточно для надежного детекта.

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

Перед сканированием целевых портов скрипт калибруется. Он стучится на заведомо случайный, высокий и закрытый порт (ws://127.0.0.1:54321), чтобы измерить ваш персональный базовый отклик закрытого порта в данный момент времени. И уже относительно этого эталонного значения вычисляются аномалии на рабочих портах мультиаккаунтинга.

Зачем антифроду ваш localhost

Цель антифрод-систем — деанонимизация профиля и поиска следов мультиаккаунтинга. 

Большинство антидетект-решений концентрируются на подмене цифровых отпечатков (Canvas, WebGL, шрифты) и оставляют сетевой стек без должного внимания. Открытые специфические порты служат для систем защиты надежным маркером подмены цифровой личности и использования инструментов автоматизации.

Что ищут скоринговые алгоритмы:

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

Если у вас открыт порт 9222, это сигнал, что профилем управляет не живой человек, а скрипт (Puppeteer, Playwright, Selenium) через протокол CDP. Никакие эмуляции движений мыши или человеческого ввода уже не помогут — сессия рискует получить максимальный риск-скор, и в лучшем случае покажется капча, а в худшем (если антифрод жесткий) — сессия будет забанена.

Если у вас открыты порты 22 (SSH), 3306 (MySQL) или специфические порты локальных прокси-клиентов, замаскироваться под обычного пользователя тоже не выйдет. Антифрод понимает, что перед ним, скорее всего, виртуальная машина, арендованный сервер или рабочая станция арбитражника. Уровень доверия к аккаунту падает.

Кросс-линкинг и связывание ферм аккаунтов

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

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

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

Как защититься: изоляция и брандмауэр

При работе с серьезными антифрод-системами ваша защита должна строиться на следующих принципах:

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

• Правильная настройка брандмауэра: межсетевой экран должен быть сконфигурирован так, чтобы не просто блокировать, а мгновенно отклонять попытки соединения. Нужно использовать правило REJECT (которое сразу отправляет TCP RST), а не DROP (которое заставляет пакет висеть до тайм-аута). Именно REJECT имитирует естественно закрытый порт, не вызывая подозрений у тайминг-анализатора.

• Глобальная блокировка: самый радикальный, но действенный метод — полный запрет браузеру обращаться к localhost. Это мгновенно нейтрализует скрипты антифрода, которые прощупывают вашу систему.

Тем не менее у глобальной блокировки есть обратная сторона. Некоторые сервисы (приложения для работы с аппаратными ключами или цифровыми подписями ЭЦП) используют локальных агентов. Отсутствие связи с ними само по себе может стать аномалией для скоринга.

Поэтому оптимальных решений в данной ситуации два:

• Точечная фильтрация: разрешение доступа на уровне брандмауэра или расширений только для доверенных локальных ресурсов и жесткое отсечение (через REJECT) любых фоновых попыток установить WebSocket-соединение с неизвестными портами. 

• Использование специализированных инструментов, которые делают это на уровне ядра (антидетект-браузеры).

У антидетект-браузера Octo Browser, например, есть защита от сканирования портов. С этой фичей Octo берет контроль за такими соединениями на себя и перехватывает на уровне браузерного API любые попытки скриптов (включая API WebSockets) обратиться к адресам 127.0.0.0/8 или localhost .

Проверяем защиту своими руками

Проверить, как это работает, можно при помощи простого теста. 

Для начала запустите на компьютере обычный локальный сервер с открытым портом.

Выглядеть открытый порт будет примерно так

Затем откройте любой сайт в вашем браузере и попытайтесь получить доступ к открытому порту. 

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

Если сделать то же самое через Octo Browser, вы увидите, что порт закрыт

Octo Browser контролирует доступ к вашим портам, чтобы не допустить утечки. 

Работает ли Private Network Access (PNA)

Private Network Access — это функция безопасности в современных браузерах (прежде всего в Chrome), предотвращающая отправку публичными веб-сайтами запросов к устройствам или серверам в локальной сети пользователя.

Действительно, современные браузеры пытаются закрыть эту уязвимость:

1. Ограничивают или полностью блокируют доступ к localhost из небезопасных публичных контекстов.

2. Требуют строгого Secure Context (HTTPS) для инициации таких соединений.

3. Направляют предварительные запросы (CORS Preflight) перед тем, как разрешить доступ к локальной сети.

Но разработчики защитных систем тоже адаптируются. Они используют публичные домены, которые резолвятся в 127.0.0.1 (yourapp.localhost.com), и работают через валидные HTTPS-сертификаты, обходя часть базовых ограничений.

И самое главное: PNA не спасает от тайминг-атак на уровне TCP. Даже если PNA в итоге заблокирует запрос к локальному порту из-за отсутствия правильных заголовков, браузеру сначала нужно установить TCP-соединение, чтобы эти заголовки попытаться прочитать. Если порт закрыт — ОС все так же мгновенно отбивает запрос (TCP RST за короткий промежуток времени). Если порт открыт — TCP Handshake успешно проходит, браузер пытается инициировать обмен данными, натыкается на ограничения PNA и только потом разрывает соединение и выдает ошибку. На все это уходят те самые десятки миллисекунд, которых и хватает алгоритму антифрода. PNA запрещает чтение данных, но не может скрыть сам факт затраченного на подключение времени.

Заключение

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