O painel começa a responder devagar, a hospedagem manda um e-mail sobre uso de CPU e, quando você abre o log, encontra centenas de POST /wp-login.php em poucos minutos. Esse é o padrão mais comum de ataque força bruta WordPress: alguém testando usuário e senha sem parar, muitas vezes de vários IPs ao mesmo tempo. Trocar a senha do admin, nesse cenário, não resolve nada, porque o ataque não depende de uma senha específica. Ele depende de tentar milhares de combinações até uma funcionar.
O que este artigo entrega é diferente de hardening genérico. Aqui o foco é o ataque em si: como identificar o padrão no log, por que a receita comum de plugin de segurança falha em ataque distribuído e qual ordem de bloqueio funciona quando você administra vários sites ao mesmo tempo.
Como reconhecer um ataque força bruta WordPress no log
Antes de bloquear qualquer coisa, você precisa confirmar que é ataque e não tráfego normal. Os sinais costumam aparecer em três lugares: log de acesso do servidor, log do plugin de segurança e métricas de recursos da hospedagem.
No log de acesso, o padrão é rajada. Você vê linhas repetidas de POST /wp-login.php ou POST /xmlrpc.php em sequência, com o mesmo user-agent ou com user-agents vazios. Em ataque distribuído, os IPs mudam a cada poucas requisições, o que dificulta o bloqueio por lista. Em ataque simples, o mesmo IP insiste por horas.
| Sinal | O que indica | Como confirmar |
|---|---|---|
| Rajada de POST em wp-login.php | Tentativa direta de login | Contar requisições por minuto no log |
| POST em xmlrpc.php | Ataque via API, muitas vezes com system.multicall |
Verificar se xmlrpc está ativo e se aparece no log |
| Muitos IPs diferentes | Ataque distribuído | Listar IPs únicos por hora |
| Usuários testados em sequência | Enumeração de logins | Ver nomes como admin, teste, suporte no log |
| Uso de CPU e conexões ao banco subindo | Sobrecarga por tentativas | Comparar com linha de base da hospedagem |
Se o log mostra POST em xmlrpc.php, o ataque pode estar usando a API para testar várias credenciais em uma única requisição. Isso multiplica o volume e explica por que o banco cai antes de você ver milhares de linhas no log.
Por que só trocar a senha não resolve
Trocar a senha do administrador é a primeira coisa que muita gente faz, e é uma reação compreensível. O problema é que o ataque não depende da senha atual. Ele testa combinações até acertar. Se o atacante ainda não acertou, trocar a senha apenas reinicia o relógio. Se ele já acertou, trocar a senha pode expulsá-lo, mas não fecha o caminho que ele usou.
Além disso, em muitos casos o ataque não busca entrar no painel. Ele busca consumir recursos. Um volume alto de tentativas derruba o banco de dados, aumenta o tempo de resposta e, em hospedagem compartilhada, pode levar à suspensão da conta. Nesse cenário, trocar a senha não reduz uma única requisição.
Por isso, a ordem correta é: primeiro bloquear a origem do ataque, depois revisar credenciais e usuários, e por fim endurecer o login. Se você inverter a ordem, o site continua caindo enquanto você mexe em senha.
Ordem de bloqueio que funciona em vários sites
Quando você administra vários sites, o bloqueio precisa ser replicável. A ordem abaixo funciona tanto para quem tem acesso a SSH quanto para quem só tem o painel da hospedagem.
- Confirme o vetor. É wp-login.php, xmlrpc.php ou os dois? Olhe o log antes de agir.
- Bloqueie no servidor, se possível. Regras no servidor web barram a requisição antes do PHP e do banco. Isso alivia a carga imediatamente.
- Desative xmlrpc se não for usado. Muitos sites não precisam da API. Desativar remove um vetor inteiro de ataque.
- Ative limite de tentativas no plugin. Funciona quando você não tem acesso ao servidor, mas depende do PHP estar de pé.
- Revise usuários e senhas. Só depois do bloqueio ativo.
- Monitore por 24 a 48 horas. Ataques distribuídos costumam voltar com outra origem.
Se você tem SSH, o caminho é editar a configuração do servidor web ou usar o firewall da hospedagem. Se só tem painel, o caminho é plugin de segurança com limite de tentativas e, quando disponível, o firewall da própria hospedagem. A diferença importa: regra no servidor bloqueia antes de o WordPress carregar; plugin bloqueia depois.
Limite de tentativas WordPress: servidor ou plugin?
A escolha entre bloquear no servidor e bloquear no plugin depende do que você tem disponível e do tipo de ataque. A tabela abaixo resume.
| Camada | Vantagem | Limitação |
|---|---|---|
| Servidor web ou firewall da hospedagem | Bloqueia antes do PHP e do banco | Exige acesso a SSH ou painel da hospedagem |
| Plugin de segurança | Funciona só com acesso ao painel | Não protege se o banco já estiver sobrecarregado |
| Desativar xmlrpc | Remove vetor inteiro | Pode quebrar apps e integrações que usam a API |
| Autenticação em dois fatores | Impede login mesmo com senha correta | Não reduz o volume de tentativas |
Na prática, a combinação mais eficaz é servidor mais plugin. O servidor segura o volume; o plugin cobre o que passar. Se você só pode escolher um, escolha o servidor, porque ele protege o banco.
Para entender como o limite de tentativas se encaixa em uma estratégia maior, vale revisar a segurança WordPress instalação: hardening em vários sites, que trata das camadas permanentes de defesa.
Quando o ataque já derrubou o banco
Se o site está fora do ar e a hospedagem aponta uso excessivo de conexões, o ataque já passou da fase de tentativa e está consumindo recursos. Nesse caso, a ordem muda.
- Bloqueie primeiro, investigue depois. Enquanto o ataque corre, qualquer análise fica lenta e imprecisa.
- Ative modo de manutenção ou bloqueio total de login. Se possível, negue acesso a wp-login.php e xmlrpc.php para todos, exceto seu IP.
- Verifique se houve acesso bem-sucedido. Procure usuários novos, sessões ativas e alterações em plugins e temas.
- Restaure backup se houver sinal de invasão. Se o atacante entrou, limpar sem restaurar costuma deixar backdoor.
- Só então libere o acesso. Liberar antes de confirmar que a origem está bloqueada reinicia o ciclo.
Se houver sinal de acesso bem-sucedido, o passo seguinte é tratar como incidente. O artigo sobre WordPress invadido: como confirmar e agir detalha o que verificar antes de considerar o site limpo.
Quando a receita comum de plugin falha
Existe um cenário em que o plugin de segurança não resolve, e é importante reconhecê-lo: ataque distribuído que não aparece em lista de IP. Nesse caso, o plugin bloqueia um IP, e o ataque continua de outro. A lista de bloqueio cresce, o banco continua sobrecarregado e o administrador acha que o plugin não funciona.
O mesmo acontece quando a hospedagem não permite editar .htaccess ou não oferece firewall. Sem acesso à camada de servidor, o bloqueio fica dependente do PHP, que é justamente o que o ataque está derrubando.
Nesses casos, as saídas práticas são: ativar o firewall da hospedagem, se existir; migrar o site para um ambiente com mais controle; ou usar um proxy de borda que filtre antes de chegar ao servidor. Nenhuma delas é instantânea, e por isso o monitoramento contínuo importa mais do que a regra isolada.
Para ataques que miram a camada de banco, vale comparar com o padrão descrito em SQL injection WordPress: blindar vários sites de uma vez, porque a lógica de bloqueio na origem é parecida.
Erros comuns ao bloquear força bruta
- Bloquear só o IP que aparece no topo do log e ignorar os demais.
- Desativar xmlrpc sem verificar se algum app ou integração depende dele.
- Confiar apenas no plugin e não monitorar o consumo de recursos.
- Trocar a senha antes de bloquear a origem e achar que o problema acabou.
- Não revisar usuários administradores depois do ataque.
- Esquecer de checar se o ataque atingiu outros sites da mesma hospedagem.
O último item é o mais subestimado. Em hospedagem compartilhada, um ataque em um site pode consumir recursos de todos. Se você administra vários sites no mesmo servidor, trate o incidente como coletivo, não individual.
Prevenção contínua em vários sites
Depois de conter o ataque, o trabalho vira rotina. Três hábitos reduzem bastante a chance de repetir o problema: monitorar tentativas de login com alerta, manter limite de tentativas ativo em todos os sites e revisar usuários administradores periodicamente.
Quando o número de sites cresce, fazer isso site a site deixa de ser viável. É aí que faz sentido centralizar. O painel 100% WP reúne atualizações, backups, monitoramento e segurança em um só lugar, o que ajuda a perceber um ataque em um site antes que ele se espalhe para os outros.
Se o ataque já passou da fase de tentativa e deixou arquivos alterados, o caminho é outro. O artigo sobre site WordPress hackeado: diagnosticar e limpar em vários sites cobre essa etapa.
Por fim, se o volume for constante e a hospedagem não oferecer camada de bloqueio, pode ser hora de avaliar um serviço especializado. A segurança e remoção de malware trata casos em que o ataque já comprometeu arquivos ou banco.
O que fazer agora
Se você chegou até aqui com o site no ar, o próximo passo é abrir o log e confirmar o vetor. Se o site está fora do ar, bloqueie primeiro e investigue depois. Em ambos os casos, não trate o ataque como evento isolado: revise os outros sites, porque a mesma origem costuma testar todos.
Para se aprofundar na camada de identidade, vale revisar como auditar admins em vários sites e remover contas que não deveriam ter acesso. Um ataque força bruta WordPress só vira invasão quando encontra uma porta aberta. Fechar as portas é mais eficiente do que reagir a cada rajada.
