Bot Proteção e API antifrode

1) Por que é necessário

Bots e atacantes atacam pontos de entrada de crescimento e dinheiro: registro, login (ATO), depósitos/conclusões, mecânica promocional, catálogos de jogos/coeficientes. As regras manuais e rate limit limpo já são insuficientes, sendo necessários sinais de vários níveis, mapeamento em tempo real e controle de solução (allow/deny/challenge/throttle) com feedback de eventos de negócios (charjbacks, chargeback-ratio, KYC-feel).

2) Taxonomia de ameaças

Check-in/Internet: contas de massa, e-mails descartáveis/bancos SIM, quintas de valores.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
Bónus-abuse: multicautagem, arbitragem geo/jurisdição, self-exclusion contornação.
Kart/frod de pagamento: teste de cartões, carteiras roubadas, reembolsos.
Screeping/inventário: extração agressiva de conteúdo, preços, coeficientes.
API-DoS de baixa intensidade: ataques de tartaruga, slow-POST, emulações de SDK móvel.
Webhooks/integração: falsificação de notificações sem HMAC/mTLS, replay.

3) Arquitetura de proteção

3. 1 Camadas

1. Edge (CDN/WAF/passarela): falhas iniciais (ASN/Geo/reputação IP), ligeiros, limites, PoW.
2. Risk API (PDP de risco): motor central de regras/ML; ответ — `decision`, `score`, `reason`, `ttl`.
3. Nível App: invariantes de domínio, lógica de negócios (limites, KYC, AML), reviravoltas asincrônicas.
4. Fluxo de eventos: Kafka/Kinesis → função store/modelo → feedback de pagamentos/displays.

3. 2 Caminho de solução

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

A solução é armazenada por uma chave (por exemplo, device x score x road) em 'ttl' segundos.

4) Sinais e enriquecimento

Rede/canal: IP/ASN, proxy/VPN/Tor, rdns, ptt/jitter, SYN-rate, fingerprint (JA3/JA4), HTTP/2/3 comportamento.
Device/navegador: canvas/audio/WebGL FP (poupado), plataforma/SDK, timezone/local, resolução, fontes, indicadores WebDriver/headless, mobile attation (SafetyNet/DeviceCheck, se possível).
Comportamento: velocidade de entrada, trajetória do mouse/tecla, seqüência de telas, dwell-time, frequência de tentativas, transições entre os navegadores.
Conteúdo/consulta: formulário de e-mail/domínio, provedores de armazenamento, phone HTR/ou tipo de número, cartão BIN, conta/IBAN em registros de sank, semelhante FIO/endereços.
Conta/histórico: idade da conta, status KYC, retenha, ARPU, velocidade de depósito/conclusão/bónus.
Fontes externas: listas de comprometimento (HIBP-similares), sinais de risco de pagamento (PSP), reputação ASN.

5) Solução: regras + ML

5. 1 Regras (determinadas)

Velocity: «N inscrição s/24 em 10 min», «M logins com uma única conta X», «K 3DS feeds consecutivos».
Geo/jurisdição: conflitos IP-geo vs endereço/documento, saltos repentinos de localização.
Invariantes de negócios: limites de pagamento responsável, self-exclusion, listas de sanções.

5. 2 montagens ML (real-time)

Modelo leve (GBM/logreg) nos sinais online: 'ip _ risk', 'device _ age', 'account _ age', 'pwd _ fail _ rate', 'bin _ risk', 'velocity _', 'behavioral _'.
Modelo separado para ATO e separadamente para pagamentos/conclusões.
Segmentação por jurisdição/tenante (para-mercado calibrar liminares).

5. 3 Tomada de decisão

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

No 'challenge', armazenar os factos de passar/falhar; escalar e reduzir a fricção de forma dinâmica.

6) Velocity e quotas (chaves e janelas)

Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
Janelas: deslizantes (1m/5m/1h/24h) + individuais «burst «/« sustained ».
Políticas: deny «rígido» em rotas quentes (login/depósito), throttle suave no conteúdo.

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) Challengs e teste de «humanidade»

CAPTCHA/turnstile: как soft-challenge; limpar depois da alta confiança na sessão «limpa».
Proof-of-Work (PoW): para API/script - calcular o hash com a complexidade definida; dificuldade dinâmica quando a carga aumenta.
OTP/SMS/Email/Push: para ATC/operações críticas; não abusar (custo/UX).
WebAuthn/biometria: alta confiança em cash-out/alteração de peças payout.
Device trust: bind conta para o lema verificado; os novos device do → challenge.

