Hardening WordPress em camadas

Hardening WordPress em Camadas: Cloudflare, wp-config e Blindagem de Origem#

Se o seu site WordPress apresenta lentidão intermitente ou você nota picos de tráfego vindos de países sem relação com o seu negócio (como China, Rússia ou Taiwan), você provavelmente é alvo de bots de reconhecimento ou ataques de força bruta.

Neste guia, documentamos como utilizar o plano gratuito da Cloudflare para implementar uma camada de Defense in Depth (Defesa em Profundidade), protegendo a sua aplicação antes mesmo de a requisição atingir o seu servidor.

No meu fluxo de operação, o objetivo é sempre o mesmo: deslocar o máximo de tráfego malicioso para a borda (edge), deixar o host de origem responder só para usuários reais e reduzir consumo de CPU/IO de forma previsível.

2. Mitigação de bots e formulários de contato#

Ataques de spam em formulários (via admin-ajax.php) não só poluem sua caixa de entrada, como podem causar picos de consumo de CPU no servidor.

Regra 3: Validação de chamadas AJAX#

Expressão:

(not cf.client.bot and http.request.uri.path contains "/wp-admin/admin-ajax.php" and http.request.method eq "POST" and not http.referer contains "dominio.com.br")

Ação: Desafio Gerenciado (Managed Challenge).

Esse ponto é crítico porque muito plugin de formulário ou recurso assíncrono do WordPress passa por admin-ajax.php. A regra precisa ser rígida contra origem suspeita, mas sem quebrar fluxo legítimo. Em produção, eu aplico em modo de desafio primeiro, monitoro logs/analytics e só depois elevo para bloqueio direto se o padrão de abuso estiver estável.

4. Dica de sênior: proteção de origem (Cloudflare IP only)#

De nada adianta configurar a Cloudflare se o atacante descobrir o IP real do seu servidor.

Nuvem cinza vs nuvem laranja: garanta que todos os registros (A, CNAME)

estejam com o "Proxy" ativado (nuvem laranja).

Firewall no servidor (CSF/IPTables): configure o firewall do seu

servidor (exemplo: cPanel/WHM) para aceitar conexões nas portas 80/443 apenas originadas dos IPs da Cloudflare. Isso impede que o atacante "pule" a proteção da Cloudflare acessando o servidor diretamente.

Exemplo de abordagem prática no host#

Em hardening de borda, eu faço o ciclo abaixo sem pular etapa:

Listar ranges oficiais da Cloudflare.
Criar regras de allowlist para 80/443.
Negar restante para tráfego HTTP/HTTPS direto.
Validar que o domínio responde via Cloudflare e não responde por IP direto.

Essa disciplina elimina a falsa sensação de segurança que acontece quando o WAF está ativo, mas a origem ainda está exposta.

Conclusão estratégica#

A segurança do WordPress não deve depender apenas de plugins internos (como Wordfence ou Sucuri), que consomem recursos do seu banco de dados. Ao mover a lógica de segurança para a Edge (Cloudflare), você protege o site com latência zero e reduz o custo de processamento da sua hospedagem.

No cenário operacional, o ganho é claro: menos ruído na infraestrutura, menos intermitência em horário de pico e maior previsibilidade para escalar sem ficar apagando incêndio.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.

Hardening WordPress em camadas: Cloudflare, wp-config e blindagem de origem