WordPress alimenta mais de 40% da web, tornando-o o CMS mais visado por bots automatizados, script kiddies e atacantes sofisticados. Todo site WordPress desprotegido enfrenta milhares de requisições maliciosas diariamente — tentativas de login por força bruta, ataques de amplificação XML-RPC, sondagens de SQL injection e varreduras de travessia de diretório. O Web Application Firewall (WAF) do Cloudflare fornece uma poderosa camada de defesa gratuita que bloqueia esses ataques na borda, antes que cheguem ao seu servidor. Neste guia, você vai configurar regras WAF personalizadas que bloqueiam os vetores de ataque WordPress mais comuns.
Pré-requisitos
- Uma conta Cloudflare (o plano gratuito funciona para até 5 regras personalizadas)
- O DNS do seu domínio gerenciado pelo Cloudflare (nuvem laranja ativada - proxied)
- Uma instalação WordPress em funcionamento
- Acesso de administrador ao painel do Cloudflare
- Seu endereço IP público atual (para liberar o acesso de administrador)
Por Que o WordPress Precisa de Proteção WAF
Sites WordPress enfrentam uma enxurrada incessante de ataques automatizados. Segundo dados do Wordfence, um site WordPress típico recebe mais de 90.000 tentativas maliciosas de login por mês. Os endpoints mais explorados são:
- xmlrpc.php — usado para amplificação de força bruta (uma requisição pode testar centenas de senhas), abuso de DDoS via pingback e ataques SSRF
- wp-login.php — alvo de bots de credential stuffing executando listas de senhas vazadas
- wp-admin/ — sondado para acesso não autenticado a funções administrativas
- wp-json/wp/v2/ — enumeração da REST API expõe nomes de usuário e estrutura de conteúdo
- Query strings — tentativas de SQL injection via
?id=1 UNION SELECT, travessia de caminho via../../etc/passwd
Um firewall no nível do servidor como iptables só enxerga endereços IP. O WAF do Cloudflare inspeciona requisições HTTP na camada 7 — ele pode verificar caminhos de URI, query strings, cabeçalhos, métodos de requisição e user agents. Isso permite escrever regras precisas que bloqueiam ataques sem afetar visitantes legítimos.
Regras WAF Essenciais
Navegue até o painel do Cloudflare: Security > WAF > Custom rules. Você criará essas regras em ordem de prioridade.
Regra 1: Bloquear xmlrpc.php
Esta é a regra com maior impacto. O xmlrpc.php é responsável pela maioria do tráfego de força bruta na maioria dos sites WordPress.
Expression:
(http.request.uri.path eq "/xmlrpc.php")
Action: BlockSe você depende do Jetpack ou do aplicativo móvel do WordPress, mude a ação para Managed Challenge em vez de Block. Mas se você pode desativar o xmlrpc completamente, bloqueie-o.
Regra 2: Desafiar wp-login.php
Em vez de bloquear a página de login completamente, use um desafio gerenciado para que administradores legítimos ainda passem enquanto bots são bloqueados.
Expression:
(http.request.uri.path eq "/wp-login.php")
Action: Managed ChallengeIsso força o desafio inteligente do Cloudflare (CAPTCHA ou desafio JS) em cada requisição à página de login. Bots automatizados falham no desafio; humanos reais passam de forma transparente.
Regra 3: Restringir wp-admin por IP
Bloqueie a área administrativa ao seu endereço IP. O detalhe crucial aqui é excluir o admin-ajax.php, que o WordPress usa para chamadas AJAX no frontend (formulários de contato, atualizações do carrinho WooCommerce, etc.).
Expression:
(http.request.uri.path contains "/wp-admin"
and not http.request.uri.path contains "admin-ajax.php"
and not ip.src in {203.0.113.50})
Action: BlockSubstitua 203.0.113.50 pelo seu IP real. Você pode adicionar múltiplos IPs usando uma lista: {203.0.113.50 198.51.100.25}.
Regra 4: Bloquear SQL Injection e Travessia de Caminho
Capture padrões comuns de injeção na URI completa, incluindo query strings.
Expression:
(http.request.uri contains "union select"
or http.request.uri contains "concat("
or http.request.uri contains "../"
or http.request.uri contains "eval("
or http.request.uri contains "<script"
or http.request.uri contains "etc/passwd")
Action: BlockEsta regra captura os payloads de SQLi e XSS mais frequentes. Os padrões cobrem injeção baseada em UNION, travessia de caminho, injeção de JavaScript e tentativas de inclusão de arquivo local.
Regra 5: Bloquear User Agents Maliciosos
Muitas ferramentas de ataque usam user agents identificáveis. Combine o bloqueio de bots em uma regra para economizar os slots de regras do plano gratuito.
Expression:
(http.request.uri.path contains "/wp-"
and (http.user_agent contains "sqlmap"
or http.user_agent contains "nikto"
or http.user_agent contains "wpscan"
or http.user_agent contains "masscan"
or http.user_agent eq ""))
Action: BlockUser agents vazios em endpoints WordPress são quase sempre scanners maliciosos. Esta regra os bloqueia junto com assinaturas de ferramentas de ataque conhecidas.
Recursos WAF: Gratuito vs Pro vs Business
| Recurso | Gratuito | Pro (US$20/mês) | Business (US$200/mês) |
|---|---|---|---|
| Regras WAF personalizadas | 5 | 20 | 100 |
| Conjuntos de regras gerenciadas (OWASP) | Não | Sim | Sim |
| Regras de limitação de taxa | 1 | 10 | 50 |
| Gerenciamento de bots | Básico | Aprimorado | Avançado |
| Páginas de erro personalizadas | Não | Sim | Sim |
| Análise WAF | Eventos básicos | Detalhado | Completo com logs |
| Regras de acesso por IP | Ilimitado | Ilimitado | Ilimitado |
| Modificação de cabeçalhos de resposta | Não | Sim | Sim |
Para a maioria dos sites WordPress, o plano gratuito com 5 regras personalizadas bem elaboradas cobre 90% do tráfego de ataques. Faça upgrade para o Pro se precisar de conjuntos de regras gerenciadas OWASP ou mais slots de regras.
Cenário Real
Você administra um site WordPress de e-commerce no WooCommerce que processa 500 pedidos por dia. Seus logs do servidor mostram mais de 1.200 tentativas de login falhas diárias no wp-login.php, seu xmlrpc.php recebe 8.000 acessos por dia de botnets, e você percebeu strings de SQL injection aparecendo nos seus logs de consulta. Seu provedor de hospedagem avisa sobre picos de CPU causados pelo processamento de todas essas requisições maliciosas.
Após habilitar as cinco regras WAF acima, o Cloudflare bloqueia 95% desse tráfego na borda. O uso de CPU do seu servidor cai 40%, os tempos de carregamento das páginas melhoram porque seus workers PHP não estão ocupados processando requisições de ataque, e seus custos de hospedagem permanecem estáveis em vez de escalar. O desafio gerenciado no wp-login.php bloqueia credential stuffing enquanto sua equipe editorial faz login sem problemas. A restrição de IP no wp-admin significa que, mesmo se um atacante obtiver credenciais, ele não consegue acessar o painel a partir do seu IP.
Limitação de Taxa para WordPress
A limitação de taxa adiciona uma dimensão temporal à sua proteção. Navegue até Security > WAF > Rate limiting rules.
Limitação de Taxa na Página de Login
Expression:
(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
Rate: 5 requests per 10 seconds
Action: Block for 600 seconds (10 minutes)
Counting expression: Same as rule expressionLimitação de Taxa na REST API
Expression:
(http.request.uri.path contains "/wp-json/")
Rate: 30 requests per 10 seconds
Action: Managed ChallengeIsso previne enumeração e abuso da API enquanto permite o uso normal da REST API por temas e plugins.
Solução de Problemas
admin-ajax.php deve ser excluído — WordPress usa admin-ajax.php para requisições AJAX no frontend mesmo para visitantes não logados. Formulários de contato, adicionar ao carrinho do WooCommerce e scroll infinito usam este endpoint. Bloqueá-lo com restrição de IP quebra todo o seu frontend.
REST API do WooCommerce — se você usa a REST API do WooCommerce para integrações externas (provedores de frete, sincronização de estoque, sistemas POS), garanta que sua limitação de taxa em /wp-json/ não bloqueie esses serviços. Libere os IPs deles ou use um limite mais alto.
Cron e tarefas agendadas — wp-cron.php é acessado por páginas cacheadas do Cloudflare. Se você usa cron do servidor (recomendado), pode bloquear o acesso externo ao wp-cron.php em uma regra WAF.
Atualizações de plugins e upload de arquivos — alguns plugins fazem requisições a caminhos do wp-admin durante atualizações automáticas. Sua regra de restrição por IP cuida disso desde que o próprio servidor não esteja atrás de um serviço externo que altere o IP de origem.
Cuidado com bloqueio por país — evite bloquear países inteiros a menos que você realmente não tenha usuários lá. Bloqueios por país podem inadvertidamente bloquear rastreadores de mecanismos de busca que passam por esses países, impactando seu SEO.
Teste minuciosamente — após habilitar as regras, abra uma janela anônima e teste: visite a página inicial, navegue até uma página de produto, envie um formulário de contato e faça login no wp-admin. Verifique Security > Events para falsos positivos.
Resumo
- Bloqueie
xmlrpc.phpcompletamente — é o endpoint WordPress mais explorado e a maioria dos sites não precisa dele - Use desafios gerenciados no
wp-login.phppara bloquear bots enquanto permite a passagem de administradores humanos - Restrinja
wp-adminpor IP mas sempre excluaadmin-ajax.phppara não quebrar a funcionalidade do frontend - Adicione verificação de padrões de SQL injection e XSS para capturar payloads comuns de injeção na borda
- Configure limitação de taxa nos endpoints de login e REST API para limitar tentativas de força bruta
- O plano gratuito do Cloudflare oferece 5 regras personalizadas — suficiente para cobrir a superfície de ataque crítica do WordPress
- Monitore os Eventos de Segurança após implantar as regras e ajuste para falsos positivos
- Considere o Cloudflare Access (Zero Trust) para cenários de IP dinâmico em vez de whitelist por IP