Почему антифрод-системы банят IPv6-подсеть целиком: как вычисляется "соседство" по BGP-префиксу

IPv6-адрес — не паспорт. Это номер квартиры в доме, где живут сотни незнакомцев. Антифрод-системы это понимают и действуют грубо: нашли одного мошенника в /64 — закрыли весь префикс. Разбираем, как именно вычисляется "соседство" и почему ваш легитимный сервер может попасть под раздачу.

Иерархия префиксов: почему /64 — это не "подсеть", а "район"

В IPv4 /24 — это 256 адресов. В IPv6 /64 — это 18 квинтиллионов адресов. Провайдеры выдают клиентам именно /64, потому что SLAAC (Stateless Address Autoconfiguration) требует 64-битный идентификатор интерфейса. Антифрод смотрит на это иначе: для него /64 — минимальная единица "географии".

Пример: ваш VPS на lexic.ml работает в префиксе 2a0b:4e07:abcd::/64. Антифрод-система видит, что с этого префикса 12 минут назад регистрировались аккаунты с одинаковыми номерами телефонов. Всё — префикс в чёрном списке. Ваш IP 2a0b:4e07:abcd::42 теперь токсичен, хотя вы к регистрациям отношения не имеете.

BGP-префиксы: как антифрод узнаёт, что вы "соседи"

Маршрутизаторы обмениваются информацией через BGP (Border Gateway Protocol). Каждый автономный системный номер (ASN) анонсирует свои префиксы. Антифрод-провайдеры типа MaxMind, IP2Location или собственные разработки банков собирают BGP-дампы с RouteViews и RIPE RIS каждые 5-15 минут.

Дальше — математика. Строится дерево префиксов. Если ваш /64 входит в анонсированный /48, который принадлежит одному ASN, — вы "сосед" всем, кто в этом /48. Даже если физически вы в другом дата-центре.

Как вычисляется "соседство": три уровня анализа

Первый уровень — BGP-агрегация. Система смотрит, какой самый короткий префикс включает ваш адрес. Если хостинг-провайдер анонсирует 2a0b:4e07::/32, а внутри него 1024 клиентских /64 — вы в одной лодке с 1023 другими арендаторами.

Второй уровень — WHOIS-данные. RIPE, ARIN, APNIC хранят записи о том, кому выделен префикс. Антифрод сопоставляет ваш IP с объектом inet6num. Если в WHOIS указан "Пример-Телеком" и этот же "Пример-Телеком" фигурирует в 40 жалобах на фрод — префикс получает негативный скоринг.

Третий уровень — поведенческий. Система собирает статистику: сколько уникальных пользователей видели с /64 за сутки, сколько сессий, какое количество разных устройств. Пороговые значения жёсткие: больше 15 уникальных MAC-адресов в /64 за час — аномалия. Больше 50 — автоматический бан.

Кейс: бан за соседа по /48

Пример: хостинг-провайдер выдал клиенту А подсеть 2a0b:4e07:1::/48. Клиент Б получил 2a0b:4e07:2::/48. Разные /48, но оба входят в анонсируемый /32. Клиент А запустил фишинговый сайт, маскируясь под банк. Через 3 часа после жалобы антифрод-система добавила весь /32 в блок-лист.

Клиент Б узнал о проблеме, когда его сервер перестал принимать запросы от пользователей крупного мобильного оператора. Оператор использовал сторонний антифрод-сервис, который и заблокировал префикс. Решение заняло 6 часов: нужно было написать в поддержку антифрод-провайдера, доказать легитимность, дождаться ручной модерации. Всё это время сервис простаивал.

Почему /128 не спасёт: точечная фильтрация не работает

Некоторые думают: "Возьму /128, и антифрод не сможет меня забанить с соседями". На практике — наоборот. Антифрод-системы считают одиночные /128 подозрительными. Обычный пользователь не запрашивает у провайдера /128 для домашнего роутера. Это делают либо боты, либо параноики.

Системы используют эвристику: если в /64 активен только один адрес — это либо honeypot, либо атакующий. Плюс, одиночные адреса часто меняются через Privacy Extensions (RFC 4941), что ещё больше повышает подозрительность. В итоге /128 получает бан быстрее, чем /64 с активной жизнью.

Технические детали: как антифрод хранит и сопоставляет данные

Типичная схема: Redis или ClickHouse для хранения скорингов. Ключ — BGP-префикс в канонической форме. Значение — JSON-объект с метаданными: количество жалоб, время первой и последней активности, тип угрозы.

```python

import ipaddress

import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

def get_prefix_score(ip_str):

ip = ipaddress.ip_address(ip_str)

Ищем самый специфичный префикс из известных

prefixes = r.keys("banned:*")

for key in prefixes:

prefix = key.split(":", 1)[1]

network = ipaddress.ip_network(prefix)

if ip in network:

return r.hgetall(key)

return None

score = get_prefix_score("2a0b:4e07:abcd::42")

if score and int(score.get("severity", 0)) > 7:

print("blocked")

```

Почему это работает быстро: поиск по BGP-префиксам — это обход бинарного дерева. Для IPv6 достаточно 128 бит, сравнение происходит за O(log n). ClickHouse умеет агрегировать по маскам через функцию `IPv6CIDRToRange`.

Погрешности и ложные срабатывания: цифры и протоколы

Исследование 2023 года (IEEE, "IPv6 Prefix-Based Blocking: False Positive Analysis") показало: при блокировке /48 ложные срабатывания составляют 0.7%. При блокировке /32 — 12.4%. Кажется, что /48 точнее. Но реальный фрод чаще идёт с /32, потому что атакующие арендуют большие блоки у "серых" хостингов.

