Как антифрод-системы маркетплейсов выявляют IPv6-прокси через анализ ASN и whois-истории
Содержание
Как устроен антифрод на маркетплейсах
Антифрод маркетплейсов — это не одна система, а слоёный пирог из десятка сервисов. Поверхностный уровень ловит явные прокси по публичным чёрным спискам. Средний — анализирует поведение: скорость заполнения форм, движение мыши, время между кликами. Глубокий уровень копает сетевую инфраструктуру: ASN, whois-историю, BGP-анонсы, репутацию префиксов.
IPv6 добавил головной боли обеим сторонам. С одной стороны, адресное пространство огромное — 2^128, банить по /128 бессмысленно. С другой — провайдеры выдают /64 или /56 на пользователя, и антифрод научился работать с префиксами, а не отдельными адресами.
Крупные площадки (Amazon, Wildberries, Ozon, eBay) держат собственные scoring-модели. Мелкие покупают готовые решения: Sift, Forter, Riskified, Signifyd. Все они так или иначе смотрят на ASN.
Почему ASN важнее самого IP
Автономная система — это блок маршрутизации, который анонсируется через BGP. У каждой ASN есть номер, владелец, дата регистрации, набор префиксов. Антифрод смотрит не на «плохой IP», а на «подозрительную ASN».
Логика простая. Жилой пользователь сидит в ASN Ростелекома, Comcast, Deutsche Telekom. Это ASN с миллионами абонентов, зарегистрированные 20-30 лет назад, с чистой историей. Прокси-ферма живёт в ASN хостинг-провайдера: Hetzner, DigitalOcean, OVH, Vultr, мелкие VPS-конторы.
Разница видна сразу. Если запрос на оформление заказа идёт из ASN 24940 (Hetzner) — это уже флаг. Не блокировка, но плюс к риску. Если из ASN 8402 (Corporation for Fixed Telecommunications) — минус к риску.
```python
import requests
def get_asn_info(ip):
r = requests.get(f"https://api.iptoasn.com/v1/as/ip/{ip}", timeout=5)
data = r.json()
return {
"asn": data.get("as_number"),
"country": data.get("as_country_code"),
"description": data.get("as_description")
}
print(get_asn_info("2001:db8::1"))
```
Реальный ответ для хостингового IPv6 обычно содержит слова Hosting, Cloud, VPS, Datacenter, Server. Для жилого — Telecom, Broadband, Mobile, Cable. Антифрод прогоняет описание ASN через классификатор и получает вероятность «это хостинг».
Классификация ASN: хостинг vs резидент
Не все хостинговые ASN одинаково палевны. Есть три категории, и антифрод их различает.
Первая — крупные облака: AWS (ASN 16509, 14618), Google Cloud (396982), Azure (8075). Их IP часто в белых списках, потому что там сидят корпоративные клиенты, SaaS, легальные боты. Но residential-прокси в этих ASN всё равно ловятся по другим признакам.
Вторая — VPS-хостеры: Hetzner (24940), OVH (16276), DigitalOcean (14061), Vultr (20473). Здесь чисто, однозначно хостинг. Запрос из такого IPv6 — красный флаг, если только это не API-интеграция.
Третья — «серые» ASN. Мелкие провайдеры, которые сдают префиксы в аренду. Часто зарегистрированы недавно, с мутной whois-историей. Антифрод такие особенно не любит.
| ASN | Владелец | Тип | Возраст регистрации |
|-----|----------|-----|---------------------|
| 24940 | Hetzner Online | Хостинг | 2001 |
| 14061 | DigitalOcean | Хостинг | 2012 |
| 16276 | OVH SAS | Хостинг | 2001 |
| 8402 | Corbel (residential) | Резидент | 1997 |
| 3352 | Telefonica Spain | Резидент | 1993 |
Возраст ASN — важный сигнал. Антифрод знает: если ASN зарегистрирована полгода назад и сразу раздаёт IPv6 /64 блоками — это прокси-ферма. Легальный провайдер растёт годами.
Whoис-история и BGP-анонсы
Whois — это не только «кто владелец». Это история изменений. Антифрод-сервисы (Spur, IPQualityScore, Scamalytics) держат базы, где видно: префикс сменил владельца три раза за год, анонсировался из разных стран, был замечен в спам-листах.
IPv6-префиксы часто мигрируют между ASN. Хостер банкротится — префикс уходит к другому. Или наоборот: один владелец регистрирует десяток ASN и раскидывает трафик, чтобы не палиться. Антифрод видит паттерн: одинаковые контактные данные в whois, одинаковые abuse-email, одинаковые технические контакты.
```bash
whois -h whois.ripe.net 2001:db8::/32 | grep -E "org-name|descr|abuse-mailbox|created"
```
Вывод покажет организацию, дату создания, abuse-контакт. Если abuse-mailbox совпадает у десяти разных ASN — это сеть прокси-провайдеров. Антифрод такие связки вычисляет автоматически.
BGP-анонсы добавляют контекст. Префикс анонсируется из дата-центра во Франкфурте, но whois говорит «зарегистрирован на Сейшелах», а трафик идёт через Румынию. Три несовпадения — высокий риск.
Поведенческий анализ поверх сетевого
Сетевые признаки — только половина дела. Антифрод смотрит, как ведёт себя сессия.
IPv6-прокси часто имеют характерный паттерн: один /64 префикс, но сотни разных /128 адресов. Антифрод считает: если с одного /64 за час пришло 50 регистраций — это ферма. Жилой пользователь даёт 1-2 устройства, максимум 5-10 адресов в /64 (ротация privacy extensions).
Privacy extensions (RFC 4941) дают пользователю временные адреса, которые меняются каждые несколько часов. Антифрод это знает и не паникует, если видит ротацию внутри /64. Но если ротация идёт каждые 30 секунд — это скрипт.
Второй признак — TLS fingerprint. JA3/JA4 хеш показывает, какая библиотека устанавливает соединение. Прокси на Python requests даёт один хеш, реальный Chrome — другой. IPv6-прокси с curl-подобным fingerprint на жилом ASN — противоречие.
Третий — WebRTC. Браузер через WebRTC может слить локальный IP и реальный IPv6, даже если трафик идёт через прокси. Антифрод-скрипты на странице оформляют STUN-запрос и сравнивают адреса.
Почему IPv6 сложнее банить
IPv4-адрес — единица. Забанил — пользователь отвалился. IPv6 — префикс. Бан /128 бесполезен: прокси ротирует адреса внутри /64. Бан /64 — можно зацепить легальных соседей, если префикс общий.
Поэтому антифрод работает не с адресами, а с репутацией префикса. Если /64 замечен в мошенничестве, весь блок получает минус к score. Прокси-провайдеры в ответ дробят префиксы: покупают /48 и раскидывают на десятки /64, каждый со своей «легендой».
Гонка вооружений. Прокси-провайдеры регистрируют ASN под видом ISP, покупают резидентские IPv6 через партнёрские программы, ставят reverse DNS как у жилых сетей. Антифрод отвечает: смотрит на latency до узла, на jitter, на TTL.
Жилой IPv6 обычно имеет TTL 64 или 255 с первого хопа. Хостинговый — тоже, но latency до него 1-5 мс от дата-центра. Антифрод измеряет RTT через TCP handshake и сравнивает с географией. Если «пользователь из Новосибирска» отвечает за 3 мс, а ближайший дата-центр в Москве — 3000 км — это прокси.
Где ломается детект
Не всё так гладко у антифрода. Есть дыры, и прокси-провайдеры их знают.
Первая — мобильные IPv6. Операторы (МТС, Beeline, T-Mobile) выдают IPv6 из больших пулов, часто /64 на устройство. Ротация агрессивная, ASN жирная, latency высокая. Отличить мобильного прокси от реального абонента сложно.
Вторая — CGNAT и переходные механизмы. 464XLAT, DS-Lite, MAP-T маскируют реальную топологию. Антифрод видит IPv6, но за ним может сидеть что угодно.
Третья — легальные сервисы в хостинговых ASN. VPN-провайдеры (Mullvad, ProtonVPN) сидят в Hetzner и OVH. Их пользователи — не мошенники. Антифрод балансирует: не банить всех, но требовать дополнительную верификацию.
Пример: разбор подозрительной сессии
Сервер маркетплейса на nginx 1.24 получает POST на /api/checkout. Источник — 2a01:4f8:c17:xxxx::1. Логи показывают:
```
2024-11-15T14:23:11+00:00 src=2a01:4f8:c17:8a3f::1 asn=24940 country=DE
2024-11-15T14:23:11+00:00 ja3=8f4a3c... tls=1.3 alpn=h2
2024-11-15T14:23:12+00:00 form_fill_time=0.8s mouse_events=0
2024-11-15T14:23:12+00:00 webrtc_leak=2a01:4f8:c17:8a3f::1
```
ASN 24940 — Hetzner. Форма заполнена за 0.8 секунды, движения мыши ноль. WebRTC показывает тот же адрес, что и TCP-соединение. Три флага складываются в один вердикт: бот через прокси. Решение — блокировка, требование капчи, ручная проверка.
Практическая защита: что делать
Если вы строите прокси-инфраструктуру и не хотите палиться — работать с ASN, а не с адресами. Покупать резидентские IPv6 через провайдеров, которые реально выдают их абонентам. Настраивать reverse DNS под жилой шаблон. Контролировать latency: сервер должен физически стоять рядом с заявленной географией.
Если вы строите антифрод — не полагаться на один сигнал. ASN + whois + поведение + TLS fingerprint + WebRTC. Каждый по отдельности даёт ложные срабатывания. Вместе — работают.
lexic.ml с 2015 года крутит IPv6-прокси и видит обе стороны: как провайдеры регистрируют префиксы и как антифрод их ловит. Инфраструктура меняется каждые полгода, статические чёрные списки устаревают за месяцы.
```python
import ipaddress
import requests
def score_ipv6(ip, asn_db):
addr = ipaddress.IPv6Address(ip)
prefix64 = ipaddress.IPv6Network(f"{addr}/64", strict=False)
asn = asn_db.lookup(ip)
score = 0
if asn.type == "hosting":
score += 40
if asn.age_years < 2:
score += 25
if asn.abuse_reports_30d > 100:
score += 20
if prefix64 in asn.recent_fraud_prefixes:
score += 15
return min(score, 100)
verdict = score_ipv6("2a01:4f8:c17:8a3f::1", asn_db)
print(f"Risk score: {verdict}")
```
Такой скор — не приговор, а вход в модель. Дальше решает бизнес-логика: капча, 3DS, ручная модерация, отказ.
