Как антифрод-системы маркетплейсов вычисляют датацентровые IPv6 по ASN и BGP-анонсам

Как устроена идентификация ASN на уровне сети

Антифрод маркетплейсов не спрашивает «откуда пришёл запрос». Он смотрит на автономную систему, из которой анонсируется префикс. Каждый IPv6-адрес принадлежит не «стране» и не «городу», а конкретному AS — набору сетей под управлением одной организации. Когда клиент открывает страницу товара, балансировщик видит source address, а дальше идёт цепочка: префикс → origin AS → тип организации.

Ключевая структура — таблица BGP. Маршрутизаторы обмениваются анонсами вида «префикс 2a01:4f8::/32 origin AS24940». Эти данные собирают сервисы вроде RouteViews, RIPE RIS, bgp.tools. Из них строят базу: какой /32, /48 или /64 анонсируется и какой AS числится origin. Антифрод-вендоры вроде IPQualityScore, Spur, MaxMind держат такие базы с обновлением раз в несколько часов.

Дальше работает классификация. AS делят на категории: ISP (access), hosting, education, government, business. Категория hosting — красный флаг для маркетплейса. Если покупатель заходит с префикса, анонсируемого хостинг-провайдером, это не домашний пользователь. Это либо VPN, либо скрейпер, либо бот, либо прокси.

Почему IPv6 выдаёт прокси сильнее, чем IPv4

IPv4-пул выжат досуха. Хостинги годами сидят на переиспользованных блоках, часть из них «отмыта» через residential-прокси. IPv6 — другое дело. Префиксы /32 и /48 раздают крупными кусками, и хостинг-провайдеры получают их пачками. Каждый такой блок легко привязать к AS.

Плотность адресов тоже играет. В одном /64 — восемнадцать квинтиллионов адресов. Антифрод не может проверить каждый, но ему и не нужно. Он смотрит на префикс /64 или /48 и делает вывод: «этот блок целиком принадлежит Hetzner». Один анонс покрывает миллиарды адресов.

Вот как выглядит типичный запрос к базе ASN:

```bash

curl -s "https://api.bgpview.io/ip/2a01:4f8:c17:1234::1" | jq '.data.prefixes[] | {prefix, asn: .asn.asn, name: .asn.name, description: .asn.description}'

```

Ответ покажет что-то вроде:

```json

{

"prefix": "2a01:4f8::/32",

"asn": 24940,

"name": "Hetzner Online GmbH",

"description": "Hetzner Online GmbH"

}

```

Этого достаточно. AS24940 — известный хостинг. Маркетплейс помечает сессию как «datacenter origin» и включает повышенный скор риска.

Что именно смотрят антифрод-движки

Не только ASN. Смотрят на комбинацию сигналов, и ASN — один из слоёв. Первый слой — RIR-регистрация. ARIN, RIPE, APNIC публикуют whois-данные: кому выделен блок, какой тип организации. Второй слой — BGP origin. Третий — репутационные базы, где ASN уже помечен как hosting или proxy.

Есть нюанс с anycast и переанонсами. Некоторые провайдеры анонсируют чужие префиксы через свои AS. Тогда origin AS в BGP не совпадает с владельцем блока по whois. Антифрод это учитывает: если origin AS — хостинг, а whois говорит «ISP», всё равно сработает хостинг-флаг.

Ещё смотрят на длину префикса в анонсе. /48 и /56 — часто признак того, что провайдер нарезает адреса клиентам мелко. Хостинги обычно анонсируют /32 или /29 и раздают /64 внутри. Residential-провайдеры анонсируют крупнее и выдают /56 или /64 конечным абонентам.

Геолокация IPv6 и её дыры

С IPv4 геолокация работала по базе MaxMind, где адрес привязан к городу. С IPv6 всё хуже. Блоки огромные, точность падает. MaxMind для IPv6 часто отдаёт страну, реже — регион, почти никогда — город с точностью до района.

Маркетплейс видит: префикс в Германии, AS — Hetzner. Пользователь заявляет адрес доставки в Москве. Расхождение — сигнал. Но само по себе не блокировка: человек мог легально сидеть за границей. Антифрод складывает это с другими факторами — скорость оформления заказа, история аккаунта, поведение мыши.

