Как антифрод-системы вычисляют мобильные прокси по особенностям TCP-стека и таймингам

TCP-стек — паспорт вашего устройства

Каждая операционная система собирает TCP-пакеты чуть по-разному. Разные значения initial window, разные тайминги отправки ACK, разные алгоритмы контроля перегрузки. Для антифрод-системы это как отпечатки пальцев.

Windows, Linux, Android, iOS — у каждого своя сигнатура. Linux с ядром 5.x отправляет окно 10 сегментов (mss 1460), Windows 10 — 64 сегмента. Android на базе Linux 4.14 — 10 сегментов, но с другими опциями в заголовке.

Мобильный прокси — это сервер в дата-центре, который принимает TCP-соединение от клиента. Сервер работает на Linux. Клиент — браузер или приложение на Windows. Антифрод видит TCP-стек Linux. Но клиент заявляет, что он на Windows. Несоответствие.

Вот как это выглядит на практике. Соединение с мобильного прокси:

```

TCP options: MSS 1460, SACK permitted, Timestamp, Window scale 7

Initial window: 10 segments

```

Соединение с реального мобильного устройства:

```

TCP options: MSS 1400, SACK permitted, Timestamp, Window scale 6

Initial window: 4 segments

```

Разница видна сразу. MSS 1400 против 1460 — это следствие MTU 1420 в мобильных сетях. Сервер в дата-центре не знает про MTU сотовых сетей и отправляет стандартные 1460.

Тайминги — зеркало сети

Мобильные сети — это радиоэфир. Задержки там нестабильны. RTT может прыгать от 20 мс до 200 мс за секунду. Дата-центры — это оптика. Там задержки стабильные, джиттер минимальный.

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

Пример из практики: сервер в Амстердаме, прокси в Москве. RTT между ними — 60 мс ± 2 мс. Гистограмма — игла. Реальный мобильный клиент в Москве: RTT от 15 до 80 мс. Гистограмма — холм.

Ещё один параметр — тайминги ACK. Мобильные сети часто задерживают ACK из-за планировщика на базовой станции. Пачки ACK приходят с задержкой 40-50 мс. Дата-центр отправляет ACK мгновенно, с точностью до микросекунд.

Опции TCP — скрытые маркеры

Timestamp — самая показательная опция. Linux заполняет её по-своему. В ядре 5.x timestamp начинается с нуля при старте системы. Windows использует случайное смещение. Android — как Linux, но с особенностями.

Антифрод смотрит на частоту обновления timestamp. Linux обновляет его каждые 1 мс. Windows — каждые 10 мс. Если клиент говорит, что он на Windows, а timestamp обновляется каждую миллисекунду — это прокси.

Window scale — тоже маркер. Linux использует 7 (максимум). Windows 10 — 8. Android — 6 или 7 в зависимости от версии. Несоответствие window scale и заявленной ОС — красный флаг.

Мобильные прокси часто не настраивают TCP-стек. Они используют дефолтный Linux. А антифрод-системы обучены именно на дефолтных настройках.

Как проверить свой TCP-стек

Посмотрим, что видит сервер при подключении. Соберём сигнатуру:

```bash

tcpdump -i eth0 -nn -s 0 'tcp[tcpflags] & tcp-syn != 0' -c 100

```

Анализ опций:

```bash

tcpdump -i eth0 -nn -s 0 'tcp[13] & 2 != 0' -c 1 -X

```

Для автоматизации можно использовать python:

```python

from scapy.all import *

def analyze_tcp_syn(pkt):

if pkt.haslayer(TCP) and pkt[TCP].flags == 'S':

tcp = pkt[TCP]

opts = tcp.options

print(f"Source: {pkt[IP].src}")

print(f"MSS: {dict(opts).get('MSS', 'N/A')}")

print(f"Window scale: {dict(opts).get('WScale', 'N/A')}")

print(f"Timestamp: {dict(opts).get('Timestamp', 'N/A')}")

print(f"Window: {tcp.window}")

sniff(prn=analyze_tcp_syn, count=10)

```

Идентификация по поведению TCP

Помимо статических параметров, антифрод смотрит на поведение. Как TCP реагирует на потерю пакетов. Linux использует CUBIC. Windows — Compound TCP. Android — тоже CUBIC, но с другими настройками.