8) Integração em gateway/proxy

8. 1 Envoy: ext _ athz → 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: PoW leve e velocidade

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 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) Dados, fichas e modelos

Função Store (on-line): Redis/Scylla/KeyDB - Contadores/velocity/rótulos de tempo.
Batch/offline: DWH (BigQuery/S3+Athena) para treinamento/refit; guarde os rótulos de saída, chargeback, remo manual.
Modelos: simples para real-time (logreg/GBM); (pesados (XGBoost/NN) - offline com PGMs/escalonamento e posterior destilação.
Controle de Drift: PSI, AUC/PR, alíquota de limiar por região/canal.

11) Observabilidade e contorno operacional

• `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 negócios: 'chargeback _ rate', 'bônus _ abuse _ rate', 'falso _ positivo _ rate'
• Logs (editados): «decise», «score», sinais-chave, «trace _ id», sem PII/segredos.
• A/B e Shadow: nova política em shadow-modo (logando soluções), depois canary (1-5%), auto-roll SLO/FP.
• Playbooks: escalação, endurecimento temporário, retrocesso, patches virtuais.

12) Privacidade e conformidade

Minimize o PII; hasteie os identificadores sustentáveis (por exemplo, o email SHA-256 com sal).
Respeite a jurisdição regional (localização de dados, consentimento).
Explicações transparentes para as soluções manuais; guarde apenas o necessário e com TTL.

13) Especificidades do iGaming/Finanças

Registro: filtros de disposable e-mail/VoIP, velocity por/24, quinta de device → challenge/deny.
Login/ATO: Novos slides/saltos geo → OTP/WebAuthn; password spraying → throttle/deny.
Bônus: limites para «caminho da lavagem» (depozit→bonus→minimalnyy oborot→vyvod), análise graph de afiliação (endereços/devis/cartões).
Pagamentos/conclusões: Risco BIN, country-mismatch, PSP; cashout para a nova ferramenta → limite alto e check KYC.
Webhooks PSP/KYC: HMAC + mTLS, folha IP-allow estreita, anti-replay ('X-Timestamp', janela de £5 min).

14) Antipattern

Um captcha universal «em todos os lugares e sempre» → alta FP/queda de conversão.
Apenas rate limit sem sinais comportamentais/devis.
Armazenamento de impressões digitais «cruas» e PII indefinidamente.
Falta de shadow-testing e canary para novas políticas.
Confiança total nas marcas de reputação externas sem validação.
Tomar decisões em um cliente (JS/SDK móvel) sem verificação de servidor.

15) Exemplos de regras e pseudocode

15. 1 Regra composta (real-tempo)

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 Gráficos de ligações (multiaccount)

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

16) Folha de cheque pró-prontidão

• Arquitetura em vários níveis: Edge → Risk API → App, fluxo de eventos.
• Sinais: rede, definição, comportamento, conteúdo, pagamento; Minimizar o PII.
• Velocity/GCRA nas chaves ip/device/account/payment, janelas deslizando.
• Soluções: allow/deny/challenge/throttle; A caixa de soluções com TTL; Um cofre de factos.
• Challengs: captcha/PoW/OTP/WebAuthn; complexidade dinâmica.
• Risk API: SLA <100 ms, dinheiro, degradação no modo «mínimo seguro».
• Observabilidade: métricas de risk, FP/FN, dashboards, alertas; métricas de negócios (chargeback/bônus-abuse).
• Shadow → canary → enforce; playbooks de escalação e reversão.
• Webhooks PSP/KYC: HMAC+mTLS+anti-replay+allow-list.
• Requisitos regionais e TTL para dados sensíveis.

17) TL; DR

Construa protecção de camadas com filtros edge e challengs iniciais, um Risk API centralizado com regras + ML e fluxo de eventos para feedback. Use os limites velocity, os sinais de rede/comportamento, o challenge dinâmico (captcha/PoW/OTP/WebAuthn). Tome as decisões allow/deny/challenge/throttle, mede o FP/FN e o efeito empresarial, divulga através do shadow/canary. Para os caminhos de pagamento/bónus, perfis individuais mais rigorosos e conexão com KYC/AML.