Bot Protection e API antifrode

1) Perché è necessario

Bot e aggressori attaccano i punti di ingresso di crescita e denaro: registrazione, login (ATO), depositi/conclusioni, meccanica promozionale, cataloghi di giochi/coefficienti. Le regole manuali e i rate limit netti non sono più sufficienti: servono segnali su più livelli, mapping in tempo reale e controllo della soluzione (allow/deny/challenge/throttle) con feedback dagli eventi aziendali (charjback, debeback-ratio, KYC-feel).

2) Tassonomia delle minacce

Registrazione/onboarding: account di massa, e-mail usa e getta/SIM, fattorie di device.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
Bonus-abuse: multicauting, arbitraggio geo/giurisdizione, self-exclusion aggiramento.
Kart/frod di pagamento: test delle carte, portafogli rubati, rimborsi.
Screaping/inventario: estrazione aggressiva di contenuti, prezzi, coefficienti.
API-DoS di bassa intensità: attacchi di tartaruga, slow-POST, emulazioni di SDK mobile.
Webhook/integrazioni: contraffazione delle notifiche senza HMAC/mTLS, replay.

3) Architettura di protezione

3. 1 Livelli

1. Edge (CDN/WAF/gateway): guasti precoci (ASN/Geo/IP-Reputation), leggeri challenge, limiti, PoW.
2. Risk API (PDP) - Motore di regole/ML centralizzato ответ — `decision`, `score`, `reason`, `ttl`.
3. Livello app: invarianti di dominio, logica aziendale (limiti, KYC, AML), gelosia asincrona.
4. Flusso di eventi: Kafka/Kinesis → feature store/modello → feedback da pagamenti/visualizzazioni.

3. 2 Tracciato della soluzione

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

La soluzione viene memorizzata nella cache con una chiave (ad esempio, device x account x route) di secondi.

4) Segnali e arricchimento

Rete/canale: IP/ASN, proxy/VPN/Tor, rdns, rtt/jitter, SYN-rate, TLS-fingerprint (JA3/JA4), HTTP/2/3 comportamento.
Device/browser: canvas/audio/WebGL FP (attento), piattaforma/SDK, timezone/locale, risoluzione, caratteri, indicatori WebDriver/headless, mobile attration (SafetyNet/DeviceCheck, se possibile).
Comportamento: velocità di input, traiettorie mouse/tach, sequenza di schermate, dwell-time, frequenza di tentativi, spostamenti tra gli ID browser.
Contenuto/richiesta: modulo e-mail/dominio, disposable provider, phone HLR/o tipo di numero, carta BIN, conto/BAN nei registri sank, simile a FIO/indirizzi.
Account/cronologia: l'età dell'account, lo stato KYC, il retensh, ARPPU, velocity per depositi/conclusioni/bonus.
Fonti esterne: liste di compromissione (HIBP-simili), segnali di rischio (PSP), reputazione ASN.

5) Soluzione: regole + ML

5. 1 Regole (determinate)

Velocity: «N registrazioni s/24 in 10 min», «M login con un solo device a X account», «K 3DS feed consecutivi».
Geo/giurisdizione: conflitti IP-geo vs indirizzo/documento, salti di posizione improvvisi.
Gli invarianti aziendali sono limiti di pagamento responsabile, self-exclusion, elenchi sanzionatori.

5. 2 set ML (real-time)

Modello leggero (GBM/logreg) sui segni online: «ip _ risk», «device _ age», «account _ age», «pwd _ fail _ rate», «bin _ risk», «velocity _», «behavioral _».
Un modello separato per ATO e separatamente per i pagamenti/conclusioni.
Segmentazione giurisdizionale/tenante (per-mercato calibrazione delle soglie).

5. 3 Decisione

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

Quando «challenge» conserva i fatti di successo/fallimento; scalare o ridurre l'attrito in modo dinamico.

6) Velocity e quote (chiavi e finestre)

Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
Finestre scivolose (1m/5m/1h/24h) + singole «burst «/« sustained ».
Regole: deny «rigidi» su rotte calde (login/deposito), throttle morbidi sui contenuti.

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) Challenge e prova di umanità

CAPTCHA/turnstile: как soft-challenge; pulire dopo l'alta fiducia in una sessione pulita.
Proof-of-Work (PoW) - Per API/script, calcolare l'hash con la complessità specificata; complessità dinamica quando il carico aumenta.
OTP/SMS/Email/Push: per le operazioni ATF/critiche; non abusare (costo/UX).
WebAuthn/biometria: elevata fiducia in cash-out/modifica di payout.
Device trust: l'account bind del device collaudato; I nuovi device del challenge.

