Bot Protection и антифрод API
1) Зачем это нужно
Боты и злоумышленники атакуют входные точки роста и денег: регистрацию, логин (ATO), депозиты/выводы, промо-механику, каталоги игр/коэффициентов. Ручные правила и чистый rate limit уже недостаточны: нужны многоуровневые сигналы, скоринг в реальном времени и контроль решения (allow/deny/challenge/throttle) с обратной связью от бизнес-событий (чарджбэки, chargeback-ratio, KYC-фейлы).
2) Таксономия угроз
Регистрация/онбординг: массовые аккаунты, одноразовые e-mail/сим-банки, фермы девайсов.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
Бонус-абьюз: мультиаккаутинг, арбитраж гео/юрисдикций, self-exclusion обход.
Картинг/платежный фрод: тест карт, ворованные кошельки, возвраты средств.
Скрейпинг/инвентарь: агрессивное вытягивание контента, цен, коэффициентов.
API-DoS низкой интенсивности: черепашьи атаки, slow-POST, эмуляции мобильных SDK.
Вебхуки/интеграции: подделка уведомлений без HMAC/mTLS, replay.
3) Архитектура защиты
3.1 Слои
1. Edge (CDN/WAF/шлюз): ранние отказы (ASN/Geo/IP-репутация), легкие челленджи, лимиты, PoW.
2. Risk API (PDP по риску): централизованный движок правил/ML; ответ — `decision`, `score`, `reason`, `ttl`.
3. App-уровень: доменные инварианты, бизнес-логика (лимиты, KYC, AML), асинхронные ревью.
4. Поток событий: Kafka/Kinesis → feature store/модель → обратная связь от платежей/диспутов.
3.2 Контур решения
[Request] → Edge Plugins → (enrich) → Risk API (rules+ML) → Decision:
allow deny throttle challenge(type=captcha sms PoW biometry)Решение кэшируется по ключу (например, device×account×route) на `ttl` секунд.
4) Сигналы и обогащение
Сеть/канал: IP/ASN, прокси/VPN/Tor, rdns, rtt/jitter, SYN-rate, TLS-фингерпринт (JA3/JA4), HTTP/2/3 поведение.
Девайс/браузер: canvas/audio/WebGL FP (бережно), платформа/SDK, timezone/locale, разрешение, шрифты, WebDriver/hеadless индикаторы, mobile attestation (SafetyNet/DeviceCheck, по возможности).
Поведение: скорость ввода, траектории мыши/тач, последовательность экранов, dwell-time, частота попыток, переходы между браузерными идентификаторами.
Контент/запрос: форма e-mail/домен, disposable-провайдеры, phone HLR/или тип номера, BIN карты, счет/IBAN в санк-реестрах, схожесть ФИО/адресов.
Аккаунт/история: возраст аккаунта, KYC-статус, ретеншн, ARPPU, velocity по депозитам/выводам/бонусам.
Внешние источники: списки компрометации (HIBP-подобные), платежные рисковые сигналы (PSP), ASN-репутация.
5) Решение: правила + ML
5.1 Правила (детерминированные)
Velocity: «N регистраций с /24 за 10 мин», «M логинов с одним девайсом к X аккаунтам», «K 3DS-фейлов подряд».
Гео/юрисдикция: конфликты IP-гео vs адрес/документ, внезапные прыжки местоположения.
Бизнес-инварианты: лимиты ответственных платежей, self-exclusion, санкционные списки.
5.2 ML-скоринг (реал-тайм)
Легкая модель (GBM/логрег) на онлайн-признаках: `ip_risk`, `device_age`, `account_age`, `pwd_fail_rate`, `bin_risk`, `velocity_`, `behavioral_`.
Отдельная модель для ATO и отдельно — для платежей/выводов.
Сегментация по юрисдикции/тенанту (пер-рынок калибровка порогов).
5.3 Принятие решения
if ip_blacklisted or bad_asn then deny else if rule_severe then challenge(hard)
else if score >= 0. 9 then deny else if 0. 7 <= score < 0. 9 then challenge(soft)
else allowПри `challenge` хранить факты прохождения/провала; эскалировать/снижать трение динамически.
6) Velocity и квоты (ключи и окна)
Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
Окна: скользящие (1м/5м/1ч/24ч) + отдельные «burst»/«sustained».
Политики: «жесткие» deny на горячих маршрутах (логин/депозит), мягкие throttle на контенте.
pseudo allow, retry_after = gcra_allow(key="login:ip:"+ip, rate=60/min, burst=30)
if not allow:
return 429, {"Retry-After": retry_after}7) Челленджи и проверка «человечности»
CAPTCHA/turnstile: как soft-challenge; убирать после высокой уверенности в «чистой» сессии.
Proof-of-Work (PoW): для API/скриптов — вычислить хэш с заданной сложностью; динамическая сложность при росте нагрузки.
OTP/SMS/Email/Push: для ATO/критичных операций; не злоупотреблять (стоимость/UX).
WebAuthn/биометрия: высокий уровень уверенности на cash-out/изменение payout-деталей.
Device trust: bind аккаунта к проверенному девайсу; новые девайсы → challenge.
8) Интеграция в шлюз/прокси
8.1 Envoy: ext_authz → Risk API (псевдо)
yaml http_filters:
- name: envoy. filters. http. ext_authz typed_config:
http_service:
server_uri: { uri: http://risk-api:8080, cluster: risk, timeout: 80ms }
authorization_request:
allowed_headers:
patterns:
- exact: "x-tenant"
- exact: "x-device-id"
- exact: "user-agent"
authorization_response:
allowed_upstream_headers:
patterns: [{ exact: "x-risk-score" }, { exact: "x-risk-decision" }]
- name: envoy. filters. http. router8.2 NGINX/Lua: легкий PoW и velocity
nginx lua_shared_dict vel 20m;
access_by_lua_block {
local ip = ngx. var. remote_addr if not gcra_allow("reg:ip:"..ip, 20, 40) then ngx. header["Retry-After"] = 30; return ngx. exit(429)
end
local pow = ngx. req. get_headers()["X-POW"]
if not verify_pow(pow, ngx. var. request_id, 18) then ngx. status = 401; ngx. say('need-pow'); return ngx. exit(401)
end
}9) Контракт Risk API
Запрос (обогащенный):json
{
"tenant":"eu-1",
"route":"POST /v1/login",
"subject":{"account_id":"a123","email":"u@d. com"},
"device":{"id":"d-xyz","fp":"...","ja3":"...","headless":false},
"network":{"ip":"203. 0. 113. 10","asn":12345,"country":"DE","rtt_ms":42},
"context":{"fail_5m":3,"pwd_reset_24h":1}
}json
{ "decision":"challenge", "score":0. 83, "reason":"high_velocity+new_device", "ttl_sec":900, "challenge":"captcha" }10) Данные, фичи и модели
Feature Store (онлайн): Redis/Scylla/KeyDB — счетчики/velocity/временные метки.
Batch/офлайн: DWH (BigQuery/S3+Athena) для обучения/рефитов; храните метки оттока, chargeback, ручных ревью.
Модели: простые для real-time (логрег/GBM); тяжелые (XGBoost/NN) — офлайн с PGMs/шкалированием и последующей дистилляцией.
Контроль дрифта: PSI, AUC/PR, калiбровка порогов по регионам/каналам.
11) Наблюдаемость и операционный контур
Метрики:- `risk_requests_total{route,decision}`
- `risk_score_bucket` (distribution)
- `waf_block_total`, `velocity_block_total`, `challenge_pass_rate`
- `ato_incidents`, `carding_detected`, `cashout_denied`
- бизнес-метрики: `chargeback_rate`, `bonus_abuse_rate`, `false_positive_rate`
- Логи (редактированные): `decision`, `score`, ключевые сигналы, `trace_id`, без PII/секретов.
- A/B и Shadow: новая политика в shadow-режиме (логируем решения), потом canary (1–5%), автороллбек по SLO/FP.
- Playbooks: эскалация, временное ужесточение, откат, «виртуальные патчи».
12) Приватность и соответствие
Минимизируйте PII; хешируйте устойчивые идентификаторы (например, email SHA-256 с солью).
Уважайте региональную юрисдикцию (локализация данных, согласия).
Прозрачные объяснения решений для ручных ревью; храните только необходимое и с TTL.
13) Специфика iGaming/финансов
Регистрация: фильтры disposable e-mail/VoIP, velocity по /24, девайс-фермы → challenge/deny.
Логин/ATO: новые девайсы/гео-скачки → OTP/WebAuthn; password spraying → throttle/deny.
Бонусы: лимиты на «путь к отмыванию» (депозит→бонус→минимальный оборот→вывод), graph-анализ аффилированности (адреса/девайсы/карты).
Платежи/выводы: BIN-риск, country-mismatch, PSP-сигналы; cashout на новый инструмент → высокий порог и чекап KYC.
Вебхуки PSP/KYC: HMAC + mTLS, узкие IP-allow-лист, anti-replay (`X-Timestamp`, окно ±5 мин).
14) Антипаттерны
Один универсальный captcha «везде и всегда» → высокий FP/падение конверсии.
Только rate limit без поведенческих/девайсных сигналов.
Хранение «сырых» отпечатков и PII бессрочно.
Отсутствие shadow-прогона и canary для новых политик.
Полное доверие внешним «репутационным» меткам без собственной валидации.
Принятие решений на клиенте (JS/мобильный SDK) без серверной проверки.
15) Примеры правил и псевдокод
15.1 Композитное правило (реал-тайм)
pseudo score = 0 if ip_asn in bad_asn_list then score += 0. 5 if device_age < 1d and route in {login, withdraw} then score += 0. 3 if velocity("login:account", 5m) > 10 then score += 0. 3 if geovelocity(last_login_loc, current_loc) > 800km/h then score += 0. 2 decision = score>=0. 9? "deny": score>=0. 7? "challenge": "allow"15.2 Граф связей (мультиаккаунт)
edge(accountA, deviceX)
edge(accountB, deviceX)
edge(accountB, cardY)
edge(accountC, cardY)
Threshold by common nodes → investigation/deny bonus16) Чек-лист prod-готовности
- Многоуровневая архитектура: Edge → Risk API → App, поток событий.
- Сигналы: сеть, девайс, поведение, контент, платеж; минимизация PII.
- Velocity/GCRA на ключах ip/device/account/payment, скользящие окна.
- Решения: allow/deny/challenge/throttle; кэш решений с TTL; хранилище фактов челленджей.
- Челленджи: captcha/PoW/OTP/WebAuthn; динамическая сложность.
- Risk API: SLA <100 мс, кэш, деградация в «минимально безопасный» режим.
- Наблюдаемость: метрики risk, FP/FN, дашборды, алерты; бизнес-метрики (chargeback/bonus-abuse).
- Shadow → canary → enforce; плейбуки эскалации и отката.
- Вебхуки PSP/KYC: HMAC+mTLS+anti-replay+allow-list.
- Региональные требования и TTL на чувствительные данные.
17) TL;DR
Стройте слоистую защиту: ранние edge-фильтры и челленджи, централизованный Risk API с правилами+ML и поток событий для обратной связи. Используйте velocity-лимиты, сигналы сети/девайса/поведения, динамические challenge (captcha/PoW/OTP/WebAuthn). Принимайте решения allow/deny/challenge/throttle, меряйте FP/FN и бизнес-эффект, раскатывайте через shadow/canary. Для платежных/бонусных путей — отдельные ужесточенные профили и связка с KYC/AML.