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

TCP fingerprint — что это и почему это работает

Каждое устройство в интернете оставляет цифровые отпечатки. TCP/IP стек — не исключение. Разные ОС, разные версии ядер, разные билды — всё это влияет на то, как формируются TCP-пакеты.

Антифрод-системы смотрят не только на IP и заголовки HTTP. Они анализируют поведение на транспортном уровне. Параметры вроде initial TTL, window size, MSS, TCP options — комбинация этих значений уникальна для каждого стека.

Вот типичный fingerprint от реального пользователя:

```

TTL: 64

Window size: 65535

MSS: 1460

TCP options: MSS, NOP, WS, NOP, NOP, TS, SACK

```

А вот что выдаёт стандартный OpenVPN-сервер на Ubuntu:

```

TTL: 128

Window size: 65535

MSS: 1460

TCP options: MSS, NOP, WS, NOP, NOP, TS, SACK

```

Разница в TTL — 64 против 128. Казалось бы, мелочь. Но для антифрода это красный флаг.

Как антифрод собирает fingerprint

**Пассивное сканирование.** Система просто слушает трафик. Ей не нужно ничего отправлять — достаточно проанализировать SYN-пакеты от клиента. Каждый SYN-пакет содержит всю нужную информацию.

**Активное зондирование.** Иногда антифрод сам шлёт пакеты клиенту и смотрит на ответ. Например, отправляет ACK-пакет и анализирует RST-ответ. Разные стеки реагируют по-разному.

**Базы fingerprint.** Есть готовые базы вроде p0f, которые содержат тысячи отпечатков. Антифрод сравнивает fingerprint клиента с известными шаблонами. Если fingerprint совпадает с типичным прокси-сервером — стоп.

Реальные данные из production: fingerprint OpenVPN на Debian 10 даёт 100% совпадение для 80% пользователей через этот сервис. Антифрод видит: "О, это же стандартный OpenVPN". Бан.

Почему стандартные прокси светятся

Большинство VPS-провайдеров используют дефолтные образы ОС. Ubuntu, Debian, CentOS — всё одинаковое. TCP fingerprint у таких серверов идентичен.

Проблема усугубляется, когда сотни прокси крутятся на одном железе через виртуализацию. Даже если гипервизор разный, TCP-стек гостевой системы остаётся стандартным.

Ещё один момент — время жизни TTL. Реальные пользователи обычно имеют TTL 64 (Linux, macOS) или 128 (Windows). Прокси часто выдают TTL 64, но это не спасает — антифрод смотрит на всю комбинацию параметров.

Как антифрод отличает прокси от реального пользователя

**Размер окна.** Реальные пользователи редко имеют window size 65535. Чаще встречаются 8192, 16384, 29200. Прокси часто используют максимальное значение.

**TCP options.** Порядок опций в пакете — это как отпечаток пальца. Linux и Windows располагают опции по-разному. Прокси на Linux выдают строго определённую последовательность.

**Timestamp.** Многие прокси включают TCP timestamps. Реальные пользователи часто отключают их для экономии трафика. Антифрод видит timestamp — подозревает прокси.

**MSS.** Максимальный размер сегмента. Для Ethernet это 1460. Но для PPPoE или VPN-туннелей MSS может быть меньше. Прокси через туннели часто имеют MSS 1400-1450.

Обход через модификацию TCP стека

Можно переписать параметры TCP/IP на уровне ядра. Linux позволяет менять всё через sysctl:

```bash

Изменяем TTL

sysctl -w net.ipv4.ip_default_ttl=128

Изменяем window size

sysctl -w net.core.rmem_default=262144

sysctl -w net.core.wmem_default=262144

Отключаем timestamps

sysctl -w net.ipv4.tcp_timestamps=0

```

Но это грубый метод. Антифрод смотрит на комбинацию. Если вы просто поменяли TTL на 128, но остальные параметры остались дефолтными — fingerprint всё равно будет отличаться от реального Windows.

Правильный подход — эмулировать конкретную ОС. Например, сделать fingerprint как у Windows 10:

```bash

TTL как у Windows

sysctl -w net.ipv4.ip_default_ttl=128

Window size как у Windows

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

sysctl -w net.ipv4.tcp_wmem='4096 65536 6291456'

Отключаем SACK (Windows 10 часто не использует)

sysctl -w net.ipv4.tcp_sack=0

Включаем window scaling

sysctl -w net.ipv4.tcp_window_scaling=1

```

Но это всё равно не идеально. Реальные fingerprint Windows содержат ещё кучу нюансов — конкретные значения WS, порядок опций, наличие определённых комбинаций.

Продвинутые методы: iptables и nftables

Можно перехватывать и модифицировать TCP-пакеты на лету. iptables с модулем `TCPOPTSTRIP` позволяет удалять ненужные опции:

