Protecția bot și anti-fraudă API

1) De ce aveți nevoie de ea

Roboții și atacatorii atacă punctele de intrare în creștere și bani: înregistrare, autentificare (ATO), depozite/concluzii, mecanică promoțională, cataloage de jocuri/coeficienți. Regulile manuale și limita ratei pure nu mai sunt suficiente: aveți nevoie de semnale pe mai multe niveluri, scoring în timp real și controlul soluției (permiteți/negați/provocare/accelerație) cu feedback de la evenimente de afaceri (chargebacks, chargeback-ratio, KYC-files).

2) taxonomie amenințare

Înregistrare/onboarding: conturi de masă, e-mail de unică folosință/bănci SIM, ferme de dispozitive.
ATO (Account Takeover): umplutură de acreditare, pulverizare parolă, deturnare sesiune.
Abuz bonus: multi-rezervare, arbitraj geo/jurisdicție, auto-excludere by-pass.
Karting/fraudă de plată: test cu cardul, portofele furate, rambursări.
Răzuire/inventariere: tragerea agresivă a conținutului, prețurilor, raporturilor.
API-DoS de intensitate scăzută: atacuri de broască țestoasă, lent-POST, emulații SDK mobile.
Webhooks/integrations: notificări false fără HMAC/mTLS, reluare.

3) Arhitectura de protecție

3. 1 straturi

1. Edge (CDN/WAF/gateway): eșecuri timpurii (reputație ASN/Geo/IP), provocări ușoare, limite, PoW.
2. Risc API (Risk PDP): motor de regulă centralizat/ML; ответ - "decizie", "scor", "motiv", "ttl'.
3. Nivelul aplicației: invarianți de domeniu, logica de afaceri (limite, KYC, AML), recenzii asincrone.
4. Fluxul evenimentului: Kafka/Kinesis → feature store/model → feedback din plăți/litigii.

3. 2 Buclă de soluție

[Request] → Edge Plugins → (enrich) → Risk API (rules+ML) → Decision:
allow      deny      throttle      challenge(type=captcha    sms    PoW    biometry)

Soluția este cache de cheie (de exemplu, dispozitiv × cont × traseu) pentru „ttl” secunde.

4) Semnale și îmbogățire

Rețea/canal: IP/ASN, proxy/VPN/Tor, rdns, rtt/jitter, rata SYN, amprenta TLS (JA3/JA4), comportament HTTP/2/3.
Dispozitiv/browser: panza/audio/WebGL FP (atent), platforma/SDK, fusul orar/localizare, rezolutie, fonturi, WebDriver/indicatori fara cap, atestat mobil (SafetyNet/DeviceCheck, daca este posibil).
Comportament: viteza de intrare, traiectoriile mouse/touch, secvența ecranului, timpul de ședere, frecvența încercărilor, tranzițiile între identificatorii browserului.
Continut/cerere: formular e-mail/domeniu, furnizori de unica folosinta, tip HLR/sau numar de telefon, card BIN, cont/IBAN in registrele sanka, similaritate nume/adrese complete.
Cont/istoric: vârsta contului, starea KYC, păstrarea, ARPPU, viteza prin depozite/retrageri/bonusuri.
Surse externe: liste de compromisuri (HIBP-like), semnale de risc de plată (PSP), reputație ASN.

5) Soluție: Reguli + ML

5. 1 Reguli (deterministe)

Viteza: „N înregistrări cu/24 în 10 minute”, „M conectează cu un dispozitiv la conturile X”, „K 3DS-files într-un rând”.
Geo/Jurisdicție: conflicte IP geo vs adresă/document, salturi bruște de localizare.
Invarianții de afaceri: limitele plăților responsabile, autoexcluderea, listele de sancțiuni.

5. 2 ML scoring (timp real)

Model de lumină (GBM/logreg) cu privire la caracteristicile online: 'ip _ risk', 'device _ age', 'account _ age', 'pwd _ fail _ rate', 'bin _ risk', 'velocity _',' behavioral _'.
Model separat pentru ATO și separat pentru plăți/ieșiri.
Segmentarea pe jurisdicție/chiriaș (calibrarea pragului pe piață).

5. 3 Luarea deciziilor

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

Când „provocare”, stocați faptele de trecere/eșec; escaladarea/reducerea dinamică a frecării.

6) Viteză și cote (chei și ferestre)

Ключи: 'ip', 'ip/24', 'device _ id',' account _ id', 'payment _ instrument', 'email _ domain', 'bin'.
Ferestre: alunecare (1m/5m/1h/24h) + „spargere „individuală/” susținută„.
Politicienii: „greu” neagă pe rute fierbinți (conectare/depozit), accelerație moale pe conținut.

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) Provocări și testarea „umanității”

CAPTCHA/turnichet: как soft-challenge; eliminați după încredere ridicată într-o sesiune „curată”.
Proof-of-Work (PoW): pentru API/scripturi - calculați un hash cu o anumită complexitate; complexitate dinamică în timpul creșterii sarcinii.
OTP/SMS/Email/Push: pentru operațiuni ATO/critice; nu abuza (cost/UX).
WebAuthn/biometrics: nivel ridicat de încredere în detaliile de retragere/schimbare a plăților.
Încrederea dispozitivului: legați contul de un dispozitiv verificat; noi dispozitive → provocare.

