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

TCP/IP стек как отпечаток пальца

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

Например, Windows 10 по умолчанию отправляет пакеты с TTL=128, Linux — 64, macOS — 64, но с другими настройками окна перегрузки. Прокси-серверы часто работают на Linux, и если ваш клиент якобы сидит на Windows, но TTL прилетает 64 — это подозрительно.

Вот как выглядит захват TTL через scapy:

```python

from scapy.all import *

def analyze_ttl(packet):

if IP in packet:

return packet[IP].ttl

Запускаем сниффер на 10 пакетов

pkts = sniff(count=10, filter="tcp")

ttls = [analyze_ttl(p) for p in pkts if p.haslayer(IP)]

print(f"TTL values: {set(ttls)}")

```

Система собирает статистику. Если все пакеты идут с TTL=64, а пользователь утверждает, что он из Нью-Йорка на Windows — стоп-сигнал.

Время отклика и RTT манипуляции

Задержки — классический маркер прокси. Человек в Москве подключается к серверу в Москве через прокси в Амстердаме — RTT скачет до 50-80 мс вместо 5-10 мс. Но это слишком просто. Умные антифроды смотрят на стабильность задержек.

Реальный пользователь имеет вариативность RTT: то 12 мс, то 15 мс, то 11 мс. Прокси даёт более ровные значения — плюс-минус 1-2 мс. Причина: трафик идёт через фиксированный канал с минимальным джиттером.

Пример замера RTT через bash:

```bash

ping -c 10 -i 0.1 target-server.com | tail -1 | awk '{print \\$4}' | cut -d'/' -f2

```

Если среднее RTT = 45.2 мс, а все значения 44-46 мс — это подозрительно ровно. Человек через мобильный интернет даст разброс 20-30%.

Window scaling и MSS

Параметры TCP window scaling и MSS (Maximum Segment Size) — ещё один слой проверки. Разные ОС выставляют разные значения. Linux часто использует window scale factor 7 (128 KiB), Windows — 8 (256 KiB). Прокси-серверы на дефолтных настройках могут выдать несоответствие.

MSS тоже различается: Ethernet обычно 1460 байт, PPPoE — 1452, VPN-туннели — 1400-1440. Если пользователь сидит через мобильный оператор, MSS будет меньше из-за дополнительных заголовков. Прокси же часто использует стандартный Ethernet MTU.

Проверить MSS можно через tcpdump:

```bash

tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' -c 5 | grep -oP 'mss \K\d+'

```

Разные MSS в одной сессии — признак туннелирования.

IP ID и фрагментация

Поле Identification в IP-пакетах — недооценённый маркер. Реальные ОС генерируют ID последовательно или случайно, но с определённым паттерном. Прокси-серверы часто переиспользуют ID или генерируют их слишком предсказуемо.

Особенно это заметно при фрагментации. Если пакет фрагментирован, ID должен совпадать у всех фрагментов. Прокси иногда косячат — разные ID у фрагментов одного пакета.

Пример кода для анализа IP ID:

```python

from scapy.all import *

def check_ip_id(packet):

if IP in packet and packet[IP].flags & 0x1: # More fragments flag

return packet[IP].id

pkts = sniff(count=100, filter="ip")

ids = [check_ip_id(p) for p in pkts if check_ip_id(p)]

print(f"Fragment IDs: {ids[:10]}")

```

Если ID не уникальны или повторяются слишком часто — прокси.

TCP timestamps

Опция TCP timestamps — мощный инструмент. Она содержит два значения: TSval (отправитель) и TSecr (получатель). Антифрод смотрит на разницу между ними. Если она слишком мала или слишком постоянна — это прокси.

Реальный пользователь имеет TSval, растущий с реальной скоростью времени. Прокси может использовать виртуальные timestamps, которые растут слишком медленно или скачками.

Захват timestamps через tcpdump:

```bash

tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' -c 1 -X | grep -A1 "Timestamp"

```

Если видите TSval = 1234567890, а через 10 секунд TSval = 1234567895 — прирост 5 за 10 секунд. Реальные часы тикают быстрее.

HTTP заголовки и User-Agent

Прокси часто подменяют User-Agent, но забывают про другие заголовки. Accept-Language, Accept-Encoding, Sec-CH-UA — всё это должно соответствовать реальному браузеру. Прокси-серверы на Python requests или curl выдают характерные наборы заголовков.

Пример: curl по умолчанию отправляет `User-Agent: curl/8.0`. Если антифрод видит такой заголовок от мобильного приложения — это прокси. Даже если User-Agent подменён, остальные заголовки выдадут подделку.

Сравнение заголовков реального браузера и прокси:

| Заголовок | Реальный Chrome | Python requests |

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