Проблема в том, что геолокация IPv6 обновляется медленнее. Провайдер может перенести блок из Франкфурта в Амстердам, а база ещё месяц показывать старое. Антифрод-вендоры это знают и добавляют вес к свежим BGP-анонсам: если префикс анонсируется недавно, доверие к геоданным ниже.

Таблица: типичные ASN и их категории

| ASN | Организация | Категория | Тип префиксов |

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

| AS24940 | Hetzner Online | Hosting | /32, /29 |

| AS14061 | DigitalOcean | Hosting | /32 |

| AS16509 | Amazon AWS | Hosting/Cloud | /32, /28 |

| AS3356 | Lumen (Level3) | ISP/Transit | /16-подобные |

| AS15169 | Google | Cloud/ISP | смешанные |

Таблица не полная, но показывает логику. Антифрод держит такие списки на тысячи ASN и обновляет их автоматически. Попадание в hosting-категорию — минус к доверию.

Пример: как выглядит проверка в Python

Реальный сценарий: сервис проверяет входящий IPv6 перед оформлением заказа.

```python

import ipaddress

import requests

HOSTING_ASNS = {24940, 14061, 16509, 16276, 51167, 197540}

def check_ipv6(ip: str) -> dict:

addr = ipaddress.ip_address(ip)

if addr.version != 6:

raise ValueError("expected IPv6")

resp = requests.get(

f"https://api.bgpview.io/ip/{ip}",

timeout=3

)

data = resp.json()["data"]

prefixes = data.get("prefixes", [])

if not prefixes:

return {"risk": "unknown", "reason": "no bgp data"}

origin = prefixes[0]["asn"]["asn"]

name = prefixes[0]["asn"]["name"]

is_hosting = origin in HOSTING_ASNS

return {

"risk": "high" if is_hosting else "low",

"asn": origin,

"org": name,

"prefix": prefixes[0]["prefix"]

}

print(check_ipv6("2a01:4f8:c17:1234::1"))

```

Функция делает один вызов и возвращает вердикт. В продакшене такие вызовы кешируют на 6-24 часа по префиксу /48, иначе API задохнётся от нагрузки.

Случай с ботом на DigitalOcean

Маркетплейс электроники, 40 тысяч заказов в сутки. Всплеск регистраций с IPv6-адресов из AS14061 (DigitalOcean). Все аккаунты создавались за 8-12 секунд, с одинаковым user-agent, заказы на дорогую технику с доставкой в разные города.

Причина: скрейпер-бот развернул пул дроплетов и гонял регистрации через них. Каждый дроплет получал свой /64 внутри анонса AS14061. Антифрод не проверял каждый адрес — он смотрел на ASN. Все адреса принадлежали одному хостингу.

Технические детали: бот использовал 200+ дроплетов, каждый с уникальным /64. Скорость регистрации — 4-6 аккаунтов в минуту на дроплет. User-agent — фиксированный Chrome 120 на Linux. Время между открытием страницы и submit — 6-9 секунд.

Решение: правило «если origin AS в hosting-списке и время сессии < 15 секунд — блок». Плюс задержка на капчу для всех регистраций из хостинг-ASN. Ложных срабатываний почти не было: реальные покупатели с хостинг-IPv6 — это в основном разработчики через VPN, их доля меньше 0.3%.

Случай с легальным VPN-пользователем

Другой маркетплейс, одежда. Клиент из Германии, IPv6 из AS24940 (Hetzner). Заказ на 300 евро, доставка во Франкфурт. Антифрод заблокировал транзакцию как «datacenter origin».

Причина: клиент сидел через корпоративный VPN, который хостился на Hetzner. Компания арендовала серверы и гоняла весь трафик сотрудников через них. Антифрод видел хостинг-ASN и не различал «VPN компании» и «прокси бота».

Технические детали: VPN-выход — 2a01:4f8:1c1c:abcd::/64, origin AS24940. Клиент заходил с того же /64 три раза за неделю, все заказы легальные. Поведение: медленное заполнение формы, чтение описаний товаров, возвраты в корзину. Это не бот.

