Как антифрод-системы детектируют прокси по MTU и RTT пакетов

Архитектура детекции на уровне сети

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

MTU и RTT — два параметра, которые выдают прокси с головой. Первый связан с фрагментацией пакетов, второй — с задержками. Комбинация этих метрик даёт точность детекции до 94-97% в современных системах.

Почему это работает? Потому что домашние пользователи сидят за NAT провайдера, а прокси — это серверы в дата-центрах. Разная физика передачи данных. Разные маршруты. Разные MTU на интерфейсах.

MTU как отпечаток пальца

MTU (Maximum Transmission Unit) — максимальный размер пакета, который может пройти через интерфейс без фрагментации. Для Ethernet это 1500 байт. Для PPPoE — 1492. Для VPN-туннелей — ещё меньше.

Вот как это работает. Когда клиент подключается к серверу, происходит Path MTU Discovery. Сервер отправляет пакет с флагом DF (Don't Fragment). Если пакет слишком большой для промежуточного узла, тот шлёт ICMP-сообщение "Fragmentation Needed". Сервер уменьшает размер и пробует снова.

Проблема прокси в том, что они добавляют дополнительные заголовки. GRE, IPIP, WireGuard — каждый протокол жрёт от 20 до 60 байт. Итоговый MTU клиента становится меньше стандартного.

```bash

Проверка MTU на интерфейсе

ip link show eth0 | grep mtu

Результат: mtu 1500 qdisc pfifo_fast state UP

Проверка MTU через ping с запретом фрагментации

ping -M do -s 1472 -c 3 google.com

-M do - запрет фрагментации

-s 1472 - размер полезных данных (1472 + 28 = 1500)

```

Если пакет с MTU 1500 не проходит, значит где-то на пути есть туннель или прокси. Антифрод это видит.

RTT и его аномалии

RTT (Round-Trip Time) — время туда-обратно. Домашний пользователь через оптоволокно получает 5-15 мс до ближайшего узла. Прокси добавляет минимум один дополнительный прыжок. Каждый прыжок — это 1-5 мс.

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

```python

import socket

import time

import statistics

def measure_rtt(host, port=80, count=10):

rtts = []

for _ in range(count):

start = time.time()

try:

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

sock.settimeout(2)

sock.connect((host, port))

end = time.time()

rtts.append((end - start) * 1000)

sock.close()

except:

pass

time.sleep(0.1)

if len(rtts) > 1:

variance = statistics.variance(rtts)

mean = statistics.mean(rtts)

return {

'mean_rtt': round(mean, 2),

'variance': round(variance, 2),

'std_dev': round(statistics.stdev(rtts), 2),

'min': round(min(rtts), 2),

'max': round(max(rtts), 2)

}

return None

Тест для разных типов соединений

print("Datacenter proxy:", measure_rtt("185.xxx.xxx.xxx"))

print("Home connection:", measure_rtt("192.xxx.xxx.xxx"))

```

На практике variance у прокси редко превышает 2-3 мс. У домашнего пользователя — 15-50 мс. Разница в 10 раз.

Комбинация MTU и RTT в реальных системах

По отдельности эти метрики слабы. MTU можно подкрутить на стороне клиента. RTT можно сгладить через буферизацию. Но вместе они дают синергетический эффект.

Антифрод строит профиль соединения. Собирает данные за первые 5-10 запросов. Строит двумерную карту: MTU по оси X, RTT variance по оси Y. Прокси ложатся в кластер с низким MTU (1400-1480) и низкой вариативностью RTT.

Пример архитектуры детекции:

```

Запрос клиента

↓

Сбор метрик: MTU, RTT, TTL, TCP window scale

↓

Нормализация данных (z-score, min-max)

↓

Кластеризация (DBSCAN или Isolation Forest)

↓

Проверка по правилам:

- MTU < 1450 AND RTT variance < 5ms → прокси

- MTU < 1420 AND RTT variance < 3ms → VPN

- MTU = 1500 AND RTT variance > 20ms → мобильный интернет

↓

Принятие решения (score от 0 до 100)

```

Кейс: Банк с MTU-детекцией на nginx

Проблема: клиенты через прокси получали отказ в авторизации. Жалобы сыпались в поддержку. Обычные методы (IP-репутация, User-Agent) не помогали.

Причина: антифрод смотрел на TCP MSS (Maximum Segment Size) в SYN-пакетах. MSS = MTU - 40 (TCP+IP заголовки). Если MSS меньше 1460, система считала соединение подозрительным.

Технические детали:

- nginx 1.24 с модулем ngx_http_core_module

- TCP MSS по умолчанию: 1460 для Ethernet

- Прокси на WireGuard: MSS = 1420 (MTU 1460 - 40)

- Лёгкие прокси на OpenVPN: MSS = 1300-1350

Решение: настройка nginx для проверки MSS на уровне ядра:

```nginx

В секции http или server

tcp_nodelay on;

proxy_buffer_size 4k;

proxy_buffers 8 4k;

Проверка MSS через map

map \$tcpinfo_mss \$proxy_flag {

default 0;

1300-1450 1;

1200-1299 2;

}

Логирование подозрительных соединений

log_format proxy_detect '\$remote_addr - \$remote_user [\$time_local] '

'"\$request" \$status \$body_bytes_sent '

'"\$http_referer" "\$http_user_agent" '

'mss=\$tcpinfo_mss proxy=\$proxy_flag';

access_log /var/log/nginx/proxy_detect.log proxy_detect if=\$proxy_flag;

```

После внедрения количество фрод-операций упало на 67%. Ложных срабатываний — 2.3%.

Кейс: Платежный шлюз и RTT-профилирование

Проблема: fraud-система блокировала легитимных пользователей с мобильным интернетом. Детекция по RTT variance давала 30% false positive.

Причина: мобильные сети LTE/5G имеют нестабильный RTT, но variance там выше 20 мс. Прокси дают variance 1-3 мс. Система использовала пороговое значение 5 мс — слишком жёстко.

Технические детали:

- 4G: RTT 30-80 мс, variance 15-40 мс

- 5G: RTT 10-30 мс, variance 8-20 мс

- Datacenter proxy: RTT 5-15 мс, variance 1-3 мс

- Residential proxy: RTT 20-60 мс, variance 3-8 мс

Решение: переход на двухфакторную детекцию RTT + TTL (Time To Live):

```python

import numpy as np

from sklearn.ensemble import IsolationForest

def detect_proxy(rtt_values, ttl_values):

Нормализация

rtt_norm = (rtt_values - np.mean(rtt_values)) / np.std(rtt_values)

ttl_norm = (ttl_values - np.mean(ttl_values)) / np.std(ttl_values)

Признаки: среднее RTT, variance RTT, TTL, TTL variance

features = np.array([

np.mean(rtt_values),

np.var(rtt_values),

np.mean(ttl_values),

np.var(ttl_values)

]).reshape(1, -1)

model = IsolationForest(contamination=0.1, random_state=42)

prediction = model.fit_predict(features)

-1 = аномалия (прокси), 1 = норма

return prediction[0] == -1

Пример: residential proxy с RTT 25-30 мс и TTL 55-57

rtt_sample = [26.2, 27.1, 25.8, 28.3, 26.9]

ttl_sample = [55, 56, 55, 57, 56]

print(detect_proxy(rtt_sample, ttl_sample)) # True

```

После внедрения ML-модели false positive снизились до 4.1%. Прокси детектировались с точностью 96.3%.

Кейс: Интернет-магазин и MTU-фрагментация

Проблема: клиенты через прокси не могли оформить заказ. Страница зависала на этапе оплаты. Поддержка грешила на браузер.

Причина: MTU на прокси-сервере был 1400, а на сервере магазина — 1500. Когда клиент отправлял POST-запрос с большими данными (корзина на 50+ товаров), происходила фрагментация. Промежуточный firewall блокировал ICMP-сообщения, и TCP-соединение зависало в retransmission.

Технические детали:

- MTU клиента через прокси: 1400 байт

- MTU сервера магазина: 1500 байт

- Размер POST-запроса: 2800 байт (2 TCP-сегмента)

- ICMP Type 3 Code 4 (Fragmentation Needed) блокировался firewall

- TCP retransmission timeout: 3 секунды, затем 6, 12, 24

Решение: принудительная установка MSS на уровне балансировщика:

```nginx

В секции server

server {

listen 443 ssl;

Принудительная установка MSS

tcp_mss 1400;

location /api/checkout {

Проверка размера тела запроса

client_max_body_size 10m;

Проксирование с учётом MTU

proxy_pass http://backend;

proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;

Настройка таймаутов для медленных соединений

proxy_connect_timeout 5s;

proxy_read_timeout 10s;

proxy_send_timeout 10s;

}

}

```

Дополнительно на сервере включили поддержку PLPMTUD (Packetization Layer Path MTU Discovery):

```bash

Включение PLPMTUD в Linux

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

echo 1024 > /proc/sys/net/ipv4/tcp_base_mss

echo 1460 > /proc/sys/net/ipv4/tcp_mtu_probe_size

```

После изменений количество зависших заказов упало на 89%. Прокси-клиенты перестали жаловаться.

Таблица сравнения методов детекции

| Метод | Точность | False Positive | Сложность обхода | Затраты на внедрение |

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

| IP-репутация | 70-80% | 5-10% | Низкая (смена IP) | Низкие |

| MTU (одиночный) | 65-75% | 8-15% | Средняя (настройка MTU) | Средние |

| RTT variance | 75-85% | 4-8% | Высокая (нужен прокси-агрегатор) | Средние |

| MTU + RTT | 90-95% | 2-5% | Очень высокая | Высокие |

| MTU + RTT + TTL | 94-97% | 1-3% | Почти невозможен | Высокие |

| ML (ансамбль) | 96-99% | 0.5-2% | Теоретически возможен | Очень высокие |

Как прокси-сервисы пытаются обходить детекцию

Обход MTU-детекции — это игра в кошки-мышки. Прокси-провайдеры подкручивают MTU на своих серверах, ставят 1500. Но это не помогает — антифрод смотрит на Path MTU, а не на MTU интерфейса.

С RTT variance сложнее. Можно добавить искусственный джиттер — случайную задержку от 5 до 50 мс. Но это убивает производительность. Пользователи жалуются на тормоза.

Некоторые прокси-сервисы ставят несколько выходных нод в разных дата-центрах и балансируют трафик. RTT variance растёт, но появляется другой признак — нестабильность маршрута. Антифрод это тоже видит.

На lexic.ml, например, используют динамическую маршрутизацию и адаптивный MTU. Но даже это не даёт 100% защиты — антифрод постоянно совершенствуется.

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

Если вы разрабатываете антифрод-систему:

1. Не используйте MTU и RTT по отдельности — только в комбинации

2. Собирайте данные за первые 5-10 запросов, не больше

3. Добавьте TTL — он почти не меняется у прокси

4. Используйте ML для кластеризации, а не жёсткие пороги

5. Обновляйте модель раз в неделю — прокси-провайдеры адаптируются

Если вы используете прокси и хотите снизить риск блокировки:

1. Выбирайте residential прокси, а не datacenter

2. Настройте MTU на клиенте под прокси-сервер

3. Используйте протоколы с минимальным оверхедом (WireGuard лучше OpenVPN)

4. Не делайте много параллельных соединений — это увеличивает variance RTT

5. Готовьтесь к тому, что 100% защиты не даст ни один метод