Web Aplicação Firewall e proteção contra ataques

Resumo curto

WAF/WAAP filtra e controla HTTP (S )/WebSocket Tráfego ao nível do aplicativo: bloqueia a operação de vulnerabilidades (OWASP Top 10), tentativas de contornação de autenticação, digitalização, tráfego de bot automatizado e L7 DDoS. A pilha moderna é complementada por um motor anti-bot, uma API, rate limiting, patches virtuais, e uma integração estreita com o CI/CD, para que as regras rolem de forma segura como o código.

Papéis e espaço na arquitetura

Edge/CDN WAF (nuvem): baixa latência, reputação global/Managed Rulas, L7 DDoS.
Self-hosted WAF (on-prem/K8s): integração profunda com redes internas, configuração fina.
WAAP-WAF + API-Gateway funções (schema-validação, authZ), anti-bot, L7 DoS, mTLS.
Esquemas de inclusão: Reverse-proxy antes do aplicativo; Controlador de Insress em K8s; Filtros Serviço Mesh; sidecar.

Modelo de proteção

Negative security (assinaturas/CRS): revestimento rápido de técnicas conhecidas (SQLI/XSS/SSRF/RCE).
Positivo security (allow-list): Permitimos apenas consultas «validas» (métodos/caminhos/esquemas/tipos de conteúdo).
Virtual Patching: bloqueia o expoente em tempo real até o fixo de código.
Contextualidade: políticas diferentes para conteúdo estático, API, almirante, downloads, webhooks.

Ameaças e medidas típicas

OWASP Top 10: SQLI, XSS, IDOR/BOLA, SSRF, injeções em modelos, deserialização, misconfigs.
L7 DDoS: perguntas lentas/títulos, burst para endpoint quentes → proteção: rate-limits, challenge, bloco automático.
Bots/screepers: comportamento, frequência, pattern «não-humanos», device-fingerprinting, tokens dinâmicos.
Credential Stuffing/ATO: interceptação/excesso de loginas → anomalia por IP/ASN, velocity rulas, fatores adicionais.
Downloads: tipo/tamanho/multiplicado por antivírus, «image-only» em mídia.
API/GraphQL: schema-validação, 'maxDepth '/' maxCost', proibição de wildcard indetectável, controle de métodos e títulos.

Políticas e estruturas de regras

1. Transporte: TLS 1. 2+/1. 3, HSTS, mTLS em backends sensíveis.

2. Os métodos: 'GET, POST, PUT, DELETE, PATCH, OPÇÕES' são exclusivos para o recurso.

3. Caminhos: máscaras e regexos rigorosos; adminka/billing - para um prefixo/domínio separado.

4. Cabeçalhos: listas brancas, proibir perigosos ('X-Original-URL', não convencionais), sem necessidade.

5. Corpos: JSON-only/Multipart-only na rota; os limites de 'Conteúdo-Length', bloco de binários para 'login/busca'.

6. Rate limits: per-IP/ASN/chave/organização; limites individuais para solicitações «caras».

7. Anti-bot: acervo comportamental, «não-brilhantes», pente de identidade (cookie-tokens, JA3/TLS FP).

8. CRS/Managed Rales: incluídos, sintonizando para FP.

9. Virt Patchi: bloqueio rápido de parâmetros/modelos de ataque conhecidos.

10. Logs/métricas: formato único, correlação com 'trace _ id', relatórios FP/TP.

Prática de sintonização: como reduzir falsos efeitos

Iniciar novas regras no Detect-only/Count-modo (shadow) com amostra de tráfego.
Criar exceções por contexto ('path =/search', 'param = q' permitir operações especiais).
Dividir área: «páginas públicas» vs «operações sensíveis» (limite de agressividade diferente).
Linha de montagem: regra → stage → canário (1-5%) → proda; rollback por métricas FP.
Conduzir o catálogo «falso» payload para testes de regressão.

Integração em DevSecOps

CI: regras estáticas em Git; testes: réplicas de pesquisas reais + sintético do catálogo de ataques.
CD: canários, bandeiras de fitas; monitoramento «político» (alteração de regras = mudança).
RASP e SAST/DAST: O WAF complementa, mas não substitui, a correção do código.

Observabilidade e SLO

• p95/99 latência via WAF; Proporção de bloqueados/omitidos; share Managed Rules vs custom; «attack rate».
• Anti-bot: Parte de desafio/troco, FP/TP.
• L7 DDoS: burst-rate, auto-mitigation events.

• "Não mais do que 0. 5% FP para operações/24 horas autorizadas ".
• «p95 overhead WAF ≤ 10 мс».
• «TTR patch virtual ≤ 30 minutos».
• Alarmes: surto 4xx/5xx após o lançamento das regras; Crescimento da FP; queda da passagem de caph; degradação JWKS/mTLS-validação.

Exemplos de configuração

ModSecurity + OWASP CRS (Nginx)

nginx
Enabling ModSecurity modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main. conf;

apache
SecRuleEngine On
Include /usr/local/owasp-modsecurity-crs/crs-setup. conf
Include /usr/local/owasp-modsecurity-crs/rules/.conf

Example of an exception for a search parameter
SecRule REQUEST_URI "@beginsWith /search" "id:900100,phase:1,pass,nolog,ctl:ruleRemoveByTag=attack-xss"
SecRule REQUEST_URI "@beginsWith /search" "id:900101,phase:2,pass,ctl:ruleRemoveTargetById=942100; ARGS:q"

