Guia para iniciantes: 5 regras gratuitas do firewall da Cloudflare para filtrar 80% do tráfego malicioso

Introdução

Os logs do servidor estão cheios de solicitações de varredura, com milhares de acessos maliciosos todos os dias. Usar o plano gratuito da Cloudflare sem configurar uma única regra de firewall é como deixar o site desprotegido. Você encontra um tutorial, copia e cola o código, mas nada funciona porque a ordem de prioridade das regras foi invertida.

Expressões como (ip.src.country eq "CN") realmente assustam no começo, mas, depois de alguns dias testando, descobri que as 5 regras do plano gratuito são suficientes de verdade. Uma boa configuração consegue filtrar mais de 80% das solicitações maliciosas sem atingir usuários legítimos. Este artigo ensina a configurar essas 5 regras, entender como elas funcionam e definir as prioridades certas — tudo em 30 minutos.

Capítulo 1: por que as 5 regras do plano gratuito são suficientes

Ao ver que o plano gratuito da Cloudflare oferece apenas 5 regras personalizadas, muita gente pensa: “Isso não pode ser suficiente”. O plano Pro tem 20. Será que vale a pena fazer o upgrade?

Calma, deixe-me explicar.

Na prática, a maior parte do tráfego malicioso vem de poucas categorias: scanners hospedados em data centers, IPs com pontuação de ameaça alta e User-Agents anormais. Segundo a experiência compartilhada pela comunidade da Cloudflare, 5 regras bem configuradas conseguem bloquear mais de 80% dos ataques.

É o clássico princípio 80/20.

Além das 5 regras personalizadas, o plano gratuito inclui o Cloudflare Free Managed Ruleset, um conjunto gratuito de regras gerenciadas. Ele vem habilitado por padrão e protege contra vulnerabilidades críticas conhecidas, como Shellshock e Log4J. Para sites pequenos e médios, o conjunto gerenciado mais 5 regras personalizadas é realmente suficiente.

As 15 regras adicionais do plano Pro são mais úteis para operações detalhadas. Por exemplo, quando você tem vários subdomínios que exigem configurações separadas ou precisa criar políticas diferentes para várias APIs. Se o site não é tão complexo, 5 regras cobrem totalmente as necessidades essenciais de proteção.

Mas há uma condição: você precisa usar essas 5 regras corretamente. Se a prioridade estiver errada, nem 10 regras resolverão.

Capítulo 2: o segredo da prioridade das regras

Este é o ponto em que mais gente erra. Quando fiz minha primeira configuração, também inverti a ordem e nenhuma das regras que eu havia preparado funcionou.

As regras de firewall da Cloudflare são executadas de cima para baixo, como uma linha de produção que verifica cada solicitação. Primeiro é avaliada a regra 1, depois a regra 2 e assim por diante. Quando uma regra corresponde, a ação associada — Allow, Block, Challenge etc. — é executada e a avaliação para, com exceção de Allow, que permite continuar avaliando regras posteriores.

Pense no segurança na entrada de um prédio:

1. Primeiro, reconhecer a pessoa: se for alguém conhecido, permitir a entrada imediatamente (lista de permissões)
2. Depois, verificar: se for desconhecida, pedir identificação (desafio)
3. Por fim, bloquear: se for suspeita, negar a entrada (bloqueio)

Se você inverter a ordem e bloquear antes de verificar, visitantes legítimos também não conseguirão entrar.

Um erro comum é colocar o bloqueio por país antes da lista de permissões. Imagine que você usa um serviço estrangeiro de monitoramento como o UptimeRobot, mas sua primeira regra diz “bloquear todos os IPs que não sejam da China”. O serviço de monitoramento é bloqueado, e você nem descobre quando o site sai do ar.

A forma correta é simples: a lista de permissões deve ser sempre a primeira regra. Libere primeiro o tráfego reconhecidamente legítimo — crawlers de mecanismos de busca, serviços de monitoramento e seu próprio IP — e depois restrinja a proteção em camadas.

Outro detalhe que costuma passar despercebido: as ações também têm prioridade. Entre regras com a mesma prioridade, a execução segue esta ordem:

• Allow (permitir) > Skip (ignorar) > Challenge (desafiar) > Block (bloquear) > Log (registrar)

Isso significa que, se uma solicitação corresponder ao mesmo tempo a uma regra Allow e a uma regra Block, Allow prevalecerá. Por isso a lista de permissões deve ficar no início: assim ela tem a maior prioridade e não é atingida por engano pelas regras seguintes.

Capítulo 3: a configuração ideal das 5 regras