| User-Agent | Mozilla/5.0 ... Chrome/120 | python-requests/2.28 |

| Accept-Encoding | gzip, deflate, br | gzip, deflate |

| Sec-CH-UA | "Chromium";v="120" | отсутствует |

| Upgrade-Insecure-Requests | 1 | отсутствует |

DNS-запросы и резолвинг

Прокси-серверы часто кэшируют DNS или используют свои резолверы. Реальный пользователь делает DNS-запросы к локальному DNS-серверу провайдера. Прокси отправляет запросы к публичным DNS (8.8.8.8, 1.1.1.1) или вообще не делает DNS — использует IP напрямую.

Антифрод отслеживает время DNS-резолвинга. Если запрос к `google.com` резолвится за 1 мс — это подозрительно. Реальная DNS-резолюция занимает 10-50 мс.

Мониторинг DNS через tcpdump:

```bash

tcpdump -i eth0 -nn port 53 -c 10 | grep -oP 'A\?\s+\K[^\s]+'

```

Если видите запросы к `google.com` с ответом за 2 мс — почти наверняка прокси с кэшем.

MTU и Path MTU Discovery

Path MTU Discovery — процесс определения максимального размера пакета до цели. Реальные пользователи проходят через разные сети с разным MTU. Прокси часто имеют фиксированный MTU на интерфейсе.

Если клиент из России подключается к серверу в США, PMTU должен быть меньше 1500 из-за трансатлантических каналов. Прокси же может показывать стабильный MTU 1500 — признак туннеля.

Проверка MTU через ping:

```bash

ping -M do -s 1472 -c 3 target-server.com

```

Если пакет проходит — MTU >= 1500. Если нет — меньше. Разные результаты для разных целей — нормально. Одинаковые — подозрительно.

Кейс: Определение прокси через комбинацию TTL и RTT

**Проблема:** Клиент из Москвы заходит на сайт банка. Система видит TTL=64 (Linux) и RTT=5 мс. Но пользователь утверждает, что сидит на Windows через мобильный интернет.

**Причина:** Прокси-сервер на Linux в том же дата-центре, что и банковский сервер. RTT низкий из-за близкого расположения. TTL выдает ОС прокси.

**Технические детали:** TTL=64, RTT стабильно 4.8-5.2 мс, window scale factor=7 (Linux), MSS=1460. Реальный Windows дал бы TTL=128, window scale=8, RTT с разбросом 10-30 мс.

**Решение:** Банк добавил проверку TTL + window scale. Если TTL=64 и window scale=7 — блокировка. Через неделю аномалии снизились на 40%.

Кейс: Выявление прокси по IP ID

**Проблема:** Пользователь из Германии заходит на онлайн-казино. Все параметры выглядят нормально: TTL=128, RTT=30 мс, User-Agent как у Safari. Но система отмечает подозрение.

**Причина:** Анализ IP ID показал, что все пакеты имеют последовательные ID, увеличивающиеся на 1. Реальный Safari генерирует случайные ID. Прокси использовал старый скрипт с простым счётчиком.

**Технические детали:** 1000 пакетов, ID от 1000 до 2000, шаг 1. Реальный браузер дал бы разброс от 0 до 65535 без паттерна.

**Решение:** Казино добавило проверку IP ID на случайность. Через месяц прокси-атаки снизились на 60%.

Кейс: Обход антифрода через манипуляцию TCP timestamps

**Проблема:** Прокси-сервис рекламирует "невидимость" для антифродов. Клиенты жалуются, что их всё равно блокируют.

**Причина:** Прокси подменял TTL и User-Agent, но забыл про TCP timestamps. Антифрод заметил, что TSval растёт линейно со скоростью 1 мс в секунду — слишком медленно для реального времени.

**Технические детали:** Реальный пользователь имеет прирост TSval ~1000 за секунду (1 тик = 1 мс). Прокси давал прирост 1-2 за секунду. Разница в 500 раз.

**Решение:** Прокси-сервис обновил софт, добавив синхронизацию timestamps с реальными часами. Блокировки снизились, но антифроды начали проверять другие параметры.

Практические рекомендации

Для защиты от прокси используйте комбинацию методов. Один параметр можно подделать, но все сразу — сложно. Собирайте TTL, RTT, window scale, MSS, IP ID, timestamps, DNS-время, HTTP-заголовки.

Настройте nginx для логирования этих параметров:

```nginx

log_format proxy_detect '\ - \ [\] '

'"\" \ \ '

'"\" "\" '

'ttl:\ rtt:\';

```

Анализируйте логи через ELK или custom скрипты. Если видите аномалии — блокируйте или отправляйте на дополнительную верификацию.

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