```bash

Удаляем timestamp из SYN-пакетов

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN SYN -j TCPOPTSTRIP --strip-options timestamp

```

Но это не меняет значения — только удаляет. Для изменения параметров нужен `nftables` с `mangle`:

```bash

nft add rule ip mangle POSTROUTING tcp flags syn tcp option maxseg size set 1460

nft add rule ip mangle POSTROUTING tcp flags syn tcp option window set 65535

```

Проблема в том, что nftables не умеет менять TTL напрямую. Для TTL нужен отдельный хак:

```bash

Меняем TTL через nftables

nft add rule ip mangle POSTROUTING ip ttl set 128

```

Комбинация nftables + sysctl даёт неплохой результат. Но антифроды тоже не стоят на месте.

Эмуляция конкретных ОС

Самый надёжный способ — использовать готовые инструменты для эмуляции TCP fingerprint. Например, `Scapy` позволяет формировать пакеты с произвольными параметрами:

```python

from scapy.all import *

Создаём SYN-пакет как у Windows 10

ip = IP(src='10.0.0.1', dst='8.8.8.8', ttl=128)

tcp = TCP(sport=12345, dport=443, flags='S',

window=65535, options=[('MSS', 1460),

('NOP', None),

('WScale', 8),

('NOP', None),

('NOP', None),

('SACKOK', None),

('Timestamp', (12345, 0))])

send(ip/tcp)

```

Но это для ручного тестирования. В production так не поработаешь — слишком медленно.

Для реального обхода используют модифицированные версии OpenVPN или WireGuard, которые подменяют fingerprint на уровне туннеля. Например, `go-tcpcopy` — утилита, которая перехватывает TCP-соединения и форвардит их с изменёнными параметрами.

Реальный кейс: обход антифрода в банковском приложении

Была задача — обойти антифрод в крупном российском банке. Стандартный OpenVPN на Debian 10 с fingerprint как у Linux — бан через 5 минут.

Решение:

1. Подняли WireGuard на FreeBSD (fingerprint отличается от Linux)

2. Настроили nftables для подмены TTL на 128

3. Отключили TCP timestamps

4. Установили window size 8192 (как у типичного Windows-пользователя)

5. Добавили случайную задержку в SYN-пакеты (jitter)

Результат: антифрод перестал детектить прокси. Fingerprint стал выглядеть как Windows 10 с PPPoE-подключением.

Но через месяц банк обновил антифрод — начали проверять ещё и порядок TCP options. Пришлось подстраиваться заново.

Почему это гонка вооружений

Антифрод-системы постоянно эволюционируют. Они уже не просто смотрят на базовые параметры — анализируют корреляции между разными метриками.

Например, если TTL=128, а window size=65535 — это подозрительно. Реальные Windows-пользователи с TTL=128 почти никогда не имеют window size 65535. Это комбинация из Linux-мира.

Или если MSS=1460, но при этом отсутствует SACK — странно. Linux почти всегда использует SACK. А вот некоторые старые версии Windows — нет.

Антифрод строит вероятностные модели. Чем больше аномалий — тем выше шанс, что это прокси.

Практические советы

**Не используйте дефолтные образы.** Установите ОС вручную, настройте TCP-стек под конкретную задачу.

**Эмулируйте конкретную версию ОС.** Не просто "Windows", а "Windows 10 build 19045". Чем точнее — тем лучше.

**Добавляйте случайность.** Фиксированный fingerprint — это красный флаг. Немного джиттера в TTL, случайный window size в разумных пределах.

**Используйте разные ОС для разных прокси.** Если у вас 100 прокси и все с fingerprint Ubuntu 20.04 — антифрод это быстро заметит.

**Тестируйте.** Есть сервисы вроде `tcpfingerprint.com`, которые показывают, как выглядит ваш fingerprint. Проверяйте до того, как антифрод вас забанит.

**Мониторьте изменения.** Антифроды обновляются. То, что работало вчера, может не работать сегодня.

Будущее TCP fingerprinting

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

Есть техника "TCP side-channel" — анализ микрофлуктуаций времени обработки пакетов. Разные стеки обрабатывают пакеты с разной скоростью. Это сложно подделать.

Но и обходные пути развиваются. Появляются прокси с полной эмуляцией TCP-стека целевой ОС. Не просто подмена параметров, а полное копирование поведения.

Для тех, кто хочет разобраться глубже — на lexic.ml есть подробная документация по настройке TCP-стека для разных сценариев. Там же можно найти готовые конфиги для эмуляции Windows, macOS и Android.

Помните: идеальной защиты не существует. Но сделать свой прокси максимально похожим на реального пользователя — вполне реально. Вопрос времени и ресурсов.