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

TCP fingerprint: как антифрод видит прокси насквозь

TCP fingerprint — это цифровой отпечаток стека протоколов. Каждая ОС собирает TCP-пакеты по-своему: разные дефолтные размеры окон, тайминги, порядок опций. Даже два одинаковых Linux-сервера с разными ядрами дадут разные отпечатки.

Антифрод-системы давно не смотрят только на IP. Они собирают пассивные метрики из SYN-пакетов и сравнивают с эталонами. Для прокси это приговор: если ваш сервер отдаёт fingerprint Linux, а клиент сидит на Windows — всё, палево.

Как формируется отпечаток

При установке TCP-соединения клиент шлёт SYN-пакет. В нём — поля:

- Window size (размер окна приёма)

- MSS (Maximum Segment Size)

- Опции: SACK, Timestamps, Window Scale, WSopt

- Порядок следования опций

- TTL (Time To Live)

Всё это вместе даёт уникальную сигнатуру. У Windows 10 и Ubuntu 22.04 она отличается радикально. У macOS — третья. Антифрод собирает базу таких сигнатур и сверяет каждый новый коннект.

Пассивный fingerprinting

Самый простой метод — p0f. Он слушает трафик и классифицирует ОС по SYN-пакетам. Работает на уровне ядра, без активных зондов. Точность на дистанции — 70-80%, но для скоринга хватает.

Вот как выглядит типичный SYN от Linux:

```

Linux: window=64240, MSS=1460, SACK=OK, TSval=random, TSecr=0, WS=7

```

А это Windows 11:

```

Windows: window=65535, MSS=1460, SACK=OK, TSval=random, TSecr=0, WS=256

```

Разница в WS (Window Scale) — 7 против 256. Плюс порядок опций. Этого достаточно, чтобы разделить 80% трафика.

Активный fingerprinting

Тут антифрод сам шлёт пакеты: FIN, SYN-ACK, пустые ACK. Смотрит, как стек отвечает на аномалии. Например, на FIN в несуществующем соединении. Или на ACK с неверным номером последовательности. Реакции разные у разных ОС.

Пример: тайм-аут на SYN-ACK. Linux пересылает SYN-ACK до 5 раз с интервалом 1, 2, 4, 8, 16 секунд. Windows — 3 раза с интервалом 3, 6, 12. Если скрипт посчитает ретрансмиссии — получит точную ОС.

Антифрод-стеки в бою

Крупные банки и платёжки используют связку: пассивный fingerprint + анализ поведения + скоринг IP. Если ваш прокси даёт Linux-fingerprint, а в User-Agent стоит Chrome на Windows — это минус 30-50 баллов к репутации.

Пример из практики: сервис доставки еды. Пользователь с прокси на базе CentOS 7 заходит с iPhone. Fingerprint — Linux, TTL 64, окно 29200. Антифрод ставит флаг "несоответствие среды". Если при этом ещё и гео-координаты прыгают — блок.

Как прокси маскируют fingerprint

Есть два пути: менять ядро или проксировать на уровне приложений.

Первый — патчить стек. Например, на Linux можно подменить Window Scale через sysctl:

```bash

sysctl -w net.ipv4.tcp_window_scaling=1

sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'

```

Но это влияет на все соединения, и не всегда помогает — порядок опций всё равно остаётся Linux-специфичным.

Второй — использовать прокси, которые сами собирают TCP-сессии и пересобирают пакеты. Такие решения есть у крупных CDN. Они принимают соединение от клиента, убивают его и создают новое к серверу. Fingerprint клиента теряется, остаётся только fingerprint самого прокси.

Реальный кейс: e-commerce платформа

Магазин электроники. Антифрод на базе ThreatMetrix. Прокси-ферма на Ubuntu 20.04. Клиенты с Windows-машин. Система за 2 недели вычислила 90% прокси-трафика. Причина: TCP fingerprint не совпадал с User-Agent, плюс TTL 64 вместо 128 у Windows.

Решение: перешли на прокси с маскировкой TCP-стека. Использовали решение, которое форсит Window Scale 256 и подменяет порядок опций. Конверсия выросла на 15%, блокировки упали в 4 раза.

Что ещё смотрит антифрод

Один fingerprint — мало. Системы собирают комплекс:

- TTL и его стабильность

- Вариации window size в течение сессии

- Timestamps: есть ли, как меняются

- ECN (Explicit Congestion Notification) — поддержка и поведение

- MTU discovery

Вот таблица типичных значений:

| ОС | TTL | Window Scale | MSS | SACK |

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

| Windows 10 | 128 | 256 | 1460 | да |

| Windows 11 | 128 | 256 | 1460 | да |

| Ubuntu 22.04 | 64 | 7 | 1460 | да |

| macOS Monterey | 64 | 3 | 1460 | да |

| Android 13 | 64 | 8 | 1460 | да |

Разница в TTL и WS видна невооружённым глазом. Если прокси отдаёт TTL 64, а клиент сидит на Windows — сразу флаг.

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

Напишите простой скрипт на Python, который делает SYN-пакет и смотрит ответ:

```python

import socket

import struct

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.settimeout(3)

s.connect(('8.8.8.8', 80))

print(s.getsockopt(socket.IPPROTO_TCP, socket.TCP_INFO))

s.close()

```

Это даст базовую информацию. Для полного fingerprint используйте p0f или pyfingerprint.

Грабли с IPv6

IPv6 добавляет головной боли. Там нет NAT, и каждый клиент имеет уникальный адрес. Но fingerprint работает так же. Плюс появляются новые поля: Flow Label, Hop Limit, расширенные заголовки.

Прокси на IPv6 часто забывают про Hop Limit. У Linux — 64, у Windows — 128. Если прокси не меняет Hop Limit, а клиент на Windows — палево.

Как защититься

Первый уровень — выбирать прокси, которые маскируют TCP-стек. Второй — гонять трафик через цепочку: клиент → прокси → VPN → целевой сайт. VPN пересобирает TCP-сессию, и fingerprint клиента теряется.

Третий уровень — использовать протоколы, которые не дают точного fingerprint. QUIC (HTTP/3) шифрует большую часть полей. Антифрод видит только тип пакета и размер. Но QUIC сам по себе — маркер прокси, если сайт его не поддерживает.

Итог

TCP fingerprint — это не приговор, но серьёзный фильтр. Антифрод-системы комбинируют его с поведенческим анализом, и если вы проксируете трафик, рано или поздно вас вычислят. Решение — маскировка на уровне ядра или протокола. Для IPv6 это особенно критично, потому что там меньше анонимности по умолчанию.

Прокси с маскировкой TCP-стека — это не роскошь, а необходимость. Если ваш сервис работает с платёжками или e-commerce, без этого никак.