Как антифрод-системы вычисляют прокси по анализу TCP/IP стека (TTL, Window Scale, MSS)

Как антифрод видит прокси: анатомия TCP/IP

Прокси — это не про IP, а про пакеты. Антифрод смотрит глубже, чем просто адрес. Он анализирует то, что обычный пользователь никогда не замечает: TTL, Window Scale, MSS, и прочие параметры TCP-рукопожатия. Это fingerprinting на уровне стека. И он работает.

Каждая операционная система, каждое ядро отправляет TCP-пакеты с уникальными значениями. Прокси-сервер на Debian 11 будет выглядеть иначе, чем Windows 11 с браузером Chrome. Разница — в деталях.

TTL: первый звоночек

Time To Live — поле в IP-заголовке, которое показывает, сколько хопов прошел пакет. Каждый маршрутизатор уменьшает его на 1. Стартовые значения жестко привязаны к ОС:

- Linux: 64

- Windows: 128

- Cisco: 255

- macOS: 64

Проблема: когда пользователь сидит за прокси, сервер видит TTL самого прокси, а не клиента. Если у вас Windows, а TTL на сервере прилетает 64 — это прокси. Классический пример: человек заходит с домашнего ПК, TTL 128. Через прокси — TTL 64. Разница очевидна.

Прокси-провайдеры пытаются подделывать TTL. Например, iptables может перезаписывать TTL на 128. Но это полумера — антифрод смотрит не только на него.

```

Пример: как выглядит TTL в pcap

tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0' -c 1 -X

```

В выводе увидите поле TTL. Если оно отличается от ожидаемого для ОС пользователя — красный флаг.

Window Scale: скользкая тема

Window Scale — параметр TCP-опций, который определяет размер окна перегрузки. Он передается только в SYN-пакетах. Значение зависит от буфера сокета в ядре ОС.

- Linux (новые ядра): 7-9

- Windows 10/11: 8

- macOS: 5-6

- Android: 7-8

Прокси-серверы часто используют дефолтные настройки ядра. Если на сервере Debian с ядром 5.10, Window Scale будет 7. Если клиент с Windows 11 (WS 8) — прокси выдает себя. Антифрод сравнивает Window Scale с ожидаемым профилем.

Пример: реальный кейс из практики. Пользователь сидит за прокси на Ubuntu 20.04. Антифрод видит TTL 64, Window Scale 7, MSS 1460. Профиль пользователя — Windows 10. Несовпадение по двум параметрам — блокировка.

MSS: максимальный размер сегмента

MSS — параметр, который ограничивает размер данных в TCP-сегменте. Зависит от MTU интерфейса. Типичные значения:

- Ethernet (1500 MTU): MSS 1460

- PPPoE (1492 MTU): MSS 1452

- VPN (1400 MTU): MSS 1360

- IPv6 over IPv4 (1280 MTU): MSS 1220

Прокси зачастую работают на серверах с Ethernet-подключением. MSS будет 1460. Если клиент использует PPPoE (домашний ADSL), его MSS — 1452. Разница в 8 байт — достаточная для детекта.

Прокси-провайдеры могут менять MSS через iptables. Но это добавляет latency и фрагментацию пакетов. Побочка хреновая.

TCP Timestamp: часы на сервере

Опция TCP Timestamp — метка времени в каждом пакете. Она позволяет определить uptime системы и часовой пояс. Прокси-серверы часто имеют uptime в сотни дней. Клиентские машины перезагружаются раз в неделю.

Формула расчета: timestamp = (uptime_seconds * 1000) & 0xFFFFFFFF. Если вычислить разницу между первым и вторым пакетом — можно оценить uptime. 30 дней vs 300 дней — разница очевидна.

Пример: антифрод собирает TCP Timestamp из SYN-пакета. Если значение > 100 миллионов (примерно 30 дней uptime) — это сервер, а не клиент. Блокировка.

IP ID: счетчик пакетов

IP Identification — поле в IP-заголовке, которое увеличивается на 1 с каждым отправленным пакетом. Разные ОС используют разные стратегии:

- Linux: глобальный счетчик, инкремент на 1

- Windows: случайное начальное значение, инкремент на 1

- macOS: случайное значение каждый раз

Прокси-серверы часто используют Linux. Если антифрод видит последовательные IP ID (например, 1000, 1001, 1002) — это сервер. Клиентские машины с Windows генерируют случайные ID.

