Eu preferia pedir uma verificação antes de barrar de vez um acesso ao WordPress. Numa das minhas regras, duas pessoas passaram pelo desafio e 86 não; esse placar me ajudava a enxergar o tanto de tentativa que chegava ao site, mas também mostra por que vale começar com cuidado antes de bloquear alguém.
Comece por um desafio antes de bloquear
Com o domínio passando pelo proxy da Cloudflare, o WAF consegue avaliar a requisição antes de ela chegar ao WordPress. No painel atual, entre em Regras de segurança e escolha Criar regra > Regras personalizadas. Dê um nome que explique o objetivo, selecione os campos que identificam a requisição — como caminho e país — e escolha a ação. A documentação atual descreve esse fluxo no painel; os nomes das telas podem mudar, mas você continua definindo quando a regra deve disparar e o que acontece depois.
Eu lembrava que a conta gratuita permitia de três a cinco regras. Hoje a Cloudflare lista cinco regras personalizadas no plano Free; confira o limite atual antes de montar sua estrutura. Quando há poucas regras, eu juntaria condições que atendem ao mesmo objetivo, sem misturar caminhos que possam causar problemas diferentes.
Na época, eu estava trocando o Legacy CAPTCHA pelo Managed Challenge. O desafio gerenciado escolhe a verificação conforme os sinais da requisição, e muita gente consegue passar sem resolver um CAPTCHA manual. Para uma regra nova, comece por essa ação e confira os eventos correspondentes em Segurança. Se o seu plano não oferecer a ação Log, a própria Cloudflare sugere observar os pedidos desafiados e só depois considerar um bloqueio.
Proteja o wp-login sem reaproveitar o score 49
Uma das minhas regras olhava o caminho wp-login e o país de origem. Como eu administrava aquele site do Brasil, requisições de fora recebiam um Managed Challenge. Na expressão também havia uma condição com pontuação 49. No painel que mostrei, duas pessoas passaram pela verificação e 86 não conseguiram. Esse resultado explica por que eu preferia o desafio a simplesmente bloquear qualquer visitante de outro país.
Essa pontuação é a parte que envelheceu. O campo antigo <code>cf.threat_score</code> da Cloudflare agora retorna sempre zero; portanto, uma condição que compara esse campo a 49 não identifica mais tráfego suspeito. O Bot Score atual usa a direção contrária — quanto menor, maior a chance de ser um bot — e exige plano Enterprise com Bot Management. Não copie os valores 49 ou 24 da minha regra antiga para o Bot Score novo. Em uma conta sem esse recurso, mantenha a regra baseada no caminho e na origem que façam sentido para a equipe, ou use as proteções disponíveis no painel.
Separe contato, XML-RPC e wp-admin
Eu incluía páginas com contact ou contato porque meu site tinha vários idiomas, e a regra também deixava de fora caminhos de <code>/wp-content</code>. Eu não lembrava exatamente por que tinha criado essa exceção; antes de copiar uma condição assim, abra os eventos e confirme quais arquivos são atingidos. Também coloquei <code>xmlrpc.php</code> na regra por causa das tentativas automatizadas que recebia, sempre com Managed Challenge em vez de bloqueio direto.
O XML-RPC pode atender aplicativos e integrações legítimas do WordPress. Um desafio de navegador devolve uma página HTML, que um cliente esperando uma resposta XML talvez não consiga resolver. Se você publica pelo aplicativo móvel ou por outra ferramenta remota, teste esse fluxo antes de desafiar o endpoint. Se depender dele, deixe-o fora da regra ou procure uma proteção compatível com esse cliente.
Eu mantinha outra condição para <code>wp-admin</code> e <code>wp-login</code>: acessos de fora do Brasil recebiam JS Challenge. Faça essa escolha pensando em quem administra o site. Uma pessoa viajando ou trabalhando de outro país pode cair na mesma verificação; se a equipe usa mais de uma localização, ajuste os países ou use outra condição para restringir a regra aos caminhos administrativos.
Revise os scores e preserve os rastreadores confiáveis
Eu também usava uma condição de score maior que 24 para aplicar JS Challenge. Naquele score antigo, número maior significava mais suspeita; o painel mostrava 60 passagens por esse desafio. Como a pontuação de ameaça hoje não funciona assim e o Bot Score tem escala invertida, não dá para converter esse limite por troca de nome. Acompanhe os eventos da regra e só use campos que estejam disponíveis no seu plano.
Na época eu dizia que as regras não afetavam os bots do Google, porque o foco estava em login, painel e XML-RPC. Esse foi o comportamento do meu site, não uma garantia para toda regra. Uma condição ampla também pode alcançar uma página pública de contato. Se precisar cobrir caminhos públicos, verifique o campo <code>cf.client.bot</code>, que permite identificar bots confiáveis, como rastreadores do Google, e deixá-los fora daquele desafio.
Use o WAF junto do cache e das outras proteções
Eu usava Jetpack principalmente pelo CDN de imagens. No mesmo painel havia Bot Fight, bloqueio de IP e Page Shield, mas eu não conhecia cada opção o bastante para recomendar todas. Vale distinguir o que eu tinha configurado do restante dos recursos que apareciam na conta.
O site da gravação estava bastante cacheado na Cloudflare: cerca de 98% das visitas, segundo o painel que consultei. Naquele recorte, eu via por volta de um milhão de requisições e 58 mil visitas únicas. São números do meu site, não uma meta nem uma medição de bloqueios. O cache fazia com que boa parte do conteúdo fosse entregue pela borda, enquanto as regras cuidavam de caminhos como login, contato e XML-RPC. Mesmo com um servidor protegido ou uma página em cache, as requisições continuam precisando das regras certas na camada que recebe o tráfego.