Voltar para blog

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

08/03/2026 · 5 min · Cibersegurança

Compartilhar

🛡️ 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.

---

1. O papel do WAF na proteção do WordPress

O Web Application Firewall (WAF) da Cloudflare analisa o tráfego em tempo real, filtrando padrões suspeitos de injeção de SQL, Cross-Site Scripting (XSS) e abusos de protocolo. Para um CMS popular como o WordPress, regras específicas são essenciais para proteger arquivos sensíveis.

🛡️ Regra 1: blindagem de caminhos críticos

Esta regra bloqueia o acesso direto a arquivos que não devem ser carregados isoladamente por navegadores, como scripts de sistema e o antiquado XML-RPC.

sistema.

(http.request.uri.path eq "/xmlrpc.php") or
(http.request.uri.path contains "/wp-content/" and http.referer ne "dominio.com.br") or
(http.request.uri.path contains "/wp-includes/" and http.referer ne "dominio.com.br")

🛡️ Regra 2: restrição de acesso ao painel administrativo

Limitar o acesso ao /wp-admin apenas para IPs do Brasil reduz drasticamente a superfície de ataque contra tentativas de login estrangeiras.

(ip.geoip.country ne "BR" and http.request.uri.path contains "/wp-admin/")
Nota operacional: em ambiente com equipe distribuída ou viagem internacional, mantenha exceções por IP em regra separada para evitar lockout administrativo.

---

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

(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")

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.

---

3. Implementação de rate limiting (limitador de taxa)

Mesmo com regras de bloqueio, um atacante pode tentar "inundar" o servidor com requisições válidas para causar negação de serviço (DoS). O Rate Limiting define um teto de requisições por IP.

⚙️ Configuração recomendada

Resultado prático: em testes de estresse (stress test) sem proteção, o servidor costuma cair após 500 acessos simultâneos. Com a proteção ativa, o bloqueio ocorre automaticamente ao atingir o limite configurado, preservando a disponibilidade do site para usuários reais.

Na operação real, esse ajuste me entrega duas vantagens diretas:

  1. Redução de saturação em PHP-FPM e banco de dados.
  2. Resposta consistente para tráfego legítimo durante pico de ataque.

---

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.

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

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

  1. 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:

  1. Listar ranges oficiais da Cloudflare.
  2. Criar regras de allowlist para 80/443.
  3. Negar restante para tráfego HTTP/HTTPS direto.
  4. 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.

---

5. Camada crítica de aplicação: isolar o wp-config.php

Além da proteção de borda, uma medida de alto impacto é mover o wp-config.php para fora da raiz pública (public_html), reduzindo risco de vazamento em falhas de parsing do servidor web.

Fluxo objetivo:

  1. backup do arquivo e do banco;
  2. mover wp-config.php para o diretório pai;
  3. validar com php -l e teste completo de login/admin;
  4. aplicar permissões restritas (400 ou 440).

Exemplo:

cp public_html/wp-config.php public_html/wp-config.php.bak.$(date +%F-%H%M)
mv public_html/wp-config.php /home/accountuser/wp-config.php
php -l /home/accountuser/wp-config.php
chmod 400 /home/accountuser/wp-config.php

Se sua estrutura for customizada, use um stub mínimo em public_html com require_once apontando para o caminho seguro.

6. Cluster interno recomendado

Para completar a blindagem, mantenha este artigo como pilar e conecte com:

---

🏁 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.

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.