Bot Protection y la API antifraude

1) Por qué es necesario

Bots y atacantes atacan los puntos de entrada de crecimiento y dinero: registro, inicio de sesión (ATO), depósitos/retiros, mecánica promocional, catálogos de juegos/coeficientes. Las reglas manuales y el límite de puntuación puro ya no son suficientes: se necesitan señales en niveles, puntuación en tiempo real y control de la solución (allow/deny/challenge/throttle) con retroalimentación de eventos empresariales (charjbacks, chargeback-ratio, KYC-feiles).

2) Taxonomía de amenazas

Check-in/onboarding: cuentas masivas, bancos de correo electrónico/SIM desechables, granjas de dispositivos.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
Bonus Abuse: multiackouting, arbitraje geo/jurisdicciones, auto-exclusión de elusión.
Kart/Food de pago: prueba de tarjetas, carteras robadas, reembolsos.
Scraping/inventario: tirando agresivamente del contenido, de los precios, de los coeficientes.
API-DoS de baja intensidad: ataques de tortugas, slow-POST, emulaciones de SDK móviles.
Webhooks/integraciones: falsificación de notificaciones sin HMAC/mTLS, replay.

3) Arquitectura de protección

3. 1 Capas

1. Edge (CDN/WAF/gateway): fallos tempranos (ASN/Geo/reputación IP), retos ligeros, límites, PoW.
2. API de riesgo (PDP por riesgo): motor centralizado de reglas/ML; ответ — `decision`, `score`, `reason`, `ttl`.
3. Nivel de aplicación: invariantes de dominio, lógica de negocio (límites, KYC, AML), rugido asíncrono.
4. Flujo de eventos: Kafka/Kinesis → feature store/modelo → comentarios de pagos/disputs.

3. 2 Esquema de solución

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

La solución se almacena en caché por clave (por ejemplo, device × account × route) durante 'ttl' segundos.

4) Señales y enriquecimiento

Red/canal: IP/ASN, proxy/VPN/Tor, rdns, rtt/jitter, tasa SYN, huella dentada TLS (JA3/JA4), comportamiento HTTP/2/3.
Device/navegador: canvas/audio/WebGL FP (cuidadosamente), plataforma/SDK, timezone/locale, resolución, fuentes, indicadores WebDriver/headless, mobile attestation (SafetyNet/DeviceCheck, si es posible).
Comportamiento: velocidad de entrada, trayectorias mouse/touch, secuencia de pantalla, dwell-time, frecuencia de intento, transiciones entre identificadores de navegador.
Contenido/solicitud: formulario de correo electrónico/dominio, disposable-proveedores, teléfono HLR/o tipo de número, tarjeta BIN, cuenta/IBAN en los registros de Sank, FIO/direcciones similares.
Cuenta/historial: edad de la cuenta, estado KYC, retiro, ARPPU, velocity por depósitos/retiros/bonos.
Fuentes externas: listas de compromiso (similares a HIBP), señales de riesgo de pago (PSP), reputación ASN.

5) Solución: reglas + ML

5. 1 Reglas (deterministas)

Velocity: «N inscripciones con/24 en 10 min», «M de inicio de sesión con un solo dispositivo a X cuentas», «K 3DS-files seguidas».
Geo/jurisdicción: conflictos IP-geo vs dirección/documento, saltos de ubicación repentinos.
Invariantes empresariales: límites de pagos responsables, autoliquidación, listas sancionadoras.

5. 2 ML-scoring (tiempo real)

Modelo ligero (GBM/logreg) en las características en línea: 'ip _ risk', 'device _ age', 'account _ age', 'pwd _ fail _ rate', 'bin _ risk', 'velocity _', 'behavioral _'.
Modelo separado para ATO y por separado para pagos/retiros.
Segmentación por jurisdicción/tenante (calibración de umbral de mercado per).

5. 3 Decisión

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

Al 'desafío' almacenar los hechos del paso/fracaso; escalar/reducir la fricción dinámicamente.

6) Velocity y cuotas (llaves y ventanas)

Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
Ventanas: deslizantes (1m/5m/1h/24h) + individuales «burst «/« sustained ».
Políticas: «duro» deny en las rutas calientes (inicio de sesión/depósito), suave throttle en el contenido.

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) Desafíos y verificación de la «humanidad»

