Existe uma suposição comum de que ativar o WAF é uma decisão binária: está bloqueando ou não está. Times que partem desse ponto ativam os managed rulesets em modo Block direto em produção, assumem que as regras são conservadoras o suficiente, e descobrem em seguida que o formulário de upload de contratos parou de funcionar, que a integração com o gateway de pagamento está retornando 403, e que o time de suporte está recebendo reclamações de clientes que não conseguem fazer login. O WAF não estava errado — mas também não conhecia a aplicação.
O que o modo Log faz e por que ele existe
O Cloudflare WAF tem três ações possíveis para cada regra: Block, que retorna 403 e encerra a requisição; Challenge, que apresenta um desafio ao cliente; e Log, que registra a ocorrência sem interferir no fluxo. O modo Log é o único que permite observar o comportamento das regras contra tráfego real sem consequência para os usuários.
Quando um ruleset é configurado com ação Log, todas as regras disparam normalmente — avaliam headers, URI, body, query string — mas em vez de bloquear, apenas registram o evento. O Firewall Events no dashboard do Cloudflare captura cada disparo: o IP de origem, o URI completo, o ID específico da regra e o conteúdo exato que causou o match. A requisição chega ao servidor de origem intacta. O usuário não percebe nada.
A sequência de deploy que evita incidentes
O processo começa habilitando todos os managed rulesets com a ação configurada como Log. O paranoia level do OWASP deve ser definido como 1 desde o início: esse nível captura os padrões de ataque mais óbvios com o menor volume de falsos positivos. Subir para level 2 ou 3 numa primeira ativação quase garante ruído excessivo que dificulta distinguir ataques reais de tráfego legítimo mal-formatado.
Com os rulesets em Log, o Firewall Events dashboard deve ser revisado diariamente. O objetivo é identificar regras que disparam consistentemente sobre requisições legítimas — o mesmo URI, o mesmo padrão de request, a mesma regra. Um disparo isolado pode ser ruído; o mesmo disparo em milhares de requisições de usuários reais é um falso positivo que vai bloquear tráfego quando a ação mudar para Block.
Quando um falso positivo é identificado, a resposta é criar uma Skip rule: uma regra de firewall que instrui o WAF a ignorar rulesets ou regras específicas quando critérios como URI e método HTTP correspondem. Um endpoint /api/upload que aciona a regra 100035 porque aceita arquivos com extensão .php no nome recebe uma Skip rule que exclui aquele path da inspeção daquela regra. A exclusão é cirúrgica: todo o restante do tráfego continua sendo avaliado.
Após uma a duas semanas com os rulesets em Log, os falsos positivos tratados com Skip rules, e nenhum disparo novo sobre tráfego legítimo, a ação muda para Block. O critério é estabilidade, não tempo decorrido.
Lendo o Firewall Events com precisão
O dashboard de Firewall Events mostra cada evento com detalhes suficientes para tomar uma decisão. Além do IP e do URI, o evento mostra o Rule ID que disparou — um identificador como 949110 ou 100035 consultável na documentação do Cloudflare — e o matched data, o trecho específico da requisição que causou o match.
Esse campo de matched data transforma a investigação de um falso positivo de especulação em diagnóstico concreto. Se a regra 100035 disparou no POST /api/upload e o matched data mostra filename=relatorio.php, fica claro que a regra reage ao nome do arquivo, não a conteúdo malicioso no body. A Skip rule resultante é precisa: ignora a regra 100035 apenas para aquele path. Qualquer outro endpoint que receba um .php genuinamente suspeito continua sendo avaliado.
Alertas de notificação para novos eventos de WAF fecham o ciclo de detecção contínua. Quando o Cloudflare adiciona uma nova assinatura para um CVE em circulação, o alerta notifica o time — e o Firewall Events mostra se a nova regra está tocando tráfego legítimo antes que seja tarde.
WAF Analytics e integração com SIEM
Para times com operações de segurança estabelecidas, os dados do Firewall Events podem ser exportados via Logpush. O Logpush envia eventos de WAF para R2, S3, Datadog ou Splunk com o conjunto completo de campos: timestamp, IP, país, URI, método, Rule ID, action tomada e matched data. Para uma equipe com SOC ativo, esses dados alimentam correlações que o dashboard do Cloudflare não faz: padrão de ataque distribuído por múltiplos IPs contra o mesmo endpoint ao longo de horas, variações de payload testando qual regra pode ser contornada.
O WAF Analytics agrega esses eventos em série temporal dentro do Cloudflare. Quando a ação muda de Log para Block, um aumento inesperado em respostas 403 no tráfego normal indica um falso positivo que escapou da fase de observação — e o Rule ID no evento diz exatamente o que tratar.
Construindo o hábito operacional
WAF não é uma configuração que se define uma vez. Aplicações mudam: novos endpoints são adicionados, integrações com terceiros introduzem padrões de request que o WAF nunca viu, e o Cloudflare atualiza os managed rulesets regularmente.
O que funciona é atribuir responsabilidade explícita: alguém no time de plataforma ou segurança revisa o Firewall Events semanalmente. A revisão busca padrões novos — regras disparando em volume alto que antes não apareciam, um spike de bloqueios em horário de pico. Quando um novo endpoint entra em produção, a sequência de observação recomeça para aquele path: Log primeiro, Skip rules para falsos positivos, Block depois.
Quando um falso positivo aparece em produção — um usuário reporta um 403 inesperado — o Rule ID no Firewall Events diz exatamente o que está acontecendo. O processo correto está em ter o Rule ID em mãos em menos de dois minutos, não em descobrir o que estava bloqueando depois que o suporte já recebeu cinquenta reclamações.
Leia também
- Cloudflare Workers em produção: o que muda depois do hello world
- O que ainda passa pelo WAF: técnicas de bypass e como mitigar
- Regras gerenciadas vs regras customizadas no WAF: quando escrever a sua própria
- Workers: debugging, logs e Workers Tail — observabilidade no edge sem servidor de log
- Cloudflare Load Balancing e Geo Steering: quando o DNS vira camada de tráfego inteligente
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido