Как антифрод-системы вычисляют прокси по анализу TCP/IP стека и MTU

Как антифрод вычисляет прокси по TCP/IP стеку

Антифрод-системы смотрят глубже, чем просто IP в базе. Они анализируют сам TCP/IP стек — как твой клиент общается с сервером. И прокси тут выдают себя с головой.

Дело в физике. Каждая ОС формирует пакеты по-своему. Windows, Linux, macOS, Android — у каждого свой fingerprint. Прокси-сервер модифицирует эти пакеты. Или не модифицирует, но тогда антифрод видит несоответствие: ОС клиента говорит одно, а поведение стека — другое.

TCP/IP fingerprint: что именно смотрят

Антифрод собирает кучу параметров из TCP handshake. SYN-пакет — кладезь информации. Вот что анализируют:

- **TTL (Time To Live)** — начальное значение. Windows ставит 128, Linux — 64, Solaris — 255. Если TTL пришёл 128, а ОС в User-Agent — Linux, это стоп-сигнал.

- **Window Size** — размер окна приёма. Windows любит 65535 или 8192. Linux — 29200 или 5840. Отклонения от нормы — подозрение.

- **MSS (Maximum Segment Size)** — максимальный размер сегмента. Обычно 1460 для Ethernet. Но прокси может резать пакеты, и MSS меняется.

- **TCP Timestamps** — опция, которая показывает, включена ли она у клиента. Прокси часто вырубают timestamps для анонимности, но тогда антифрод видит: "клиент без timestamps — 90% прокси".

- **Window Scaling** — масштабирование окна. Разные ОС используют разные множители. Windows — 8, Linux — 7 или 3. Несовпадение — красный флаг.

Всё это складывается в уникальный отпечаток. Библиотеки типа p0f собирают такие сигнатуры и сравнивают с эталонами.

MTU — неожиданный палец вверх

MTU (Maximum Transmission Unit) — максимальный размер пакета на сетевом интерфейсе. Обычно 1500 байт для Ethernet. Но прокси-серверы часто меняют MTU. Почему? Потому что они работают через туннели, VPN, GRE — там MTU может быть меньше.

Антифрод измеряет MTU косвенно — через размер ICMP-пакетов или через фрагментацию. Если клиент шлёт пакеты с MTU 1400, а типовой MTU для его провайдера — 1500, это подозрительно.

Реальный кейс: один сервис блокировал всех, у кого MTU отличался от 1500. Оказалось, 90% их легитимных пользователей сидели на Ethernet. А прокси-арендаторы часто используют VPS с MTU 1450 или 1492 (PPPoE). Профит.

Пример: curl и анализ стека

Вот как выглядит захват SYN-пакета с помощью tcpdump:

```bash

sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

```

Результат для Windows 10:

```

IP 192.168.1.2.54321 > 10.0.0.1.80: Flags [S], seq 12345, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

```

Для Linux:

```

IP 192.168.1.2.54321 > 10.0.0.1.80: Flags [S], seq 12345, win 29200, options [mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7], length 0

```

Разница видна невооружённым глазом. Антифрод может за секунду понять, кто ты.

Python-скрипт для проверки MTU

Если хочешь проверить MTU своего соединения, вот простой скрипт:

```python

import socket

import struct

def get_mtu(host):

try:

Создаём сырой сокет

sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)

sock.settimeout(5)

Пингуем с разными размерами

for size in range(1500, 1400, -10):

packet = struct.pack('!BBHHH', 8, 0, 0, 0, 1)

packet += b'A' * (size - 28) # 28 байт заголовок IP+ICMP

Отправляем

sock.sendto(packet, (host, 1))

try:

data, addr = sock.recvfrom(1024)

print(f"MTU {size}: OK")

except:

print(f"MTU {size}: FAIL - фрагментация")

except Exception as e:

print(f"Error: {e}")

get_mtu("8.8.8.8")

```

Но предупреждение: сырые сокеты требуют root. И на некоторых хостингах это запрещено.

Как прокси себя выдают

Прокси-серверы — это посредники. Они принимают пакет от клиента, разбирают его, потом собирают заново и отправляют на целевой сервер. В этом процессе теряются оригинальные параметры стека.

**Сценарий 1: Прокси не меняет TTL.**

Клиент с Windows (TTL=128) шлёт через прокси на Linux (TTL=64). Сервер получает TTL=128, но видит, что пакет пришёл с IP прокси, который обычно живёт на Linux. Несоответствие.

**Сценарий 2: Прокси подменяет Window Size.**

Некоторые прокси выставляют фиксированный Window Size для всех клиентов. Антифрод видит: "У 1000 разных пользователей одинаковый Window Size — это прокси".

**Сценарий 3: MTU не совпадает с ожидаемым.**

Провайдеры обычно используют MTU 1500. А VPS-провайдеры — 1450 или 1492. Если клиент сидит на VPS, его MTU будет отличаться от типового.

Таблица: типовые параметры TCP/IP стека

| Параметр | Windows 10 | Linux 5.x | macOS | Android |

|----------|------------|-----------|-------|---------|

| TTL | 128 | 64 | 64 | 64 |

| Window Size | 65535 | 29200 | 65535 | 65535 |

| MSS | 1460 | 1460 | 1460 | 1460 |

| Window Scaling | 8 | 7 | 3 | 8 |

| TCP Timestamps | Да | Да | Да | Да |

| SACK | Да | Да | Да | Да |

Если у клиента комбинация не из таблицы — это либо старая ОС, либо прокси.

Что можно сделать? Прокси с фиксацией стека

Есть прокси, которые умеют подменять TCP/IP стек под нужную ОС. Например, 3proxy с модулем tcp_fingerprint. Или socks5-прокси на Go с ручной сборкой пакетов.

Но это сложно. Нужно эмулировать не только TTL и Window Size, но и тайминги, поведение при ретрансмиссии, порядок опций. Антифроды типа DataDome или PerimeterX анализируют десятки параметров.

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

Реальный кейс: lexic.ml и анализ MTU

Один из наших клиентов работал с площадкой, где антифрод блокировал всех с MTU != 1500. Стандартные прокси с VPS отлетали сразу. Он перешёл на наши IPv6 прокси — и проблема ушла. Почему?

Мы используем выделенные серверы с прямым Ethernet-подключением. MTU там родной, 1500. Никаких туннелей, никакого PPPoE. Пакеты летят как с обычного домашнего роутера. Антифрод не цепляется.

Как антифрод обходит прокси: дополнительные техники

Анализ TCP/IP стека — не единственный метод. Есть ещё:

- **HTTP-заголовки**: X-Forwarded-For, Via, X-Real-IP. Прокси часто забывают их чистить.

- **WebRTC**: скрипт на сайте может запросить локальный IP клиента через WebRTC. Если он не совпадает с IP подключения — прокси.

- **DNS-запросы**: если DNS-запросы идут не через прокси, а напрямую, виден реальный IP.

- **Время отклика**: прокси добавляют задержку. Если пинг до сервера 200 мс, а до прокси 50 мс — странно.

Итог

Антифрод-системы уже давно не смотрят только на IP. Они анализируют весь стек — от TTL до MTU. Прокси, которые не умеют эмулировать поведение реальной ОС, вычисляются за секунду.

Если тебе нужно обойти антифрод, выбирай прокси с правильным TCP/IP стеком. Или используй реальные устройства с мобильными IP. Всё остальное — игра в кошки-мышки, где кошка становится умнее с каждым днём.