WAF e DDoS na Cloudflare: o que realmente precisa de regra personalizada

Os rulesets gerenciados da Cloudflare bloqueiam os padrões de ataque conhecidos assim que são ativados: injeção SQL, cross-site scripting, todo o top ten da OWASP, coberto de fábrica. Esse é o piso, e é um piso real. Também está longe de ser o trabalho inteiro.

A lacuna é o que é próprio da sua aplicação: o endpoint interno de API cujo formato de payload parece estranho pra uma regra genérica e é completamente normal pra aquela integração específica, o fluxo de login que precisa do próprio limite de taxa porque o padrão gerenciado foi ajustado pro site médio, não pro seu.

As regras gerenciadas são o piso, não o teto

Situação	Ruleset gerenciado	O que fecha a lacuna de verdade
Uma tentativa genérica de injeção SQL ou XSS	Bloqueia	Nada mais é necessário
Uma API interna com payload incomum mas legítimo	Pode dar falso positivo	Uma regra personalizada limitada àquela rota
Um login sob credential stuffing	Cobertura parcial	Um limite de taxa ajustado ao seu volume real de login, não um padrão
Um padrão de bot específico atacando o checkout	Bot Management pontua	Uma regra que age sobre a pontuação, não só registra

As duas linhas do meio são onde mora a maior parte do trabalho real, e são exatamente as que um padrão pula, porque um padrão não pode saber como é o seu volume de login ou o seu tráfego de API interno.

A proteção DDoS está sempre ativa; o risco real é o falso positivo

A proteção DDoS da Cloudflare roda nas camadas 3, 4 e 7, sempre ativa, sem configuração necessária pro piso básico. O que resta como risco não é um ataque passar, é uma regra de limite de taxa ajustada num mês tranquilo confundir um pico real de tráfego, um lançamento de produto, uma campanha que de fato funcionou, com um ataque e bloqueá-lo.

Onde isso é implementado na prática

Acertar aqui tem menos a ver com conhecer o catálogo de produtos da Cloudflare e mais com conhecer o seu próprio tráfego o bastante pra escrever as duas ou três regras que importam, deixando o resto pro piso gerenciado em vez de sobre-configurar regras que competem entre si.

Implementamos configuração de WAF e DDoS como parte da nossa prática de implementação de Cloudflare, com a mesma disciplina que aplicamos a qualquer projeto de engenharia: uma revisão de tráfego antes de mudar uma única regra, não um template aplicado às cegas. Como lidamos com segurança na nossa própria entrega, inclusive sob um BAA assinado quando há dado de saúde, está nas nossas práticas de segurança.