Решение: добавить поведенческий слой поверх ASN-фильтра. Если сессия длинная, поведение человеческое, история аккаунта чистая — снимать хостинг-флаг. Плюс whitelist для известных корпоративных VPN по /48. После правки ложные блокировки упали с 12% до 1.4% от всех хостинг-сессий.

Случай с переанонсом префикса

Сервис доставки еды, 15 тысяч заказов в сутки. Внезапно 8% заказов с IPv6 стали помечаться как «подозрительные». ASN у всех — AS3356 (Lumen), категория ISP. Формально не хостинг, но флаг всё равно срабатывал.

Причина: небольшой хостинг-провайдер арендовал блок у Lumen и переанонсировал его через свой AS. BGP origin показывал AS3356, а whois — хостинг. Антифрод смотрел только на origin AS и видел ISP, но репутационная база уже пометила эти /48 как proxy. Расхождение между BGP и whois дало ложный сигнал.

Технические детали: блок 2600:1234::/48, origin AS3356, whois-владелец — мелкий хостинг. Переанонс через AS3356 с более специфичным префиксом. Антифрод-база обновилась с задержкой 18 часов, за это время прошло 1200 ложных блокировок.

Решение: сверять origin AS с whois-владельцем блока. Если не совпадают — понижать доверие к origin-категории и смотреть на whois. Плюс мониторить BGP-изменения для своих критичных префиксов. После фикса ложные срабатывания ушли в ноль за двое суток.

Как это обходят и почему не всегда работает

Простейший обход — residential-прокси. Это реальные домашние IPv6 от ISP, не хостинг. Антифрод видит AS провайдера, категория access, флаг не срабатывает. Такие пулы дорогие, но их покупают для обхода ASN-фильтров.

Второй способ — найти хостинг с «чистым» ASN. Мелкие провайдеры, которых нет в репутационных базах, не помечены как hosting. Пока вендор не добавит их в список, адреса проходят. Это гонка: провайдер появляется, антифрод его находит, провайдер меняет ASN.

Третий — использовать мобильные IPv6. Операторы выдают /64 абонентам, origin AS — крупный телеком, категория ISP. Прокси через мобильные сети дороже, но ASN-фильтр не ловит. Правда, остаются другие сигналы: нестабильность сессии, смена /64 между запросами.

Здесь и появляется ниша IPv6-прокси с чистыми ASN. Сервис вроде lexic.ml выдаёт адреса из префиксов, которые не помечены как хостинг в основных базах, — это снижает вероятность срабатывания ASN-фильтра, хотя поведенческий анализ и геолокация всё равно остаются на стороне антифрода.

Что делать, если тебя блокируют по ASN

Первый шаг — проверить, какой ASN у твоего адреса. Запрос к bgpview или bgp.tools покажет origin и категорию. Если это hosting — фильтр сработает почти гарантированно.

```bash

curl -s "https://api.bgpview.io/ip/\$(curl -s -6 ifconfig.co)" | jq '.data.prefixes[0].asn | {asn, name, description}'

```

Второй шаг — сравнить с whois. Если origin AS хостинг, а whois тоже хостинг, обхода по ASN не будет. Нужен residential или мобильный пул.

Третий шаг — проверить геолокацию. MaxMind и IP2Location дают разные результаты для IPv6. Если твой адрес в базе числится в другой стране, чем заявленная доставка, это отдельный сигнал.

Четвёртый — поведение. Даже с хостинг-ASN можно пройти, если сессия выглядит человеческой: медленное заполнение, чтение страниц, отсутствие паттернов бота. Антифрод редко блокирует по одному признаку, обычно это сумма.

Итог по архитектуре

Антифрод маркетплейса строит решение на четырёх слоях: BGP origin, whois, репутационная база, поведение. ASN — самый дешёвый и быстрый слой, поэтому его проверяют первым. Хостинг-ASN даёт мгновенный минус к доверию, но не приговор.

Понимание этой цепочки помогает и защищаться, и строить. Если ты пишешь антифрод — не полагайся только на ASN, добавляй поведение и сверку BGP с whois. Если ты обходишь фильтры — смотри на ASN первым делом, потом на геолокацию, потом на поведение. Каждый слой закрывается отдельно, и самый слабый всегда найдётся.