Как антифрод-системы детектят прокси по MTU и TCP Window Size

Как антифрод-системы детектят прокси по MTU и TCP Window Size

Прокси-серверы — зло для антифрода. Но они же — хлеб для тех, кто обходит блокировки. Годами шла война: антифрод учился отличать реального пользователя от прокси по IP, User-Agent, таймингам. Потом прокси научились подделывать заголовки. Теперь антифрод копает глубже — на уровень TCP/IP стека.

MTU и TCP Window Size — два параметра, которые выдают прокси с головой. Разберём, как это работает, почему это сложно обойти и что с этим делать.

Почему MTU важен для детекта

MTU (Maximum Transmission Unit) — максимальный размер пакета, который может передать сетевое устройство. Для Ethernet это 1500 байт. Но многие прокси-серверы настраивают MTU по-своему: 1400, 1450, 1480.

Антифрод смотрит: если MTU клиента отличается от стандартного 1500 — это подозрительно. Особенно если MTU меньше 1400. Такое бывает только при туннелировании трафика через VPN или прокси.

Реальный кейс: пользователь сидит за прокси с MTU 1400. Антифрод видит пакеты размером 1400 байт. Нормальные пользователи так не шлют. Блок.

Проверить MTU на своей стороне:

```bash

ping -M do -s 1472 google.com

```

Если пакет не проходит — MTU меньше 1500. Прокси-серверы часто режут MTU для оптимизации.

TCP Window Size — скрытый отпечаток

TCP Window Size — размер окна перегрузки. Определяет, сколько данных можно отправить без подтверждения. Каждая ОС выставляет свой дефолтный window size. Windows — 65535, Linux — 29200, macOS — 65535, но с нюансами.

Прокси-серверы часто не меняют window size своего ядра. Получается: клиент шлёт запрос с window size 65535 (Windows), а прокси отвечает с window size 29200 (Linux). Антифрод видит несоответствие.

Таблица дефолтных TCP Window Size:

| ОС | Default Window Size | Примечание |

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

| Windows 10/11 | 65535 | Может меняться при автонастройке |

| Linux (ядро 5.x) | 29200 | Зависит от дистрибутива |

| macOS | 65535 | Аналогично Windows |

| Android | 65535 | Но часто режется провайдером |

| iOS | 65535 | Стабильно |

Если антифрод видит window size 29200, а User-Agent — Chrome на Windows — это стопроцентный прокси.

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

Схема простая. При TCP-рукопожатии клиент и сервер обмениваются SYN пакетами. В них — MTU и window size. Антифрод-система перехватывает эти пакеты на уровне ядра или через DPI.

Дальше — анализ. Если параметры не совпадают с ожидаемыми для данного устройства — флаг.

Пример детекта на Python (упрощённо):

```python

import scapy.all as scapy

def detect_proxy(packet):

if packet.haslayer(scapy.TCP):

window = packet[scapy.TCP].window

mtu = packet[scapy.IP].len

if window == 29200 and mtu < 1500:

print("Прокси детектед!")

```

На практике антифроды используют более сложные алгоритмы. Но суть та же.

Почему это сложно обойти

Проблема в том, что MTU и window size — параметры ядра ОС. Просто так их не поменять в браузере. Нужно лезть в настройки сети.

Для Linux:

```bash

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

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

```

Для Windows — через реестр:

```

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TcpWindowSize = 65535

```

Но даже после этого антифрод может смотреть на другие параметры TCP-стека: TTL, MSS, опции SACK и т.д.

Реальные кейсы блокировок

Кейс 1. Пользователь купил дешёвый прокси на DigitalOcean. MTU там 1400. Антифрод банка сразу заблокировал операцию. Пользователь не мог войти в личный кабинет.

Кейс 2. Сервис стриминга заметил, что 30% трафика идёт с window size 29200, хотя User-Agent — Chrome на Windows. Оказалось, это прокси на Linux. Заблокировали всех.

Кейс 3. Прокси-провайдер lexic.ml настраивает MTU и window size под клиента. Но даже так — антифроды учатся быстрее.

Что делают прокси-провайдеры

Пытаются подделывать параметры. На прокси-серверах ставят iptables правила для изменения MSS (Maximum Segment Size). Меняют window size через sysctl.

Но это палка о двух концах. Чем больше подделок — тем сложнее поддерживать стабильность. Прокси начинает тормозить, рвать соединения.

Как антифроды улучшают детект

Современные антифроды не просто смотрят на MTU и window size. Они анализируют паттерны:

- Изменение window size во время сессии

- Соотношение window size и задержки

- Наличие TCP-опций (SACK, Timestamps)

- TTL (Time To Live) — если TTL меньше 64, это почти наверняка прокси

Таблица TTL для разных ОС:

| ОС | Default TTL |

|---|---|

| Windows | 128 |

| Linux | 64 |

| macOS | 64 |

| Android | 64 |

| iOS | 64 |

Если TTL 64, а User-Agent — Windows — прокси.

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

Для тех, кто обходит блокировки:

1. Выбирай прокси с настройкой MTU под 1500

2. Проверяй window size — он должен совпадать с твоей ОС

3. Используй прокси с TTL не менее 64

4. Не экономь на качестве — дешёвые прокси сливают параметры ядра

Для тех, кто защищается:

1. Собирай статистику по MTU и window size для разных устройств

2. Добавь проверку TTL

3. Анализируй паттерны изменения window size

4. Используй машинное обучение для выявления аномалий

Будущее детекта

Антифрод-системы эволюционируют. Уже сейчас некоторые банки анализируют TCP-стек на уровне ядра. В будущем — детект по микро-задержкам, jitter, паттернам TCP-рекордов.

Прокси-провайдерам придётся либо полностью эмулировать TCP-стек клиента, либо искать новые пути. Война продолжается.

Итог

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

Если ты используешь прокси — проверь свои параметры. Если защищаешься — добавь эти проверки в систему. И помни: идеальных прокси не бывает. Бывают только те, которые антифрод пока не научился ловить.