Bot-Schutz und Anti-Fraud-API

1) Warum es notwendig ist

Bots und Angreifer greifen die Einstiegspunkte von Wachstum und Geld an: Registrierung, Login (ATO), Ein-/Auszahlungen, Promo-Mechanik, Spiel-/Quotenkataloge. Manuelle Regeln und ein reines Ratenlimit reichen nicht mehr aus: Wir brauchen mehrstufige Signale, Echtzeit-Scoring und Entscheidungssteuerung (allow/deny/challenge/throttle) mit Feedback aus Geschäftsereignissen (Chargebacks, Chargeback-Ratio, KYC-Fails).

2) Taxonomie der Bedrohungen

Registrierung/Onboarding: Massenkonten, einmalige E-Mail/SIM-Banken, Farmen von Geräten.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
Bonus-Missbrauch: Multi-Akkuuting, Geo/Gerichtsbarkeit Arbitrage, Selbstausschluss Umgehung.
Kart-/Zahlungsbetrug: Kartentest, gestohlene Geldbörsen, Rückerstattungen.
Scraping/Inventar: aggressives Ziehen von Inhalten, Preisen, Quoten.
Low Intensity API-DoS: Schildkrötenangriffe, Slow-POST, mobile SDK-Emulationen.
Webhooks/Integrationen: Fälschung von Benachrichtigungen ohne HMAC/mTLS, replay.

3) Schutzarchitektur

3. 1 Schichten

1. Edge (CDN/WAF/Gateway): frühe Ausfälle (ASN/Geo/IP Reputation), leichte Herausforderungen, Limits, PoW.
2. Risk API (Risiko-PDP): zentralisierte Regel-/ML-Engine; ответ — `decision`, `score`, `reason`, `ttl`.
3. App-Ebene: Domäneninvarianten, Geschäftslogik (Limits, KYC, AML), asynchrone Reviews.
4. Ereignisablauf: Kafka/Kinesis → Feature Store/Modell → Feedback von Zahlungen/Disputen.

3. 2 Lösungskontur

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

Die Lösung wird nach einem Schlüssel (z.B. device × account × route) für 'ttl' Sekunden zwischengespeichert.

4) Signale und Anreicherung

Netzwerk/Kanal: IP/ASN, Proxy/VPN/Tor, rdns, rtt/jitter, SYN-Rate, TLS-Fingerprint (JA3/JA4), HTTP/2/3 Verhalten.
Gerät/Browser: canvas/audio/WebGL FP (sorgfältig), Plattform/SDK, timezone/locale, Auflösung, Schriftarten, WebDriver/headless Indikatoren, mobile attestation (SafetyNet/DeviceCheck, wenn möglich).
Verhalten: Eingabegeschwindigkeit, Maus-/Touchtrajektorien, Bildschirmsequenz, Dwell-Time, Häufigkeit der Versuche, Übergänge zwischen Browser-IDs.
Inhalt/Anfrage: E-Mail-Formular/Domain, Disposable-Anbieter, Telefon HLR/oder Nummerntyp, BIN-Karte, Konto/IBAN in Sank-Registern, Namens-/Adressähnlichkeit.
Konto/Geschichte: Alter des Kontos, KYC-Status, Retention, ARPPU, Velocity für Einzahlungen/Schlussfolgerungen/Boni.
Externe Quellen: Kompromittierungslisten (HIBP-like), Payment Risk Signals (PSP), ASN Reputation.

5) Lösung: Regeln + ML

5. 1 Regeln (deterministisch)

Velocity: „N Registrierungen mit/24 in 10 Minuten“, „M Logins mit einem Gerät zu X Konten“, „K 3DS-Fails in Folge“.
Geo/Gerichtsbarkeit: IP-Geo vs Adresse/Dokument Konflikte, plötzliche Standortsprünge.
Geschäftsinvarianten: Grenzen für verantwortungsvolle Zahlungen, Selbstausschluss, Sanktionslisten.

5. 2 ML-Scoring (Real-Time)

Leichtbaumodell (GBM/logreg) auf Online-Zeichen: 'ip _ risk', 'device _ age', 'account _ age', 'pwd _ fail _ rate', 'bin _ risk', 'velocity _', 'behavioral _'.
Separates Modell für ATO und separat für Zahlungen/Auszahlungen.
Segmentierung nach Jurisdiktion/Tenant (Per-Market-Kalibrierung von Schwellenwerten).

5. 3 Entscheidung treffen

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

Bei 'Herausforderung' Fakten des Passierens/Scheiterns speichern; Reibung dynamisch eskalieren/reduzieren.

6) Velocity und Quoten (Schlüssel und Fenster)

Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
Fenster: schiebbar (1m/5m/1h/24h) + einzelne „burst „/„ nachhaltig “.
Politiker: „hart“ deny auf heißen Routen (Login/Einzahlung), weiche Throttle auf Inhalten.

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) Herausforderungen und Prüfung der „Menschlichkeit“

CAPTCHA/turnstile: как soft-challenge; Reinigung nach hohem Vertrauen in die „saubere“ Sitzung.
Proof-of-Work (PoW): für APIs/Skripte - Berechnen Sie den Hash mit der angegebenen Komplexität; dynamische Komplexität bei steigender Belastung.
OTP/SMS/Email/Push: für ATO/kritische Operationen; nicht missbrauchen (Kosten/UX).
WebAuthn/Biometrie: Hohes Vertrauen in Cash-Out/Änderung von Auszahlungsteilen.
Device Trust: Bind des Kontos zum verifizierten Gerät; Die neue → Challenge.