8) Integrazione in gateway/proxy

8. 1 Avvoy: ext _ authz → Risk 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: leggero e 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) Contratto 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) Dati, feci e modelli

Feature Store (online): Redis/Scylla/KeyDB - contatori/velocity/etichette temporali.
Batch/offline: DWH (BigQuery/S3+Athena) per l'apprendimento/rifiti; memorizzare etichette di deflusso, chargeback, gelosia manuale.
Modelli semplici per il real-time (logreg/GBM) pesanti (XGBoost/NN) - offline con PGMs/scorrimento e successiva distillazione.
Controllo del drift: PSI, AUC/PR, calibro delle soglie per regione/canale.

11) Osservabilità e tracciato operativo

• `risk_requests_total{route,decision}`
• `risk_score_bucket` (distribution)
• `waf_block_total`, `velocity_block_total`, `challenge_pass_rate`
• `ato_incidents`, `carding_detected`, `cashout_denied`
• metriche aziendali: 'marceback _ rate', 'bonus _ abuse _ rate', 'false _ positive _ rate'
• I loghi (modificati) sono «decision», «score», i segnali chiave, «trace _ id», senza PII/segreti.
• A/B e Shadow: nuova regola in modalità shadow (logifichiamo le soluzioni), poi canary (1-5%), roll automatico SLO/FP.
• Playbooks: escalation, stretta temporanea, rimborso, patch virtuali.

12) Privacy e conformità

Ridurre al minimo il PII; hashtag identificatori sostenibili (ad esempio, email SHA-256 con sale).
Rispetto della giurisdizione regionale (localizzazione dei dati, consenso).
Spiegazioni trasparenti per le soluzioni manuali memorizzare solo ciò di cui hai bisogno e con TTL.

13) Specificità iGaming/finanza

Registrazione: filtri disposable e-mail/VoIP, velocity a/24, fattoria device → challenge/deny.
Login/ATF: nuovi device/geo-corse ; password spraying → throttle/deny.
Bonus: limiti per «via di riciclaggio» ( ), analisi graph di affiliazione (indirizzi/device/carte).
Pagamenti/conclusioni: rischio BIN, country-mismatch, segnali PSP; cashout al nuovo strumento → una soglia alta e un checkup KYC.
Webhoop PSP/KYC: HMAC + mTLS, foglio IP-allow stretto, anti-replay ('X-Timestamp', finestra © 5 min).

14) Antipattern

Un captcha universale «dappertutto e sempre» → un alto FP/calo della conversione.
Solo rate limit senza segnali comportamentali/device.
Conservazione di impronte crude e PII a tempo indeterminato.
Nessuna prova shadow e canary per le nuove regole.
Piena fiducia nelle etichette di reputazione esterne, senza la propria validazione.
Prendere decisioni su un client (JS/mobile SDK) senza controllo server.

15) Esempi di regole e pseudocodi

15. 1 Regola composita (real-time)

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 Grafico di relazioni (multiaccount)

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

16) Assegno-foglio prod-pronto

• Architettura su più livelli: Edge → Risk API → App, flusso di eventi.
• Segnali: rete, device, comportamento, contenuti, pagamento; Ridurre al minimo la PII.
• Velocity/GCRA nelle chiavi ip/device/account/payment, finestre che scivolano.
• Soluzioni allow/deny/challenge/throttle; Cache delle soluzioni con TTL il deposito dei fatti challenge.
• Challengee: captcha/PoW/OTP/WebAuthn; complessità dinamica.
• Risk API: SLA <100 ms, cache, degradazione in modalità «minimamente sicura».
• Osservabilità: metriche risk, FP/FN, dashboard, alert; metriche aziendali (conformeback/bonus-abuse).
• Shadow → canary → enforce; playbook di escalation e ritiri.
• Webhook PSP/KYC: HMAC+mTLS+anti-replay+allow-list.
• Requisiti regionali e TTL per i dati sensibili.

17) TL; DR

Creare una protezione a strati: filtri edge e challenge precoci, API Risk centralizzata con regole + ML e flusso di eventi per il feedback. Utilizzare limiti velocity, segnali di rete/device/comportamento, challenge dinamico (captcha/PoW/OTP/WebAuthn). Prendere le decisioni allow/deny/challenge/throttle, misurare FP/FN e effetti aziendali, sfoggiare attraverso shadow/canary. Per i percorsi di pagamento/bonus, i singoli profili rigidi e il collegamento con KYC/AML.