TL;DR: Ataque de força bruta no WordPress (brute force) tenta adivinhar sua senha testando milhares de combinações por minuto na tela de login. A defesa combina limite de tentativas, autenticação de dois fatores, proteção da página de login e firewall que bloqueia o atacante na origem. Na hospedagem gerenciada da FULL, a partir de R$849 no plano PRO, o firewall já barra esses ataques antes de chegarem ao WordPress, com custo de R$85 por site.

Ataque de força bruta no WordPress é o mais comum e o mais subestimado dos ataques: bots testam usuário e senha sem parar até acertar ou desistir. A gente vê no suporte da FULL que todo site exposto sofre tentativas de brute force, mesmo os pequenos, porque os ataques são automatizados e não escolhem alvo. Este guia mostra como reconhecer o ataque em andamento e como bloqueá-lo em camadas, da tela de login ao firewall do servidor.

O Que é um Ataque de Força Bruta

Um ataque de força bruta é a tentativa automatizada de descobrir sua senha testando combinações em sequência, uma após a outra, na velocidade que o servidor aguentar. No WordPress, o alvo é quase sempre a página wp-login.php ou o arquivo xmlrpc.php.

O bot parte de listas de senhas comuns e de vazamentos conhecidos, e testa o usuário admin primeiro, porque ainda é o nome padrão em muitos sites. Nos tickets da FULL, sites que mantinham o usuário admin e uma senha reaproveitada caíram em horas sob ataque sustentado. O xmlrpc.php é especialmente perigoso porque permite testar centenas de senhas em uma única requisição, multiplicando a velocidade do ataque. Entender o alvo é o primeiro passo da defesa: proteger wp-login.php e desativar ou restringir o xmlrpc.php fecha as duas portas mais exploradas pelos bots.

Como Saber se Seu Site Está Sob Ataque

Você sabe que está sob ataque de força bruta quando o site fica lento sem motivo aparente, o login falha com mensagens de muitas tentativas, ou os logs mostram dezenas de acessos seguidos ao wp-login.php de um mesmo IP. O consumo de CPU sobe junto.

Plugins de segurança registram e notificam tentativas de login falhas, e esse é o primeiro lugar para olhar. Picos de uso de CPU em horários estranhos, e-mails de redefinição de senha que você não pediu, e lentidão geral são sinais clássicos. A gente vê no suporte da FULL que muitos donos só percebem o ataque quando o servidor estoura o limite de recursos e o site sai do ar. Monitorar as tentativas de login com uma ferramenta como o Wordfence transforma o ataque invisível em um alerta acionável, antes que ele derrube o site ou acerte a senha.

Limitar Tentativas de Login

A defesa mais eficaz e mais simples é limitar o número de tentativas de login por IP. Em vez de permitir testes infinitos, o site bloqueia o IP após um punhado de erros, o que torna a força bruta inviável na prática.

Configure um limite baixo, como cinco tentativas, seguido de um bloqueio temporário que cresce a cada nova rodada de falhas. Isso reduz milhares de tentativas por minuto a um punhado por hora, e o ataque deixa de valer a pena para o bot. Nos testes da FULL, ativar limite de tentativas cortou os ataques de força bruta bem-sucedidos para perto de zero, porque nenhum bot tem paciência para testar uma lista enorme cinco senhas por vez. Combine o limite com a autenticação de dois fatores: mesmo que o bot tivesse tempo infinito, ele travaria no segundo fator. As duas camadas juntas praticamente encerram o vetor de senha.

Proteger e Esconder a Tela de Login

Reduzir a exposição da tela de login corta o ataque pela raiz. Trocar a URL padrão wp-login.php por um endereço personalizado faz os bots baterem em uma porta que não existe mais, e a maioria desiste sem insistir.

Outra medida forte é restringir o acesso ao painel por IP, liberando o wp-admin apenas para os endereços da sua equipe quando isso é viável. Desative o xmlrpc.php se o site não usa aplicativos móveis nem integrações que dependam dele, porque ele é o atalho favorito dos ataques de alta velocidade. Trocar o usuário admin por um nome único também ajuda, já que o bot precisa adivinhar usuário e senha em vez de só a senha. No suporte da FULL, a combinação de URL de login personalizada e xmlrpc desativado derruba a maior parte do ruído de ataque antes mesmo de chegar ao limite de tentativas.

Firewall e Bloqueio na Origem

A camada mais forte é o firewall, que bloqueia o atacante antes de a requisição chegar ao WordPress. Um Web Application Firewall identifica padrões de força bruta e barra o IP malicioso no nível do servidor ou da rede, poupando os recursos do site.