AWS WAF (JSON, rate limit + bloco de lista de países)

json
{
"Name": "prod-web-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "BurstLogin",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": { "ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
"PositionalConstraint": "CONTAINS"
}}
}
},
"Action": { "Block": {} },
"VisibilityConfig": { "MetricName": "BurstLogin", "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true }
}
]
}

Cloudflare (Expression Rules)

(http. request. uri. path contains "/admin" and ip. geoip. country ne "UA")
or (http. request. uri. path eq "/login" and cf. threat_score > 10)
or (http. request. uri. path contains "/api" and not http. request. headers["authorization"][0] contains "Bearer ")

NGINX: regra simples sobre métodos/corpos

nginx location /api/withdraw {
limit_except POST { deny all; }
if ($request_method = POST) {
set $cl $http_content_length;
if ($ cl = "") {return 411;} # length is required if ($ cl> 1048576) {return 413;} # ≤ 1MB add_header X-Idempotency-Required "true";
}
}

GraphQL: limitadores

«maxDepth=6», «maxCost=1000», «__ schema» em venda, «allow-list», validação de cabeçalhos.

Anti-bot e verificações amigáveis

Invisível challenge (JS-challengs sem capchi), proof-of-work em caminhos «caros», analista comportamental (movimento/timing).
TLS/JA3-fingerprinting, IP/ASN reputação, listas de proxy/VPN (dentro de limites razoáveis).
Armadilhas (campos honeypot) em formulários, toques dinâmicos de forma/sessão.
Proteção da privacidade: minimização do tracking, políticas transparentes, opções opt-out.

Foco de API

Schema-first: OpenAPI/JSON Schema para validação; a proibição de campos extras.
Auth: Necessariamente Bearer JWT ou mTLS; reject без `Authorization`.
Rate/Quota: per-key/per-org; quando ultrapassado, «soft block «/slowing.
Webhooks: assinatura HMAC, 'timestamp + nonce', uma janela de recepção curta.
GraphQL: Consulte os limitadores acima; logar o nome/marca da operação.

Downloads e mídia

Limite de tamanho, whitelistas MIME/extensões, renomear arquivos;

Skan AV (multi-motores), policy ImageMagick (sem decodificadores perigosos);

Serviço Thumb em domínio separado, serve-only-images.

Segurança de almirantes e áreas críticas

Domínio/caminho separado, mTLS/proibição com ASN/países compartilhados, rate limits rígidos, JIT acessíveis, IP allow-list.
Os sinais adicionais (device posture, risk score) → exigir uma segunda verificação.

Operações, incidentes e patches virtuais

Runbook: saída rápida da regra block, limitação TTL, notificação de comandos.
Critérios de reversão: 4xx/5xx> limite, FP> limiar, p95 latency↑.
Post-mortem: adição de um teste no conjunto de regras de regressão, fixação do SIGMA-alert no SIEM.

Complacência e privacidade

Logar o mínimo: caminho/método/código/causa do bloco/identificadores; não guardar PII/segredos corporais.
Prazo de armazenamento dos logs de política; Acesso - por papéis; criptografia em disco.

Características para iGaming/Fintech

Pagamentos/pagamentos/carteiras: per-org quotas, mTLS para PSP, caminhos de alow rígidos, HMAC para webhooks PSP.
ATO/bónus-abuse: regras velocity para login/registro/moagem, limites comportamentais e anti-bot.
Provedores de conteúdo/estúdios: domínios/políticas individuais, IP/ASN allow-list, monitoramento do Time-to-Wallet/Conversões sobre o impacto da WAF.
Exigências regionais: geo-políticas (países/regiões), transparência de ganhos para GDPR.

Mapa de tráfego de implementação

1. Inventário de áreas (público, API, adminca, downloads).
2. Perfil básico: TLS, métodos/caminhos de allow-list, Managed Rulas/CRS.
3. Rate limits + anti-bot em vias sensíveis.
4. Patches virtuais e regras de urgência (SLA ≤ 30 min).
5. CI/CD para regras, stage/canário/shadow-modo.
6. Telemetria, SLO, testes de regressão.
7. Review periodicamente exceções e «limpar» as rondas.

Erros típicos

«Todos os CRS foram incluídos no máximo» → avalanche FP e incineração do comando.
Regras sem canarinhos ou modo shadow.
Falta de segmentação: uma política para tudo.
Ignorar API/GraphQL especificidades (schema/limits).
Logs sem correlação ('trace _ id') e sem métricas de qualidade.

FAQ

O WAF substitui o código seguro?
Não. É uma camada de flexibilização e «patch virtual», mas é obrigatório eliminar o código técnico.

Como saber que está na hora de ligar os blocos duros?
Quando o relatório de modo shadow mostra FP baixo e há testes de regressão de regras.

Será necessário um WAF separado para a API?
Melhor WAAP/integração com a entrada API: esquema, limites, autenticação, assinaturas de webhooks.

Resultado

O WAF/WAAP eficiente é uma combinação de CRS/Managed Rales básicos, modelo positivo, anti-bot, limites e patches virtuais, apoiado em processos de DevSecOps, telemetria e SLO nítidos. Esta abordagem permite uma resposta rápida às vulnerabilidades, à resistência a ataques automatizados e ao impacto previsível no UX e no desempenho.