| Camada | O que para | Ferramenta típica |
|---|---|---|
| Firewall de borda | IP de botnet conhecido, antes do PHP | Cloudflare WAF |
| Limite de login | Força bruta na wp-login.php | All in One Security |
| Segundo fator (2FA) | Senha vazada acertada pelo bot | All in One Security, Authy |
| Proteção de formulário | Spam e injeção via Contact Form 7 | hCaptcha, Akismet |
| Atualização constante | Exploit de plugin desatualizado | Gestão FULL, auto-update |
Legenda: cada camada barra o tráfego que a anterior deixou passar, do firewall de borda até a atualização do plugin.
--- ## Por que ataques automatizados atingem todo site WordPress Ataques automatizados atingem todo site porque o WordPress roda em cerca de 43% da web, o alvo de maior retorno para um bot que opera em escala. Segundo o Cloudflare Radar, em junho de 2026 o Brasil teve 82,4% dos ataques de aplicação como DDoS e 16,4% barrados por WAF. O atacante não mira você: ele varre blocos de IP inteiros procurando wp-login.php, xmlrpc.php e versões vulneráveis de plugin. A gente vê no suporte da FULL que a maioria dos sites invadidos nunca foi alvo pessoal: caiu numa varredura genérica que encontrou um plugin sem atualizar. Entender que o ataque é indiscriminado muda toda a estratégia de defesa: você protege contra um padrão de comportamento de bot, não contra um inimigo específico, e é justamente isso que torna o problema solucionável com camadas previsíveis. --- ## Camada 1: Firewall de borda contra ataques automatizados O firewall de borda é a primeira camada porque descarta o IP da botnet antes do PHP carregar, o que poupa entre 60% e 90% do processamento sob ataque automatizado. Um firewall de borda como o Cloudflare avalia a reputação do IP na rede dele e devolve a requisição hostil sem nunca tocar seu servidor. Quando o firewall vive dentro do WordPress (plugin), o site precisa carregar todo o PHP a cada tentativa só para então decidir bloquear, e esse carregamento é exatamente a CPU que o bot quer esgotar. Esse é o ponto que poucos guias explicam: o firewall de plugin protege contra o exploit, mas não contra a exaustão de recurso. Por isso a defesa madura coloca os dois em série. Quem usa o firewall de borda já corta a maior parte das varreduras de credential stuffing logo na entrada. --- ## Camada 2: Limite de tentativas de login Limitar tentativas de login bloqueia o IP após um número fixo de falhas, travando o ataque de força bruta que martela a wp-login.php com listas de senhas vazadas. Sem esse limite, um bot testa milhares de combinações por minuto contra o mesmo usuário "admin" até acertar. Com bloqueio progressivo (cada nova falha aumenta o tempo de espera), o custo do ataque automatizado dispara e o bot desiste e parte para o próximo alvo. O ataque de força bruta no WordPress é a forma mais comum dessa varredura, e o brute force automatizado depende justamente da ausência desse limite. Configure o limite no firewall do WordPress e desative a enumeração de usuários para que o bot nem descubra qual login atacar primeiro. Veja também o passo a passo de como evitar ataques de força bruta no login e mantenha o registro de IPs reincidentes. --- ## Camada 3: Segundo fator e xmlrpc O segundo fator (2FA) neutraliza a senha que o bot já descobriu: mesmo acertando a credencial, o ataque automatizado trava na exigência do código temporário, que nenhuma botnet consegue gerar. Essa camada é o seguro contra vazamentos de senha que você nem sabe que aconteceram, e é a que mais frustra ataques automatizados de credential stuffing. Em paralelo, desative a xmlrpc.php se não usa app móvel nem Jetpack: a chamada system.multicall permite testar centenas de senhas numa única requisição HTTP, multiplicando a velocidade do ataque. A gente vê no suporte da FULL que desativar a xmlrpc.php corta boa parte das tentativas de login distribuído sem quebrar site nenhum, na maioria dos casos. Para configurar o código temporário, siga o passo a passo de autenticação de dois fatores (2FA) e ative o 2FA em todas as contas de administrador, sem exceção, porque basta um login sem segundo fator para a camada inteira cair. --- ## Cves reais: O que o ataque automatizado procura Ataques automatizados procuram CVEs públicas, ou seja, falhas já catalogadas com identificador oficial que o bot testa em sequência contra versões desatualizadas. O dado importa: um plugin com muitos CVEs todos corrigidos é sinal de manutenção ativa, não de risco. O risco real é a versão antiga ainda instalada, que ataques automatizados encontram em minutos. No Contact Form 7, a CVE-2020-35489 (CVSS 10.0, crítica) permitia upload arbitrário de arquivo em versões anteriores à 5.3.2, e foi varrida em massa por bots logo após a divulgação. No Elementor, a CVE-2023-48777 (CVSS 9.9) atingiu versões abaixo da 3.18.2. Ambas já têm patch: o ataque só funciona em quem não atualizou. A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) pela CISA desde maio de 2022, ou seja, quem escreve aqui cataloga CVE oficialmente, não apenas lê sobre elas. --- ## Como proteger WordPress contra ataques automatizados em 5 passos Os cinco passos abaixo montam as camadas na ordem correta e levam cerca de 40 minutos num site típico. Faça na sequência: cada passo depende do anterior estar no lugar. ### Passo 1: Ative o firewall de borda na Cloudflare Aponte o DNS do domínio para a Cloudflare e ligue o modo de proteção. O firewall de borda passa a avaliar cada requisição pela reputação do IP antes de chegar ao seu servidor, descartando IP de botnet conhecido sem carregar o PHP. É a camada que mais economiza CPU sob ataque automatizado sustentado. ### Passo 2: Instale o All in One Security e limite o login Instale o All in One Security e ative o limite de tentativas de login com bloqueio progressivo. Defina cinco tentativas e bloqueio crescente. Esse passo trava a força bruta na wp-login.php e registra os IPs reincidentes para você auditar depois. ### Passo 3: Ative o segundo fator em todo administrador Ligue o 2FA no All in One Security e exija o código temporário para toda conta de nível administrador. Mesmo que o bot acerte a senha numa lista vazada, o ataque automatizado para aqui. Nunca deixe um administrador sem segundo fator. ### Passo 4: Proteja formulários e desative a xmlrpc.php Adicione hCaptcha ao Contact Form 7 e desative a xmlrpc.php caso não use app móvel. O formulário sem captcha é porta de spam e injeção automatizada; a xmlrpc.php aberta multiplica a velocidade do ataque de login via system.multicall. ### Passo 5: Ative atualização automática de plugins Ligue a atualização automática dos plugins ou delegue a gestão. Como o bot testa CVEs públicas contra versões antigas, manter o plugin atualizado fecha a porta antes do scan chegar. Confira também o hardening de segurança do WordPress para travar permissões de arquivo. --- ## Escaneie e proteja com a base de plugins da FULL Manter cinco camadas em dezenas de sites na unha não escala, e é por isso que a gente reuniu o All in One Security e os outros plugins de segurança no bundle da FULL. O plano PRO sai por R$849 e cobre até dez sites, o que dá R$85 por site, com os plugins premium já licenciados. Para quem cuida de carteira de clientes, esse R$85 por site substitui a compra avulsa de cada licença e a manutenção manual de versão, atualizada de forma centralizada sem você renovar chave a chave. Conheça os planos da FULL e ative o All in One Security já configurado. Antes disso, rode o FULL Scan gratuito para descobrir se algum plugin do seu site já está vulnerável. --- --- ---Sofre porque o bot não escolhe alvo por tamanho: ele varre faixas inteiras de IP testando wp-login.php e versões de plugin em qualquer WordPress exposto. Como a plataforma roda em cerca de 43% da web, todo site novo entra no radar das varreduras em horas. O porte do site não influencia: o que importa para o bot é achar uma porta aberta, como um plugin sem atualizar.
Sim, é possível barrar boa parte deles só com firewall de borda na Cloudflare, que filtra o IP de botnet antes do PHP carregar, sem nenhum plugin no site. O ganho é dobrado: além de bloquear, você economiza a CPU que o ataque tenta esgotar. Para login e 2FA, porém, um plugin como o All in One Security ainda agrega camadas que o firewall de borda sozinho não cobre.
Você identifica olhando o log de acesso: dezenas ou centenas de POST para wp-login.php vindos de IPs variados em poucos minutos são a assinatura de uma força bruta automatizada. Picos de CPU sem tráfego humano correspondente e e-mails de tentativa de login falha também indicam varredura ativa. O FULL Scan e o registro de bloqueios do All in One Security confirmam o padrão em segundos.
O firewall de borda para mais volume, porque descarta o IP malicioso antes de o WordPress carregar, enquanto o firewall de plugin só age depois do PHP rodar. Na prática os dois se complementam: a borda absorve a varredura em massa e poupa CPU, e o plugin trata o exploit específico que passou. Usar apenas o de plugin deixa o servidor exposto à exaustão de recurso sob ataque sustentado.
O ataque automatizado é indiscriminado e o dirigido é sob medida: um botnet testa CVEs e senhas vazadas contra milhares de sites, enquanto o ataque dirigido estuda a sua infraestrutura antes de agir. Na prática, priorize a defesa automatizada: o firewall de borda da Cloudflare e o limite de login do All in One Security já neutralizam a maioria esmagadora, que é varredura de bot. O ataque dirigido é raro, mas as mesmas cinco camadas elevam muito o custo do invasor e ganham tempo para a resposta manual.