При потере пакета CUBIC уменьшает окно в 0.7 раза. Compound TCP — более агрессивно. Эти паттерны видны при анализе потоков.

Пример: сервер намеренно теряет пакет (drop rate 1%). Наблюдает за реакцией клиента. Если клиент уменьшает окно по алгоритму CUBIC — это Linux. Если по Compound — Windows. Прокси на Linux не может скрыть CUBIC.

Тайминги HTTP-запросов

TCP-стек — не единственный маркер. Тайминги HTTP-запросов тоже выдают прокси. Реальный мобильный клиент отправляет запросы с задержками, связанными с обработкой на устройстве. 50-200 мс между запросами — типично для человека, читающего страницу.

Прокси передаёт запросы с минимальной задержкой. 5-10 мс между запросами — подозрительно. Антифрод строит график интервалов между запросами. У реального пользователя — экспоненциальное распределение. У прокси — равномерное, с маленькой дисперсией.

Ещё один параметр — TTFB (time to first byte). Мобильная сеть добавляет 50-100 мс к TTFB из-за радиоинтерфейса. Прокси в дата-центре — 5-10 мс. Если TTFB слишком маленький для мобильного клиента — это прокси.

Кейс: банковский антифрод

Банк внедрил анализ TCP-стека. Клиент с мобильного устройства, но TCP-сигнатура Linux. Менеджер по рискам увидел: MSS 1460, window scale 7, timestamp 1 мс. Это сервер в дата-центре. Приложение говорило "Android 13", а TCP-стек — "Linux 5.15". Несоответствие привело к блокировке.

Решение: клиент использовал мобильный прокси для обхода гео-блокировки. Банк заблокировал операцию. Клиент потерял доступ на 3 дня.

Кейс: партнёрская программа

Рекламная сеть заметила аномалию. 80% трафика с одного мобильного прокси. TCP-сигнатура всех соединений — одинаковая. Один и тот же MSS, window scale, тайминги. Реальные мобильные устройства так не работают. У каждого своя сигнатура.

Сеть использовала алгоритм кластеризации по TCP-параметрам. Все соединения с прокси попали в один кластер. Партнёрская программа была закрыта, выплаты заморожены. Убыток сети — \$50,000.

Кейс: интернет-магазин

Магазин использовал прокси для проверки цен конкурентов. Антифрод заметил: запросы приходят с одного IP, но TCP-сигнатура меняется. Через час — новая сигнатура. Это указывало на ротацию прокси. Но ротация не помогла — антифрод кластеризовал соединения по поведению.

Решение магазина — использовать прокси с настройкой TCP-стека под мобильные устройства. Изменили MSS на 1400, window scale на 6. Но тайминги остались дата-центровскими. Антифрод вычислил по джиттеру RTT.

Скрыть или не скрыть

Можно подделать TCP-опции. Есть инструменты для изменения MSS, window scale, timestamp. Но тайминги — это физика сети. Сервер в дата-центре не может имитировать радиоэфир. Джиттер RTT, потеря пакетов, задержки ACK — всё это определяется сетью.

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

Настройка TCP-стека для прокси

Если нужно настроить прокси под мобильный трафик, можно изменить параметры ядра:

```bash

sysctl -w net.ipv4.tcp_window_scaling=1

sysctl -w net.ipv4.tcp_sack=1

sysctl -w net.ipv4.tcp_timestamps=1

```

Изменить MSS с помощью iptables:

```bash

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

```

Но это только начало. Нужно менять алгоритм контроля перегрузки, тайминги ACK, поведение при потере пакетов. Полная имитация мобильного TCP-стека — сложная задача.

Как антифрод обходит маскировку

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

Машинное обучение обучается на реальных мобильных соединениях. Модель знает, как выглядят распределения RTT, как меняются тайминги в зависимости от времени суток, как ведёт себя TCP при перегрузках.

Прокси-сервис не может имитировать все эти параметры одновременно. Каждая маскировка создаёт новые несоответствия. Антифрод находит их.

Выводы

TCP-стек и тайминги — мощный инструмент для идентификации. Мобильные прокси вычисляются по несоответствию между заявленной ОС и реальным TCP-поведением. Тайминги RTT и ACK выдают дата-центр. Полная маскировка требует глубокой настройки на уровне ядра и сети. Но даже тогда остаются следы.