CAPTCHA/turnstile: как soft-challenge; limpiar después de una alta confianza en una sesión «limpia».
Proof-of-Work (PoW): para API/scripts - calcular el hash con la complejidad especificada; complejidad dinámica en el crecimiento de la carga.
OTP/SMS/Email/Push: para ATO/operaciones críticas; no abusar (costo/UX).
WebAuthn/Biometría: alto nivel de confianza en las piezas de pago/cambio.
Device trust: bind de la cuenta al dispositivo verificado; nuevos dispositivos → desafío.

8) Integración en 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: ligero PoW y 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) Contrato de la API de Risk

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) Datos, fichas y modelos

Feature Store (en línea): Redis/Scylla/KeyDB - contadores/velocity/marcas de tiempo.
Batch/offline: DWH (BigQuery/S3 + Athena) para entrenamiento/refits; almacene las marcas de salida, chargeback, rugido manual.
Modelos: simple para real-time (logreg/GBM); pesado (XGBoost/NN) - fuera de línea con PGMs/escala y posterior destilación.
Control de deriva: PSI, AUC/PR, calibración de umbrales por regiones/canales.

11) Observabilidad y circuito 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`
• métricas de negocio: 'chargeback _ rate', 'bonus _ abuse _ rate', 'false _ positive _ rate'
• Logs (editados): 'decision', 'score', señales clave, 'trace _ id', sin PII/secretos.
• A/B y Shadow: nueva política en modo shadow (lógica de la solución), luego canario (1-5%), autorollback por SLO/FP.
• Playbooks: escalada, apriete temporal, retroceso, «parches virtuales».

12) Privacidad y cumplimiento

Minimice el PII; hash identificadores sostenibles (por ejemplo, correo electrónico SHA-256 con sal).
Respetar la jurisdicción regional (localización de datos, consentimiento).
Explicaciones transparentes para soluciones de rugido manual; almacene sólo lo necesario y con TTL.

13) Especificidad de iGaming/finanzas

Registro: filtros disposable e-mail/VoIP, velocity por/24, granjas de device → challenge/deny.
Login/ATO: nuevos dispositivos/geo-saltos → OTP/WebAuthn; password spraying → throttle/deny.
Bonificaciones: límites de «camino al lavado» (depozit→bonus→minimalnyy oborot→vyvod), análisis graph de afiliación (direcciones/dispositivos/tarjetas).
Pagos/conclusiones: riesgo BIN, país-mismatch, señales PSP; cashout a la nueva herramienta → alto umbral y cheque KYC.
Webhooks PSP/KYC: HMAC + mTLS, hoja IP-allow estrecha, anti-replay ('X-Timestamp', ventana ± 5 min).

14) Antipattern

Un captcha universal «en todas partes y siempre» → alta FP/caída de conversión.
Sólo rate limit sin señales de comportamiento/device.
El almacenamiento de las impresiones «crudas» y PII es indefinido.
No hay shadow-running y canary para nuevas políticas.
Confianza total en las marcas «reputacionales» externas sin validación propia.
Toma de decisiones en el cliente (JS/SDK móvil) sin revisión del servidor.

15) Ejemplos de reglas y pseudocódigo

15. 1 Regla compuesta (tiempo 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 Grafo de conexiones (multiaccount)

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

16) Lista de comprobación prod

• Arquitectura multinivel: Edge → Risk API → App, flujo de eventos.
• Señales: red, dispositivo, comportamiento, contenido, pago; minimización de PII.
• Velocity/GCRA en las claves ip/device/account/payment, ventanas deslizantes.
• Decisiones: allow/deny/challenge/throttle; caché de soluciones con TTL; repositorio de hechos Challenge.
• Challenges: captcha/PoW/OTP/WebAuthn; complejidad dinámica.
• API de riesgo: SLA <100 ms, caché, degradación en modo «mínimamente seguro».
• Observabilidad: métricas risk, FP/FN, dashboards, alertas; métricas de negocio (chargeback/bonus-abuse).
• Shadow → canary → enforce; playbucks de escalamiento y retroceso.
• Webhooks PSP/KYC: HMAC + mTLS + anti-replay + allow-list.
• Requisitos regionales y TTL para datos sensibles.

17) TL; DR

Construya una protección en capas: filtros edge y challenges tempranos, una API centralizada de Risk con reglas + ML y un flujo de eventos para retroalimentación. Utilice los límites de velocidad, señales de red/dispositivo/comportamiento, desafío dinámico (captcha/PoW/OTP/WebAuthn). Tomar decisiones allow/deny/challenge/throttle, medir FP/FN y el efecto de negocio, rodar a través de shadow/canary. Para las rutas de pago/bonificación - perfiles individuales apretados y un conjunto con KYC/AML.