8) Integrare gateway/proxy

8. 1 Trimis: ext_authz → risc API (pseudo)

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. router

8. 2 NGINX/Lua: PoW şi viteză uşoară

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) Contract API de risc

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) Date, caracteristici și modele

Feature Store (online): Redis/Scylla/KeyDB - contoare/viteze/marcaje de timp.
Lot/offline: DWH (BigQuery/S3 + Athena) pentru antrenament/refits; păstrați semne de ieșire, chargeback, recenzii manuale.
Modele: simple pentru timp real (logreg/GBM); heavy (XGBoost/NN) - offline cu PGMs/scalare și distilare ulterioară.
Controlul driftului: PSI, ASC/PR, calibrarea pragurilor pe regiuni/canale.

11) Observabilitate și circuit operațional

• 'risk _ requests _ total {route, decision}'
• 'risk _ score _ bucket' (distribuţie)
• 'waf _ block _ total', 'velocity _ block _ total', 'challenge _ pass _ ratee'
• 'ato _ incidents',' carding _ detected ',' cashout _ denieds'
• business metrics: 'chargeback _ rate', 'bonus _ abuse _ rate', 'false _ positive _ ratee'
• Jurnale (editate): "decizie", "scor", semnale cheie, "trace _ id', fără PII/secrete.
• A/B și Shadow: o nouă politică în modul umbră (log decizii), apoi canar (1-5%), auto-rollback prin SLO/FP.
• Playbook-uri: escaladare, strângere temporară, rollback, „patch-uri virtuale”.

12) Confidențialitate și conformitate

Minimizați PII; identificatori stabili hash (de exemplu, SHA-256 de e-mail cu sare).
Respectați jurisdicția regională (localizarea datelor, consimțământul).
Explicații transparente ale deciziilor pentru revizuirile manuale; păstrați doar ceea ce aveți nevoie și cu TTL.

13) Specificul iGaming/Finanțe

Înregistrare: e-mail de unică folosință/filtre VoIP, viteză cu/24, dispozitiv fermă → provocare/negare.
Autentificare/ATO: dispozitive noi/geo-salturi → OTP/WebAuthn; parola pulverizare → accelerație/negare.
Bonusuri: limite privind „calea către spălare” (depozit→bonus→minimalnyy oborot→vyvod), analiza grafică a afilierii (adrese/dispozitive/carduri).
Plăți/retrageri: risc BIN, neconcordanță de țară, semnale PSP; cashout la noul instrument → un prag ridicat și control KYC.
Webhooks PSP/KYC: HMAC + mTLS, îngust IP-allow-list, anti-reluare („X-Timestamp”, fereastră ± 5 minute).

14) Antipattern

Un captcha universal „peste tot și întotdeauna” → o cădere mare FP/conversie.
Numai limita ratei fără semnale comportamentale/dispozitiv.
Depozitarea printurilor „brute” și a PII este nelimitată.
Fără umbră şi canar pentru noi politici.
Încredere deplină în etichetele externe „reputaționale” fără validare proprie.
Luați decizii cu privire la client (JS/Mobile SDK) fără validarea serverului.

15) Exemple de reguli și pseudocodul

15. 1 Regulă compozită (în timp real)

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 Graficul relațiilor (multi-cont)

edge(accountA, deviceX)
edge(accountB, deviceX)
edge(accountB, cardY)
edge(accountC, cardY)
Threshold by common nodes → investigation/deny bonus

16) Lista de verificare Prod Readiness

• Arhitectură pe mai multe niveluri: API Edge → Risk → App, fluxul de evenimente.
• Semnale: rețea, dispozitiv, comportament, conținut, plată; Minimizarea PII.
• Viteza/GCRA pe ip/dispozitiv/cont/chei de plată, ferestre glisante.
• Soluții: permite/nega/provocare/accelerație; Soluție cache cu TTL un depozit de fapte provocare.
• Provocări: captcha/PoW/OTP/WebAuthn; complexitate dinamică.
• Risc API: SLA <100ms, cache, degradat la modul „minim de siguranță”.
• Observabilitate: risc, FP/FN, tablouri de bord, alerte; metrici de afaceri (chargeback/bonus-abuz).
• Umbra → canar → aplica; escaladarea și rollback playbooks.
• Webhooks PSP/KYC: HMAC + mTLS + anti-reluare + permite-listă.
• Cerințe regionale și TTL privind datele sensibile.

17) TL; DR

Construiți protecție stratificată: filtre de margine timpurii și provocări, API de risc centralizat cu reguli + ML și flux de evenimente pentru feedback. Utilizați limite de viteză, semnale de rețea/dispozitiv/comportament, provocări dinamice (captcha/PoW/OTP/WebAuthn). Luați decizii care permit/neagă/provocare/accelerație, măsurați FP/FN și efectul de afaceri, rulați prin umbră/canar. Pentru căi de plată/bonus - profiluri strânse separate și o legătură cu KYC/AML.