Как антифрод-системы вычисляют прокси по MTU и TCP Window Scaling

Сетевой fingerprinting — не магия

Антифрод-системы смотрят на кучу параметров. IP-адрес, User-Agent, тайминги. Но есть вещи, которые ты не спрячешь в браузере. Параметры TCP/IP стека — они ниже уровнем. Операционная система их выставляет автоматически. Большинство прокси об этом даже не задумываются.

MTU и TCP Window Scaling — два таких параметра. Они передаются в открытую, на уровне рукопожатия TCP. Любой сервер их видит. И если твой трафик идёт через прокси — эти параметры могут выдать тебя с потрохами.

MTU — максимальный размер пакета

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

Итог: пакет становится больше 1500. Сеть начинает фрагментировать. Или MTU уменьшается. На клиенте это часто 1400-1450. Прокси-серверы, работающие через туннели, тоже имеют изменённый MTU.

Как это выглядит для антифрода:

- Клиент из России шлёт пакеты с MTU 1500

- Прокси в Нидерландах принимает, перепаковывает, шлёт дальше

- Сервер видит MTU 1420 или 1450

- При этом IP адрес — нидерландский

Несоответствие. Подозрительно.

TCP Window Scaling — коэффициент окна перегрузки

TCP использует скользящее окно для контроля потока данных. Изначально — 16 бит, максимум 65535 байт. Мало. Поэтому придумали Window Scaling — опцию TCP, которая умножает размер окна на коэффициент (от 1 до 14).

Конкретные цифры:

- Linux: по умолчанию 7 (масштаб 128)

- Windows: 8 (масштаб 256)

- macOS: 6 (масштаб 64)

- OpenVPN-туннель: часто 4-5

Антифрод собирает эти данные. Если у клиента Windows с масштабом 8, а через прокси вдруг приходит Linux с масштабом 7 — это стыковка не сходится. А если прокси ещё и OpenVPN — там вообще 4-5.

Как выглядит детекция на практике

Сервер при установке TCP-соединения получает SYN-пакет. В нём — все опции. Анализ происходит в реальном времени.

```

SYN-пакет:

- MSS (Maximum Segment Size) = 1460 (при MTU 1500)

- Window Scale = 7 (Linux)

- Timestamp = присутствует

- SACK = разрешён

```

Если клиент через прокси:

```

SYN-пакет:

- MSS = 1400 (MTU 1420 из-за туннеля)

- Window Scale = 4 (OpenVPN)

- Timestamp = может отсутствовать

- SACK = разрешён

```

Разница видна сразу.

Пример кода — как проверить свой MTU

```bash

Linux

ip link show | grep mtu

Или

ping -M do -s 1472 google.com

```

Если пакет не проходит — MTU меньше 1500.

```bash

Проверка TCP Window Scale

Потребуется tcpdump

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

```

Смотри на опцию `wscale`. Норма — 6-8.

Python-скрипт для анализа

```python

from scapy.all import *

def analyze_syn(packet):

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

mss = None

wscale = None

for opt in packet[TCP].options:

if opt[0] == 'MSS':

mss = opt[1]

if opt[0] == 'WScale':

wscale = opt[1]

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

print(f"MSS: {mss}")

print(f"Window Scale: {wscale}")

sniff(filter="tcp", prn=analyze_syn, count=10)

```

Запускай на своём сервере. Смотри, что приходит от разных клиентов.

Реальные кейсы из практики

**Кейс 1.** Банк. Клиент из Москвы, IP нидерландский. MTU 1420, Window Scale 4. Антифрод заблокировал. Клиент использовал OpenVPN на дешёвом VPS. Прокси-сервер не настраивал MTU.

**Кейс 2.** Торговая площадка. Продавец из Украины, IP немецкий. MTU 1500, Window Scale 8. Но User-Agent — iOS Safari. iOS не использует Window Scale 8. Там 6. Несоответствие. Блокировка.

**Кейс 3.** Сервис знакомств. Клиент через прокси. Всё совпадает — MTU 1500, Window Scale 8. Но TCP Timestamp отсутствует. Windows 10 всегда шлёт Timestamp. Linux — иногда нет. Подозрение.

Как обходить — базовые методы

Правильная настройка прокси.

```bash

Linux: принудительно установить MSS

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --set-mss 1460

```

Это заставит все пакеты через прокси иметь MSS 1460 (MTU 1500).

```bash

Изменение Window Scale

echo 7 > /proc/sys/net/ipv4/tcp_window_scaling

Не во всех ядрах работает

```

Сложнее с Window Scale. Менять его на уровне системы — костыль. Лучше использовать прокси, которые умеют подменять TCP-опции.

Продвинутые техники обхода

Некоторые антифрод-системы смотрят не только на конкретные значения, но и на их стабильность. Если ты меняешь MTU и Window Scale динамически — это тоже подозрительно.

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

- MTU 1500

- Window Scale 7 (Linux) или 8 (Windows)

- TCP Timestamp всегда включён

- SACK разрешён

Но даже так — если антифрод видит, что у тебя 1000 пользователей с одинаковыми TCP-параметрами, это red flag.

Что делает lexic.ml

Сервис прокси с 2015 года. IPv6 прокси. Настраивает TCP-стек под каждого клиента. MTU и Window Scale выставляются в соответствии с ОС клиента. Не тупо копируют значения, а эмулируют поведение реального пользователя.

Таблица сравнения

| Параметр | Типичный пользователь | Плохой прокси | Хороший прокси |

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

| MTU | 1500 | 1420-1450 | 1500 |

| Window Scale | 6-8 | 4-5 | 6-8 |

| Timestamp | Всегда | Иногда | Всегда |

| SACK | Разрешён | Может быть запрещён | Разрешён |

| TTL | 64-128 | 64-128 | Корректируется |

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

Антифрод-системы становятся умнее. Они не просто смотрят на IP. Они анализируют весь стек. TCP-параметры — один из слоёв. Если ты используешь прокси, но не контролируешь эти параметры — ты оставляешь след.

Один неверный параметр — и система помечает тебя как подозрительного. Не блокирует сразу. Но добавляет в "серый список". Дальше — больше проверок.

Вывод

MTU и TCP Window Scaling — не единственные параметры. Есть ещё TTL, TCP Timestamp, SACK, размер окна в данных. Но они — база. Если прокси не умеет их правильно выставлять — антифрод увидит несоответствие.

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