| Camada | O que mitiga | Check de validação |
|---|---|---|
| WAF de borda | DDoS, SQL injection, payload malicioso | Requisição com aspas simples retorna 403 |
| Hardening wp-config | Leitura e edição do arquivo de configuração | DISALLOW_FILE_EDIT ativo e permissão 640 |
| Bloqueio de login | Força bruta e enumeração de usuário | 5 tentativas erradas geram bloqueio temporário |
| Headers HTTP | XSS refletido, clickjacking, sniffing | Header Content-Security-Policy presente na resposta |
| Monitoramento CVE | Plugin ou tema com falha pública | Scanner sem alerta de versão sem patch |
Legenda: o WAF na camada de aplicação inspeciona requisições que já passaram pela borda, fechando o vão do upload multipart.
--- ## Camada 2: Hardening do wp-config como base da mitigação de ataques O hardening do wp-config.php é a camada mais barata da mitigação de ataques e fecha o arquivo que guarda as credenciais do banco. Duas mudanças resolvem boa parte do risco: definir `DISALLOW_FILE_EDIT` como `true`, que desativa o editor de plugins, e ajustar a permissão para 640, que barra a leitura por usuário que não seja o dono do processo. A relação técnica é clara: wp-config.php com DISALLOW_FILE_EDIT true mais permissão 640 elimina o caminho de injeção via editor de código no admin. Isso importa porque o editor de plugins é o caminho preferido para injetar um backdoor após um login comprometido. A gente vê no suporte da FULL que boa parte dos sites reinfectados tinha o editor aberto. A edição segura está no guia de como editar o wp-config.php, e o conjunto de travas no guia de hardening de segurança no WordPress. --- ## Camada 3: Bloqueio de força bruta e mitigação de ataques no login O login é o alvo número um de ataques automatizados, e bloqueá-lo é a terceira camada da mitigação de ataques. Força bruta tenta milhares de senhas por minuto contra wp-login.php e xmlrpc.php. A defesa tem 3 partes: limite de tentativas (5 erros geram bloqueio), 2FA e desativação do xmlrpc.php. Na maioria dos casos, só o limite de tentativas já derruba o bot, que desiste e procura alvo mais fácil. O xmlrpc.php merece atenção porque permite o método `system.multicall`, que empacota centenas de tentativas de senha em uma requisição, multiplicando o ataque. Desativá-lo quando o site não depende dele é mitigação de ataques de baixo custo. Detalhe operacional: plugins legados ainda chamam o xmlrpc, então monitore os logs por 48 horas após desativar. O passo a passo está no guia de como evitar ataques de força bruta no login, e o conceito no verbete de brute force. --- ## Camada 4: Headers HTTP de segurança contra XSS e clickjacking Headers HTTP de segurança instruem o navegador a recusar comportamentos perigosos e fecham a mitigação de ataques do lado do cliente. 4 headers fazem o trabalho pesado: Content-Security-Policy neutraliza XSS refletido; X-Frame-Options bloqueia clickjacking; X-Content-Type-Options para MIME sniffing; e Strict-Transport-Security força HTTPS. Sem CSP, um script injetado executa livremente. O cross-site scripting está entre as falhas mais frequentes: dos 62 CVEs históricos do Elementor, 40 são de severidade média, e a maioria é XSS. Configurar o CSP é mitigação de ataques que não depende de plugin pago, mas exige cuidado para não quebrar scripts do Elementor ou do Google Analytics. Comece em modo report-only por uma semana e só então aplique a política. O passo a passo está no guia de como adicionar cabeçalhos de segurança HTTP, e o mecanismo no artigo sobre cross-site scripting (XSS). --- ## Camada 5: Monitoramento de CVE com dados reais de vulnerabilidade Monitorar CVE é a quinta camada e torna a mitigação de ataques proativa: avisa antes do exploit virar ataque em massa. Um CVE é o identificador oficial de uma falha pública, com nota CVSS de 0 a 10. O que importa é o risco ATUAL, não o total histórico: plugin com muitos CVEs todos corrigidos é sinal de manutenção ativa, não de perigo. O perigo real é a falha sem patch na versão instalada hoje. Dois exemplos reais, segundo o perfil público do WPVulnerability. O Contact Form 7 teve o CVE-2020-35489, CVSS 10.0, que permitia upload irrestrito abaixo da 5.3.2, já corrigido. O Elementor teve o CVE-2023-48777, CVSS 9.9, upload arbitrário por usuário de baixo privilégio abaixo da 3.18.2, também corrigido. O risco vira real só num site em versão antiga. A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, então quem escreve aqui cataloga CVE. Audite o site com o guia de ferramentas para verificar vulnerabilidades e o verbete de CVE. --- ## Passo a passo: Aplicando as 5 camadas de mitigação de ataques Montar a mitigação de ataques completa leva cerca de 90 minutos num site de porte médio, e a ordem reduz retrabalho: borda primeiro, aplicação depois. Cada passo abaixo é independente e tem um check de validação no fim. Faça um backup antes de começar, porque mexer em wp-config e headers pode derrubar o site se houver erro de sintaxe. ### Passo 1: Ative o WAF de borda e de aplicação Configure a Cloudflare em modo proxy para o domínio e ative o WAF gerenciado. Em seguida, ative o firewall do All In One WP Security no nível básico. Valide enviando uma requisição com uma aspa simples na URL: a resposta deve ser 403. A dupla camada cobre borda e aplicação sem conflito de regra. ### Passo 2: Aplique o hardening do wp-config Adicione `define('DISALLOW_FILE_EDIT', true);` ao wp-config.php e ajuste a permissão do arquivo para 640 via gerenciador de arquivos ou SSH. Valide tentando acessar Aparência e Plugins: o editor de código deve sumir do menu. Essa trava sozinha já fecha o caminho de backdoor mais comum. ### Passo 3: Limite o login e desative o xmlrpc Ative o limite de 5 tentativas no All In One WP Security, ligue o 2FA para administradores e desative o xmlrpc.php se o site não usa app móvel. Valide errando a senha cinco vezes: o IP deve ser bloqueado por 15 minutos. Monitore os logs por 48 horas. ### Passo 4: Publique os headers de segurança Adicione Content-Security-Policy em modo report-only, X-Frame-Options como SAMEORIGIN, X-Content-Type-Options como nosniff e o Strict-Transport-Security. Valide com uma ferramenta de inspeção de headers: os quatro devem aparecer na resposta. Depois de uma semana sem violações, troque o CSP para enforce. ### Passo 5: Ligue o monitoramento contínuo de CVE Rode um scanner de vulnerabilidade e agende a verificação semanal. O alvo é zero alerta de versão sem patch. Mantenha plugins e temas atualizados, porque um CVE corrigido só protege quem aplicou o patch. --- ## Quando a mitigação de ataques compensa o investimento Montar as cinco camadas com plugins avulsos custa caro: licença de WAF premium, plugin de backup, plugin de 2FA e monitoramento somam fácil mais de R$1.500 por ano por site. No plano PRO da FULL, por R$849, você ativa o All In One WP Security e os outros 16 plugins inclusos em até dez sites, o que dá R$85 por site por ano. A gente vê no suporte da FULL que o custo de limpar um site invadido (perda de SEO, downtime e horas de especialista) supera em muito o da prevenção. Para ativar a camada completa, conheça os planos da FULL. Se o seu site já mostra sinal de invasão, o scanner gratuito ajuda a confirmar antes de agir. Escaneie seu WordPress sem instalação no FULL Scan e consulte o repositório de vulnerabilidades para checar se algum plugin instalado tem falha conhecida.Precisa porque cada camada para um tipo de ameaça distinto e nenhuma cobre tudo. O WAF barra payload malicioso, mas não impede um login comprometido de injetar backdoor pelo editor de plugins. O hardening do wp-config fecha esse vão, mas não detém força bruta. Por isso a defesa em cinco camadas: WAF, hardening, login, headers e CVE. Segundo o Cloudflare Radar, a borda mitiga 82,4% dos ataques, mas os 16,4% restantes exigem inspeção na aplicação.
Sim, é possível cobrir boa parte do risco sem WAF pago. O plano gratuito da Cloudflare entrega WAF gerenciado básico, e o All In One WP Security oferece firewall de aplicação sem custo de licença. Some a isso o hardening do wp-config e os headers HTTP, que não custam nada, e você fecha três das cinco camadas de graça. O WAF pago agrega regras avançadas e suporte, mas a base de mitigação de ataques não depende dele para parar os ataques automatizados mais comuns.
A mitigação na borda acontece antes da requisição chegar ao servidor, como na Cloudflare, e é ótima para volume e DDoS. A mitigação na aplicação roda dentro do WordPress, como o WAF do All In One WP Security, e inspeciona o que a borda não vê, como upload multipart de formulário. A borda economiza CPU; a aplicação fecha o vão. Os dados do Cloudflare Radar mostram que 82,4% dos ataques são tratados na borda, mas as duas camadas se complementam e não competem.
Leva cerca de 90 minutos num site de porte médio, divididos entre os cinco passos. O WAF e o limite de login são rápidos, em torno de 15 minutos cada. O hardening do wp-config leva 10 minutos. Os headers HTTP exigem mais cuidado, com uma semana de teste em modo report-only antes do enforce. O monitoramento de CVE é uma configuração única de 10 minutos mais a verificação semanal. Faça backup antes, porque erro de sintaxe no wp-config derruba o site.
Um CVE é o identificador oficial de uma vulnerabilidade pública, como o CVE-2023-48777 do Elementor, CVSS 9.9, corrigido na versão 3.18.2. Ele afeta a mitigação de ataques porque transforma a defesa de reativa em proativa: ao monitorar CVE, você sabe quando um plugin instalado virou porta de entrada antes do exploit se espalhar. O que importa é o risco atual, ou seja, a falha sem patch na versão de hoje, não o total histórico de CVEs já corrigidos.