Existem firewalls de plugin, que rodam dentro do WordPress, e firewalls de servidor ou de nuvem, que filtram o tráfego antes de ele tocar no PHP. O firewall de servidor é mais eficiente porque não gasta recursos do site para bloquear o ataque, enquanto o de plugin já carregou o WordPress para então barrar. A gente vê no suporte da FULL que sites atrás de um firewall de borda nem sentem os ataques de força bruta, que são absorvidos antes de gerar carga. Na hospedagem gerenciada da FULL, a partir de R$849 no plano PRO, esse firewall de borda já vem ativo, com custo de R$85 por site. Você confere os planos em full.services/planos.

Quando o Ataque Já Teve Sucesso

Se o brute force acertou a senha, o site está comprometido e a resposta muda de defesa para contenção. O primeiro passo é trocar imediatamente todas as senhas de administrador e forçar logout de todas as sessões ativas, expulsando o invasor.

Em seguida, revise a lista de usuários e remova qualquer administrador que você não criou, porque o invasor costuma criar uma conta de acesso reserva. Rode uma varredura completa de malware, já que um acesso bem-sucedido costuma deixar arquivos maliciosos para garantir o retorno; uma varredura via terminal ajuda a encontrar o que o painel esconde. Se confirmar arquivos infectados, o caminho mais seguro é seguir o processo de limpeza e recuperação de site hackeado e restaurar um backup limpo anterior ao ataque. Depois de limpo, ative todas as camadas de defesa para não repetir o ciclo.

Erros ao Se Defender de Brute Force

O erro mais comum é manter o usuário admin com uma senha reaproveitada de outro serviço, o que entrega metade do trabalho ao atacante. Logo atrás vem não limitar tentativas de login, deixando o bot testar à vontade.

Outro erro recorrente nos tickets da FULL é deixar o xmlrpc.php ativo sem necessidade, abrindo o atalho de alta velocidade para o ataque. Também vemos sites que dependem só de um plugin de segurança e ignoram o firewall de borda, gastando recursos do próprio site para se defender. Por fim, muita gente trata a lentidão como problema de performance quando na verdade é um ataque de força bruta em andamento consumindo CPU. A regra é defender em camadas: limite de tentativas, dois fatores, login protegido, xmlrpc fechado e firewall na origem. Nenhuma camada sozinha basta, mas juntas elas encerram o ataque.

FAQ

Todo site WordPress sofre ataque de força bruta?

Sim, todo site exposto recebe tentativas de força bruta, independente do tamanho. Os ataques são automatizados e varrem a internet sem escolher alvo. A gente vê no suporte da FULL que até sites recém-lançados já registram tentativas nos primeiros dias. Por isso a defesa não é opcional: ela precisa estar ativa desde o primeiro dia do site no ar.

Limitar tentativas de login atrapalha usuários legítimos?

Quase nunca. Um limite de cinco tentativas dá margem de sobra para quem erra a senha algumas vezes, e o bloqueio é temporário. Usuários legítimos raramente erram cinco vezes seguidas. O incômodo eventual de esperar alguns minutos é mínimo perto da proteção que o limite oferece contra milhares de tentativas automatizadas por minuto.

Desativar o xmlrpc.php quebra alguma coisa?

Depende do site. O xmlrpc.php é usado por aplicativos móveis do WordPress e por algumas integrações antigas. Se o seu site não usa o app móvel nem depende de integrações que o exijam, desativá-lo é seguro e fecha um vetor importante de ataque. No suporte da FULL, a maioria dos sites não usa o xmlrpc e ganha em segurança ao desativá-lo.

Firewall de plugin ou de servidor é melhor contra brute force?

O firewall de servidor ou de borda é mais eficiente, porque bloqueia o ataque antes de chegar ao WordPress, sem gastar recursos do site. O firewall de plugin funciona, mas já precisa carregar o WordPress para então barrar, o que consome CPU sob ataque pesado. O ideal é ter o firewall de borda como primeira linha e o plugin como reforço.

Como sei se minha senha foi descoberta por força bruta?

Sinais incluem login em horários que você não fez, novos usuários administradores que você não criou, e-mails de saída que você não enviou e arquivos estranhos no servidor. Se notar qualquer um, troque todas as senhas e rode uma varredura de malware. No suporte da FULL, esses sinais quase sempre confirmam um acesso bem-sucedido que precisa de resposta imediata.

Conclusão

Ataque de força bruta no WordPress é inevitável, mas o sucesso dele não. A defesa que funciona é em camadas: limite as tentativas de login, ative a autenticação de dois fatores, proteja e esconda a tela de login, feche o xmlrpc.php e ponha um firewall na origem para barrar o atacante antes do WordPress. Se o ataque já teve sucesso, troque as senhas, remova contas estranhas, rode varredura de malware e restaure um backup limpo. Para quem quer essa proteção pronta sem montar camada por camada, a hospedagem gerenciada da FULL entrega firewall de borda a partir de R$849 no plano PRO, com custo de R$85 por site, e você confere os planos em full.services/planos. Força bruta só vence onde a defesa não existe.