8) Integration in Gateway/Proxy

8. 1 Envoy: 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: leichtes PoW und 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 Vertrag

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) Daten, Daten und Modelle

Feature Store (online): Redis/Scylla/KeyDB - Zähler/Velocity/Zeitstempel.
Batch/offline: DWH (BigQuery/S3 + Athena) für Training/Refits; Speichern Sie Abfluss-Tags, Chargeback, manuelle Revue.
Modelle: einfach für Echtzeit (logreg/GBM); heavy (XGBoost/NN) - offline mit PGMs/Scaling und anschließender Destillation.
Driftkontrolle: PSI, AUC/PR, Kalibration der Schwellen nach Region/Kanal.

11) Beobachtbarkeit und Operationskontur

• `risk_requests_total{route,decision}`
• `risk_score_bucket` (distribution)
• `waf_block_total`, `velocity_block_total`, `challenge_pass_rate`
• `ato_incidents`, `carding_detected`, `cashout_denied`
• Geschäftskennzahlen: 'chargeback _ rate', 'bonus _ abuse _ rate', 'false _ positive _ rate'
• Protokolle (bearbeitet): 'decision', 'score', key signals, 'trace _ id', ohne PII/Geheimnisse.
• A/B und Schatten: neue Richtlinie im Schattenmodus (wir protokollieren Entscheidungen), dann kanarisch (1-5%), autorollback durch SLO/FP.
• Playbooks: Eskalation, vorübergehende Verschärfung, Rollback, „virtuelle Patches“.

12) Privatsphäre und Compliance

Minimieren Sie PII; Hash stabile IDs (z. B. E-Mail- SHA-256 mit Salz).
Respektieren Sie die regionale Rechtsprechung (Datenlokalisierung, Einwilligungen).
Transparente Erklärungen von Lösungen für manuelle Revuen; nur das Notwendige und mit TTL aufbewahren.

13) Spezifität von iGaming/Finanzen

Registrierung: Filter disposable E-Mail/VoIP, velocity durch/24, Gerät-Farm → Herausforderung/deny.
Login/ATO: neue Geräte/Geo-Sprünge → OTP/WebAuthn; password spraying → throttle/deny.
Boni: Grenzen für den „Weg zur Wäsche“ (depozit→bonus→minimalnyy oborot→vyvod), Graph-Analyse der Zugehörigkeit (Adressen/Geräte/Karten).
Zahlungen/Schlussfolgerungen: BIN-Risiko, Country-Mismatch, PSP-Signale; Cashout auf das neue Instrument → eine hohe Schwelle und Check-up KYC.
PSP/KYC Webhooks: HMAC + mTLS, schmales IP-Allow-Blatt, Anti-Replay ('X-Timestamp', Fenster ± 5 min).

14) Antipatterns

Ein universelles Captcha „überall und immer“ → ein hoher FP/Conversion-Drop.
Nur Rate Limit ohne Verhaltens-/Gerätesignale.
Speicherung von „rohen“ Drucken und PII auf unbestimmte Zeit.
Kein Schattenlauf und kein Kanarenlauf für neue Politiker.
Volles Vertrauen in externe „Reputation“ -Tags ohne eigene Validierung.
Entscheidungsfindung auf dem Client (JS/mobile SDK) ohne Servervalidierung.

15) Regelbeispiele und Pseudocode

15. 1 Zusammengesetzte Regel (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 Verknüpfungsgraph (Multiaccount)

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

16) Checkliste Prod-Ready

• Mehrstufige Architektur: Edge → Risk API → App, Ereignisablauf.
• Signale: Netzwerk, Gerät, Verhalten, Inhalt, Zahlung; Minimierung der PII.
• Velocity/GCRA on ip/device/account/payment keys, sliding windows.
• Lösungen: allow/deny/challenge/throttle; Entscheidungscache mit TTL; Die Fakten der Herausforderungen.
• Herausforderungen: captcha/PoW/OTP/WebAuthn; dynamische Komplexität.
• Risk API: SLA <100ms, Cache, Degradation in den „minimal sicheren“ Modus.
• Beobachtbarkeit: Risk Metrics, FP/FN, Dashboards, Alerts; Geschäftsmetriken (Chargeback/Bonus-Missbrauch).
• Shadow → canary → enforce; Eskalations- und Rollback-Playbooks.
• PSP/KYC Webhooks: HMAC + mTLS + anti-replay + allow-list.
• Regionale Anforderungen und TTL für sensible Daten.

17) TL; DR

Erstellen Sie einen geschichteten Schutz: frühe Edge-Filter und Herausforderungen, eine zentralisierte Risk-API mit + ML-Regeln und einen Ereignisfluss für Feedback. Verwenden Sie Velocity-Limits, Netzwerk-/Geräte-/Verhaltenssignale, dynamische Herausforderungen (Captcha/PoW/OTP/WebAuthn). Treffen Sie Entscheidungen allow/deny/challenge/throttle, messen Sie FP/FN und Geschäftseffekt, rollen Sie durch Schatten/Kanal. Für Zahlungs-/Bonuswege gibt es separate verschärfte Profile und eine Verknüpfung mit KYC/AML.