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/headless індикатори, mobile attestation (SafetyNet/Ded viceCheck, по можливості).
Поведінка: швидкість введення, траєкторії миші/тач, послідовність екранів, 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: для АТО/критичних операцій; не зловживати (вартість/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, калібрування порогів по регіонах/каналах.
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.
Логін/АТО: нові девайси/гео-стрибки → OTP/WebAuthn; password spraying → throttle/deny.
Бонуси: ліміти на «шлях до відмивання» (depozit→bonus→minimalnyy oborot→vyvod), 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.