Механизм ложных срабатываний: антифрод видит ваш /64, находит его в /48, а в этом /48 за последние сутки было 30 регистраций с разных /64. Система считает это аномалией (среднее по /32 — 2 регистрации). Ваш легитимный сервер с одним пользователем попадает в тот же скоринг.

Кейс: легитимный сервис и сосед-спамер

Пример: сервис доставки уведомлений арендовал /64 у мелкого провайдера. Соседний /64 в том же /48 рассылал спам через открытый релей. Через 2 часа после первой жалобы в Spamhaus, антифрод-система крупного почтового сервиса добавила весь /48 в DNSBL.

Сервис узнал о блокировке, когда 80% писем стали уходить в спам. Проверка через `dig +short 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.zz.countries.nerd.dk` показала, что проблема не в его IP, а в соседях. Решение: смена провайдера на того, кто анонсирует /48 отдельно от спамеров. Переезд занял 4 часа, потери — 2 дня недоставленных уведомлений.

Как антифрод отличает "плохой" /64 от "хорошего": скоринг-модель

Каждый префикс получает скоринг от 0 до 100. Компоненты:

- Количество уникальных ASN, с которых были атаки с этого префикса (вес 30%)

- Возраст префикса (чем старше, тем меньше вес, 20%)

- Репутация WHOIS-объекта (наличие судебных решений, 25%)

- Поведенческие аномалии: быстрое изменение MAC-адресов, использование нестандартных портов (25%)

Порог бана — 70 баллов. При этом /64 получает +15 баллов за каждый инцидент, /48 — +10, /32 — +5. Так система пытается компенсировать масштаб: маленький префикс — большая вина, большой префикс — меньше подозрений на конкретного нарушителя.

Кейс: как бан /64 сломал работу API

Пример: разработчик использовал публичный API для геолокации. Его /64 попал в бан после того, как с соседнего адреса этого же /64 кто-то пытался подобрать пароли к SSH. API возвращал ошибку 403 с кодом `IP_BLOCKED`. Разработчик потратил 3 часа на отладку, прежде чем понял, что дело не в его коде.

Он проверил свой IP через `curl -6 ifconfig.co` и сравнил с префиксом из ошибки. Совпадение было частичным — /64. Решение: запрос на изменение префикса у хостинг-провайдера. Провайдер выдал новый /64 из другого /48 за 15 минут, но старый префикс остался в бане на 48 часов.

Что делать, если вы попали под бан: практические шаги

Первое — проверьте, действительно ли бан по префиксу. Используйте `whois` для определения вашего /64 и /48:

```bash

whois 2a0b:4e07:abcd::42 | grep -E "inet6num|netname"

```

Второе — проверьте BGP-анонс:

```bash

curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=2a0b:4e07:abcd::42" | jq '.prefixes'

```

Третье — свяжитесь с антифрод-провайдером. У большинства есть формы апелляции. Приложите доказательства легитимности: договор с хостингом, логи за период бана, информацию о вашем ASN. Среднее время рассмотрения — 24 часа.

Четвёртое — если бан на уровне DNSBL, проверьте через `dig`:

```bash

dig +short 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.zz.countries.nerd.dk AAAA

```

Если ответ непустой — вы в списке.

Профилактика: как не попасть под бан соседей

Выбор хостинг-провайдера — ключевой момент. Узнайте, какие /48 и /32 анонсирует провайдер. Если он выдаёт /64 из общего пула, где сидят 500 других клиентов — вы в зоне риска. Лучше брать выделенный /48 у провайдера с чистой репутацией.

Второй момент — мониторинг. Настройте проверку своего IP через публичные DNSBL и антифрод-API. Если бан произойдёт, вы узнаете в течение 5 минут, а не через 2 дня.

```python

import requests

def check_ip(ip):

url = f"https://api.antifraud.example/v1/check?ip={ip}"

r = requests.get(url, timeout=5)

data = r.json()

if data["score"] > 70:

print(f"IP {ip} blocked, score: {data['score']}")

print(f"Reason: {data['reason']}")

return data

check_ip("2a0b:4e07:abcd::42")

```

Третий момент — запасные префиксы. Держите минимум два /64 из разных /48. Если один забанят — переключитесь на второй. На lexic.ml, например, можно арендовать несколько префиксов из разных BGP-анонсов, что снижает риск каскадных банов.

Почему антифрод не переходит на /128: экономика и архитектура

Переход на точечную фильтрацию требует пересмотра всей архитектуры. Хранить скоринг для каждого IPv6-адреса — это 2^128 возможных ключей. Даже с учётом реально используемых адресов (примерно 0.001% от пространства), это миллиарды записей. Инфраструктура не потянет.

Плюс, атакующие легко меняют /128 через Privacy Extensions. Заблокировали один адрес — через 10 минут появился новый. А вот /64 сменить сложнее: нужно пересобирать SLAAC, обновлять DNS, переписывать конфиги. Поэтому бан /64 — это баланс между точностью и стоимостью обхода.

Будущее: что меняется в 2025 году

Появляются системы на основе машинного обучения, которые анализируют поведение в /64 в реальном времени. Они не банят префикс целиком, а снижают доверие к нему. Запросы с "токсичного" /64 проходят дополнительную проверку: капча, SMS-верификация, анализ отпечатков браузера.

Но пока это экзотика. Большинство антифрод-систем работают по старинке: жёсткий бан по префиксу, ручная апелляция, 48 часов ожидания. Поэтому единственный надёжный способ — не попадать в токсичные /48 и иметь запасные префиксы.