SYN-пакет: полная картина

В одном SYN-пакете антифрод анализирует комбинацию параметров:

| Параметр | Типичное значение Linux | Типичное значение Windows | Типичное значение macOS |

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

| TTL | 64 | 128 | 64 |

| MSS | 1460 | 1460 | 1460 |

| Window Scale | 7 | 8 | 5 |

| TCP Timestamp | uptime | uptime | uptime |

| SACK Permitted | да | да | да |

| IP ID | последовательный | случайный | случайный |

Если профиль не совпадает с ожидаемым — прокси.

Как прокси пытаются обойти

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

1. **Подмена TTL через iptables**: `iptables -t mangle -A POSTROUTING -j TTL --ttl-set 128`. Работает, но не меняет другие параметры.

2. **Изменение Window Scale через sysctl**: `sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'`. Меняет буфер, но не всегда точно.

3. **Прокси на Windows**: запуск прокси на Windows Server. TTL будет 128, Window Scale 8. Но IP ID останется последовательным, а uptime — высоким.

4. **Сложные цепочки**: прокси-сервер на Linux + VPN на Windows. TTL клиента сохраняется, но Window Scale и Timestamp — от прокси.

Проблема: идеального обхода нет. Антифрод анализирует десятки параметров. Изменить все — невозможно без глубокой модификации ядра.

Реальный кейс: прокси на lexic.ml

Пример: сервис lexic.ml использует IPv6 прокси с 2015 года. Они столкнулись с проблемой: антифрод блокировал их прокси из-за несоответствия профиля. Решение — настройка параметров TCP/IP на серверах:

- TTL: 128 (через iptables)

- Window Scale: 8 (через sysctl)

- TCP Timestamp: сброс при каждом новом соединении

Но даже это не панацея. Антифрод смотрит на корреляцию параметров. Если TTL 128, а IP ID последовательный — это все равно сервер. Нужно менять и IP ID, и Timestamp.

Кейс: банк блокирует через TCP fingerprint

Банк использовал систему на основе p0f — пассивного анализа TCP/IP стека. Пользователь с Windows 10 (TTL 128, WS 8, MSS 1460) заходил через прокси на Debian (TTL 64, WS 7, MSS 1460). Разница в TTL и WS — блокировка.

Попытка обойти через подмену TTL не помогла. Банк анализировал корреляцию TTL и Window Scale. Если TTL 64, а WS 8 — это не Windows. Прокси пойман.

Решение: поднять прокси на Windows Server 2019. TTL 128, WS 8, MSS 1460, IP ID случайный. Но uptime — 200 дней. Банк увидел TCP Timestamp > 100 млн — блокировка.

Кейс: e-commerce видит прокси по MTU

Магазин анализировал MSS. Большинство пользователей — PPPoE (MSS 1452). Прокси на сервере с Ethernet (MSS 1460). Разница в 8 байт.

Прокси-провайдер настроил MSS clamping через iptables: `iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu`. MSS стал 1452. Но магазин посмотрел на Window Scale — остался 7. Профиль не совпал.

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

Современные системы используют машинное обучение. Они собирают fingerprint каждого пользователя: TTL, WS, MSS, Timestamp, IP ID, SACK, и еще 20+ параметров. Строят профиль. Если новый запрос отличается от профиля — это прокси.

Пример: пользователь всегда заходил с TTL 128, WS 8, MSS 1452, IP ID случайный. Вдруг — TTL 64, WS 7, MSS 1460, IP ID последовательный. Модель детектит аномалию.

Обойти ML-антифрод практически невозможно. Нужно копировать весь профиль, включая uptime и IP ID. Это требует прокси на той же ОС, с теми же настройками, и сбросом Timestamp при каждом соединении.

Что делать прокси-провайдерам

1. **Использовать ту же ОС, что и клиенты**. Если большинство пользователей на Windows — поднимайте прокси на Windows Server.

2. **Настраивать параметры TCP/IP под конкретный профиль**. TTL, Window Scale, MSS — все должно совпадать.

3. **Сбрасывать TCP Timestamp при каждом соединении**. Через sysctl или модуль ядра.

4. **Менять IP ID на случайный**. Через iptables или eBPF.

5. **Использовать IPv6**. Многие антифрод-системы слабее анализируют IPv6-трафик.

Но даже это не гарантия. Антифрод становится умнее. Прокси-война — это бесконечная гонка вооружений.