Vamos direto ao que interessa. As 5 regras abaixo estão ordenadas da maior para a menor prioridade, e você pode copiar as expressões.

Regra 1 (maior prioridade): lista de permissões para proteger seus aliados

Objetivo: liberar tráfego reconhecidamente legítimo e evitar falsos positivos.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Quando usar:

• Crawlers de mecanismos de busca, como Google, Bing e Baidu
• Serviços de monitoramento, como UptimeRobot e StatusCake
• IPs do seu escritório e da sua casa

Expressão da regra:

(cf.client.bot) or (ip.src in {1.2.3.4 5.6.7.8})

Ação: Allow

Observações:

• cf.client.bot representa crawlers legítimos verificados pela Cloudflare, incluindo mecanismos conhecidos como Google e Bing
• Substitua {1.2.3.4 5.6.7.8} pelos seus próprios endereços IP, separando vários IPs com espaços
• Se não precisar liberar IPs específicos, simplifique para (cf.client.bot)

Regra 2: desafio para ASNs de data centers

Objetivo: aplicar uma verificação humana ao tráfego proveniente de data centers.

Quando usar:

Scanners e ferramentas de crawling costumam ser hospedados em VPSs e servidores de nuvem, enquanto usuários comuns raramente acessam sites a partir de IPs de data centers. Um desafio costuma afastar os bots.

Expressão da regra:

(ip.geoip.asnum in {13335 15169 16509 14618 45090})

Ação: Managed Challenge

Tabela de ASNs (data centers comuns):

Adicione ou remova ASNs de acordo com a realidade do seu site. Não recomendo usar Block diretamente, pois isso pode atingir usuários reais de VPN. Managed Challenge é suficiente: pessoas reais passam pela verificação, enquanto bots ficam presos.

Regra 3: pontuação de ameaça e filtro de IPs de risco

Objetivo: bloquear IPs de alto risco com base na inteligência de ameaças da Cloudflare.

Quando usar:

A Cloudflare atribui uma pontuação de 0 a 100 a cada IP: quanto maior a pontuação, maior o risco. Acima de 10 pode indicar um emissor de spam; acima de 40, um agente malicioso; acima de 50, recomenda-se bloquear diretamente.

Expressão da regra:

(cf.threat_score gt 10)

Ação: Challenge para pontuações de 10 a 40 ou Block para pontuações acima de 50

Limites recomendados:

Dica de otimização:

Se quiser tratar as faixas separadamente, crie duas regras:

• Regra 3A: (cf.threat_score gt 10 and cf.threat_score le 50) → Challenge
• Regra 3B: (cf.threat_score gt 50) → Block

Isso consome duas regras. Se não houver espaço, use apenas gt 10 com Challenge, observe o resultado por uma semana e ajuste depois.

Regra 4: bloqueio de User-Agents anormais

Objetivo: filtrar User-Agents vazios, crawlers maliciosos e ferramentas automatizadas.

Quando usar:

Navegadores normais enviam um User-Agent para informar ao servidor algo como “sou o Chrome”. Se o UA estiver vazio ou for claramente uma ferramenta de script, como python-requests ou curl, é muito provável que a visita não seja de uma pessoa.

Expressão da regra:

(http.user_agent eq "") or (http.user_agent contains "python-requests") or (http.user_agent contains "curl") or (http.user_agent contains "sqlmap") or (http.user_agent contains "nikto") or (http.user_agent contains "MJ12bot")

Ação: Block

User-Agents maliciosos comuns:

• python-requests — script em Python
• curl — ferramenta de linha de comando
• sqlmap — ferramenta de injeção SQL
• nikto — scanner de vulnerabilidades
• MJ12bot — crawler de SEO da Majestic que não respeita o robots.txt
• masscan — scanner de portas
• ZmEu — scanner

Cuidados:

• Não bloqueie User-Agents de navegadores conhecidos, como Mozilla, Chrome e Safari
• Você pode usar a ação Log por uma semana, identificar UAs anormais nos registros e só depois adicioná-los à regra
• Se o site oferece uma API, talvez seja necessário excluir o UA do seu próprio cliente de API

Regra 5: proteção de caminhos sensíveis

Objetivo: proteger páginas administrativas, APIs sensíveis e arquivos de configuração.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Quando usar:

Os caminhos /wp-admin e /wp-login.php do WordPress são alvos frequentes de scanners. Arquivos como .env e .git também são perigosos: se vazarem, o dano pode ser grave.

Expressão da regra:

(http.request.uri.path contains "/wp-login" or http.request.uri.path contains "/wp-admin" or http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git") and not (ip.src in {1.2.3.4})

Ação: Block ou Challenge

Observações:

• Substitua {1.2.3.4} pelo seu próprio IP para não bloquear o seu acesso ao painel
• Se não quiser usar uma lista de permissões por IP, remova and not (ip.src in {1.2.3.4}) e use a ação Challenge

Outros caminhos sensíveis:

• /xmlrpc.php — interface XML-RPC do WordPress, usada com frequência em ataques DDoS
• /phpMyAdmin — interface de administração do banco de dados
• /config.php
• /.sql — arquivo de backup do banco de dados

Adicione os caminhos relevantes para a stack do seu site.

Fluxo completo de execução

Depois de configurar as 5 regras, cada solicitação seguirá este fluxo:

Solicitação de acesso
   ↓
Regra 1: é um crawler legítimo ou IP permitido? → Sim → Permitir imediatamente
   ↓ Não
Regra 2: vem de um ASN de data center? → Sim → Desafio humano → Aprovar/bloquear
   ↓ Não
Regra 3: pontuação de ameaça acima de 10? → Sim → Desafiar/bloquear
   ↓ Não
Regra 4: User-Agent anormal? → Sim → Bloquear
   ↓ Não
Regra 5: acessa um caminho sensível? → Sim → Bloquear/desafiar
   ↓ Não
Permitir e encaminhar ao servidor de origem

Esse fluxo filtra a maior parte dos ataques automatizados sem afetar usuários legítimos.

Capítulo 4: configuração passo a passo

Não basta conhecer as regras; é preciso configurá-las. Siga estes passos.

Passo 1: abra a página de configuração do firewall

Entre no Cloudflare Dashboard → selecione seu domínio → no menu lateral, abra “Security” → clique em “WAF” → acesse a aba “Custom rules”.

Passo 2: crie a primeira regra, a lista de permissões

1. Clique no botão azul “Create rule” no canto superior direito

2. Nome da regra: digite Lista de permissões - crawlers e monitoramento legítimos ou outro nome fácil de reconhecer

3. Editor de expressão: o padrão é o Expression Builder visual. Para colar o código diretamente, clique em “Edit expression”

4. Cole a expressão:

   (cf.client.bot) or (ip.src in {1.2.3.4})

   Substitua o IP pelo seu

5. Selecione a ação: escolha “Allow” no menu

6. Clique em “Deploy”

Passo 3: crie as outras 4 regras

Repita o procedimento para as regras 2 a 5. Use os nomes, as expressões e as ações descritos no capítulo anterior.

Passo 4: ajuste a ordem das regras

Depois de criar as 5 regras, você verá a lista completa. Arraste o ícone de seis pontos à esquerda de cada regra para garantir esta ordem:

• Lista de permissões no topo (prioridade 1)
• Desafio por ASN em segundo
• Pontuação de ameaça em terceiro
• User-Agent anormal em quarto
• Caminhos sensíveis em quinto

Passo 5: teste as regras

Depois da configuração, faça alguns testes:

1. Teste a lista de permissões: acesse o site com seu próprio IP; o acesso deve funcionar normalmente

2. Teste o bloqueio por UA: abra o terminal e execute:

   curl -A "sqlmap" https://seu-dominio.com

   A página de bloqueio deve aparecer

3. Consulte os registros: volte para Cloudflare Dashboard → Security → Events e confira o bloqueio que acabou de ocorrer

Se a regra não funcionar, verifique:

• Se há erro de sintaxe na expressão
• Se a ordem de prioridade está correta
• Se a ação selecionada é a certa

Capítulo 5: técnicas avançadas e dúvidas frequentes

As 5 regras básicas já protegem contra a maior parte dos ataques, mas alguns detalhes ajudam a melhorar o resultado.

Como saber se uma regra funciona

A Cloudflare oferece uma métrica muito útil: CSR (Challenge Solve Rate, taxa de resolução de desafios).

Fórmula: CSR = número de desafios resolvidos com sucesso / número total de desafios emitidos

Quanto menor o valor, melhor. Um CSR próximo de 0% significa que quase todos os desafiados eram bots e nenhum passou pela verificação. Nesse caso, considere trocar a ação de Challenge para Block, bloqueando diretamente e economizando recursos do servidor.

Um CSR alto, por exemplo acima de 50%, indica que usuários reais podem estar sendo afetados e que as condições da regra precisam ser ajustadas.

Para consultar o CSR: Security → Events → clique em uma regra → veja as estatísticas detalhadas.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Como evitar bloquear usuários legítimos

Este é o maior receio. Algumas recomendações:

1. Observe uma nova regra no modo Log por 7 dias
   • Selecione a ação “Log”, que apenas registra e não bloqueia
   • Após uma semana, confira Security Events e só então mude para Challenge ou Block
2. Adicione seu próprio IP e os serviços de monitoramento à lista de permissões
   • Inclua na regra 1 os IPs que você usa
   • Consulte as faixas de IP do UptimeRobot no site oficial e adicione-as à lista
3. Não comece com Block
   • Use Challenge durante algum tempo
   • Só considere Block depois de confirmar que o CSR está próximo de 0%
4. Fique atento a quedas anormais no tráfego
   • Se o tráfego legítimo cair muito depois da configuração, pode haver falsos positivos
   • Confira em Security Events se usuários reais foram bloqueados

Como reagir a um ataque repentino

Se o site estiver sofrendo um ataque CC ou DDoS e o tráfego disparar, você pode ativar temporariamente o modo Under Attack:

Security → Settings → Security Level → selecione “I’m Under Attack”

Esse modo exibe a todos os visitantes uma página de carregamento por 5 segundos para executar uma verificação em JavaScript. Bots não passam pela verificação; pessoas reais entram após os 5 segundos. Quando o ataque terminar, volte para Medium ou Low.

Você também pode reforçar as regras temporariamente:

• Trocar Challenge por Block
• Adicionar um bloqueio geográfico; se o ataque vier de um país específico, bloqueie temporariamente os IPs desse país

E se 5 regras não forem suficientes?

Às vezes, 5 regras realmente não bastam. Há algumas soluções:

1. Use or para reunir regras do mesmo tipo
   • A regra 4, por exemplo, já combina vários User-Agents anormais em uma única expressão com or
   • Tente fazer cada regra cobrir uma categoria de cenário
2. Crie uma lista de IPs para gerenciamento centralizado
   • A Cloudflare permite criar listas com milhares de IPs
   • Referencie a lista em uma regra: ip.src in $blacklist
   • Assim, uma regra gerencia muitos IPs sem consumir mais regras
3. Considere o plano Pro
   • O plano Pro oferece 20 regras e outros recursos avançados
   • Se o site gera receita, pode valer o investimento

Dúvidas frequentes

P: O que fazer quando uma regra não funciona?

R: Verifique:

• Se há erro de sintaxe na expressão — a Cloudflare avisa
• Se a ordem de prioridade está correta — a lista de permissões deve ficar no topo
• Se uma regra anterior já aplicou Allow ou Skip

P: Meu próprio IP foi bloqueado. O que fazer?

R: Adicione seu IP à lista de permissões da regra 1:

(cf.client.bot) or (ip.src in {seu IP})

P: Qual pontuação de ameaça devo usar?

R: Recomendações:

• Conservadora: cf.threat_score gt 30 — menos bloqueios e menor risco de falso positivo
• Equilibrada: cf.threat_score gt 10 — recomendada, pois equilibra proteção e experiência
• Agressiva: cf.threat_score gt 5 — mais bloqueios, mas pode atingir usuários de VPN

Comece com 10, observe por uma semana e ajuste de acordo com o CSR e os falsos positivos.

P: Por que o crawler do Google foi bloqueado?

R: Confirme se a regra 1, a lista de permissões, tem a maior prioridade. cf.client.bot identifica automaticamente crawlers conhecidos como Google e Bing. Se a lista de permissões estiver em primeiro lugar, eles não serão bloqueados.

Conclusão

Resumindo: as 5 regras de firewall do plano gratuito são suficientes. O segredo é configurá-las na ordem correta:

1. Lista de permissões em primeiro lugar para proteger seus aliados
2. Desafio por ASN para filtrar tráfego de data centers
3. Pontuação de ameaça para barrar IPs de alto risco
4. Bloqueio de User-Agents anormais para filtrar ferramentas automatizadas
5. Proteção de caminhos sensíveis para fechar portas de entrada

As regras entram em vigor em 30 minutos. Depois de uma semana, consulte Security Events: o volume bloqueado pode surpreender. Os scanners que antes consumiam tráfego e largura de banda ficarão do lado de fora.

Configure agora mesmo. O Cloudflare Dashboard está pronto, e os modelos estão acima: copie, cole, ajuste o IP e termine em meia hora.

Após uma semana, volte para conferir os dados de bloqueio. Se o resultado for bom, salve este artigo para consultar quando precisar ajustar as regras. Se tiver algum problema, releia as dúvidas frequentes do capítulo 5.

Seu site merece uma proteção melhor.