{"id":944,"date":"2026-09-27T17:03:33","date_gmt":"2026-09-27T17:03:33","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/ataque-forca-bruta-wordpress-blindar-varios-sites\/"},"modified":"2026-09-27T17:03:33","modified_gmt":"2026-09-27T17:03:33","slug":"ataque-forca-bruta-wordpress-blindar-varios-sites","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/seguranca\/ataque-forca-bruta-wordpress-blindar-varios-sites\/","title":{"rendered":"Ataque for\u00e7a bruta WordPress: blindar v\u00e1rios sites"},"content":{"rendered":"

O painel come\u00e7a a responder devagar, a hospedagem manda um e-mail sobre uso de CPU e, quando voc\u00ea abre o log, encontra centenas de POST \/wp-login.php<\/code> em poucos minutos. Esse \u00e9 o padr\u00e3o mais comum de ataque for\u00e7a bruta WordPress: algu\u00e9m testando usu\u00e1rio e senha sem parar, muitas vezes de v\u00e1rios IPs ao mesmo tempo. Trocar a senha do admin, nesse cen\u00e1rio, n\u00e3o resolve nada, porque o ataque n\u00e3o depende de uma senha espec\u00edfica. Ele depende de tentar milhares de combina\u00e7\u00f5es at\u00e9 uma funcionar.<\/p>\n

O que este artigo entrega \u00e9 diferente de hardening gen\u00e9rico. Aqui o foco \u00e9 o ataque em si: como identificar o padr\u00e3o no log, por que a receita comum de plugin de seguran\u00e7a falha em ataque distribu\u00eddo e qual ordem de bloqueio funciona quando voc\u00ea administra v\u00e1rios sites ao mesmo tempo.<\/p>\n

Como reconhecer um ataque for\u00e7a bruta WordPress no log<\/h2>\n

Antes de bloquear qualquer coisa, voc\u00ea precisa confirmar que \u00e9 ataque e n\u00e3o tr\u00e1fego normal. Os sinais costumam aparecer em tr\u00eas lugares: log de acesso do servidor, log do plugin de seguran\u00e7a e m\u00e9tricas de recursos da hospedagem.<\/p>\n

No log de acesso, o padr\u00e3o \u00e9 rajada. Voc\u00ea v\u00ea linhas repetidas de POST \/wp-login.php<\/code> ou POST \/xmlrpc.php<\/code> em sequ\u00eancia, com o mesmo user-agent ou com user-agents vazios. Em ataque distribu\u00eddo, os IPs mudam a cada poucas requisi\u00e7\u00f5es, o que dificulta o bloqueio por lista. Em ataque simples, o mesmo IP insiste por horas.<\/p>\n\n\n\n\n\n\n\n
Sinal<\/th>\nO que indica<\/th>\nComo confirmar<\/th>\n<\/tr>\n
Rajada de POST em wp-login.php<\/td>\nTentativa direta de login<\/td>\nContar requisi\u00e7\u00f5es por minuto no log<\/td>\n<\/tr>\n
POST em xmlrpc.php<\/td>\nAtaque via API, muitas vezes com system.multicall<\/code><\/td>\nVerificar se xmlrpc est\u00e1 ativo e se aparece no log<\/td>\n<\/tr>\n
Muitos IPs diferentes<\/td>\nAtaque distribu\u00eddo<\/td>\nListar IPs \u00fanicos por hora<\/td>\n<\/tr>\n
Usu\u00e1rios testados em sequ\u00eancia<\/td>\nEnumera\u00e7\u00e3o de logins<\/td>\nVer nomes como admin, teste, suporte no log<\/td>\n<\/tr>\n
Uso de CPU e conex\u00f5es ao banco subindo<\/td>\nSobrecarga por tentativas<\/td>\nComparar com linha de base da hospedagem<\/td>\n<\/tr>\n<\/table>\n

Se o log mostra POST em xmlrpc.php, o ataque pode estar usando a API para testar v\u00e1rias credenciais em uma \u00fanica requisi\u00e7\u00e3o. Isso multiplica o volume e explica por que o banco cai antes de voc\u00ea ver milhares de linhas no log.<\/p>\n

Por que s\u00f3 trocar a senha n\u00e3o resolve<\/h2>\n

Trocar a senha do administrador \u00e9 a primeira coisa que muita gente faz, e \u00e9 uma rea\u00e7\u00e3o compreens\u00edvel. O problema \u00e9 que o ataque n\u00e3o depende da senha atual. Ele testa combina\u00e7\u00f5es at\u00e9 acertar. Se o atacante ainda n\u00e3o acertou, trocar a senha apenas reinicia o rel\u00f3gio. Se ele j\u00e1 acertou, trocar a senha pode expuls\u00e1-lo, mas n\u00e3o fecha o caminho que ele usou.<\/p>\n

Al\u00e9m disso, em muitos casos o ataque n\u00e3o 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 \u00e0 suspens\u00e3o da conta. Nesse cen\u00e1rio, trocar a senha n\u00e3o reduz uma \u00fanica requisi\u00e7\u00e3o.<\/p>\n

Por isso, a ordem correta \u00e9: primeiro bloquear a origem do ataque, depois revisar credenciais e usu\u00e1rios, e por fim endurecer o login. Se voc\u00ea inverter a ordem, o site continua caindo enquanto voc\u00ea mexe em senha.<\/p>\n

Ordem de bloqueio que funciona em v\u00e1rios sites<\/h2>\n

Quando voc\u00ea administra v\u00e1rios sites, o bloqueio precisa ser replic\u00e1vel. A ordem abaixo funciona tanto para quem tem acesso a SSH quanto para quem s\u00f3 tem o painel da hospedagem.<\/p>\n

    \n
  1. Confirme o vetor.<\/strong> \u00c9 wp-login.php, xmlrpc.php ou os dois? Olhe o log antes de agir.<\/li>\n
  2. Bloqueie no servidor, se poss\u00edvel.<\/strong> Regras no servidor web barram a requisi\u00e7\u00e3o antes do PHP e do banco. Isso alivia a carga imediatamente.<\/li>\n
  3. Desative xmlrpc se n\u00e3o for usado.<\/strong> Muitos sites n\u00e3o precisam da API. Desativar remove um vetor inteiro de ataque.<\/li>\n
  4. Ative limite de tentativas no plugin.<\/strong> Funciona quando voc\u00ea n\u00e3o tem acesso ao servidor, mas depende do PHP estar de p\u00e9.<\/li>\n
  5. Revise usu\u00e1rios e senhas.<\/strong> S\u00f3 depois do bloqueio ativo.<\/li>\n
  6. Monitore por 24 a 48 horas.<\/strong> Ataques distribu\u00eddos costumam voltar com outra origem.<\/li>\n<\/ol>\n

    Se voc\u00ea tem SSH, o caminho \u00e9 editar a configura\u00e7\u00e3o do servidor web ou usar o firewall da hospedagem. Se s\u00f3 tem painel, o caminho \u00e9 plugin de seguran\u00e7a com limite de tentativas e, quando dispon\u00edvel, o firewall da pr\u00f3pria hospedagem. A diferen\u00e7a importa: regra no servidor bloqueia antes de o WordPress carregar; plugin bloqueia depois.<\/p>\n

    Limite de tentativas WordPress: servidor ou plugin?<\/h2>\n

    A escolha entre bloquear no servidor e bloquear no plugin depende do que voc\u00ea tem dispon\u00edvel e do tipo de ataque. A tabela abaixo resume.<\/p>\n\n\n\n\n\n\n
    Camada<\/th>\nVantagem<\/th>\nLimita\u00e7\u00e3o<\/th>\n<\/tr>\n
    Servidor web ou firewall da hospedagem<\/td>\nBloqueia antes do PHP e do banco<\/td>\nExige acesso a SSH ou painel da hospedagem<\/td>\n<\/tr>\n
    Plugin de seguran\u00e7a<\/td>\nFunciona s\u00f3 com acesso ao painel<\/td>\nN\u00e3o protege se o banco j\u00e1 estiver sobrecarregado<\/td>\n<\/tr>\n
    Desativar xmlrpc<\/td>\nRemove vetor inteiro<\/td>\nPode quebrar apps e integra\u00e7\u00f5es que usam a API<\/td>\n<\/tr>\n
    Autentica\u00e7\u00e3o em dois fatores<\/td>\nImpede login mesmo com senha correta<\/td>\nN\u00e3o reduz o volume de tentativas<\/td>\n<\/tr>\n<\/table>\n

    Na pr\u00e1tica, a combina\u00e7\u00e3o mais eficaz \u00e9 servidor mais plugin. O servidor segura o volume; o plugin cobre o que passar. Se voc\u00ea s\u00f3 pode escolher um, escolha o servidor, porque ele protege o banco.<\/p>\n

    Para entender como o limite de tentativas se encaixa em uma estrat\u00e9gia maior, vale revisar a seguran\u00e7a WordPress instala\u00e7\u00e3o: hardening em v\u00e1rios sites<\/a>, que trata das camadas permanentes de defesa.<\/p>\n

    Quando o ataque j\u00e1 derrubou o banco<\/h2>\n

    Se o site est\u00e1 fora do ar e a hospedagem aponta uso excessivo de conex\u00f5es, o ataque j\u00e1 passou da fase de tentativa e est\u00e1 consumindo recursos. Nesse caso, a ordem muda.<\/p>\n

      \n
    1. Bloqueie primeiro, investigue depois.<\/strong> Enquanto o ataque corre, qualquer an\u00e1lise fica lenta e imprecisa.<\/li>\n
    2. Ative modo de manuten\u00e7\u00e3o ou bloqueio total de login.<\/strong> Se poss\u00edvel, negue acesso a wp-login.php e xmlrpc.php para todos, exceto seu IP.<\/li>\n
    3. Verifique se houve acesso bem-sucedido.<\/strong> Procure usu\u00e1rios novos, sess\u00f5es ativas e altera\u00e7\u00f5es em plugins e temas.<\/li>\n
    4. Restaure backup se houver sinal de invas\u00e3o.<\/strong> Se o atacante entrou, limpar sem restaurar costuma deixar backdoor.<\/li>\n
    5. S\u00f3 ent\u00e3o libere o acesso.<\/strong> Liberar antes de confirmar que a origem est\u00e1 bloqueada reinicia o ciclo.<\/li>\n<\/ol>\n

      Se houver sinal de acesso bem-sucedido, o passo seguinte \u00e9 tratar como incidente. O artigo sobre WordPress invadido: como confirmar e agir<\/a> detalha o que verificar antes de considerar o site limpo.<\/p>\n

      Quando a receita comum de plugin falha<\/h2>\n

      Existe um cen\u00e1rio em que o plugin de seguran\u00e7a n\u00e3o resolve, e \u00e9 importante reconhec\u00ea-lo: ataque distribu\u00eddo que n\u00e3o 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\u00e3o funciona.<\/p>\n

      O mesmo acontece quando a hospedagem n\u00e3o permite editar .htaccess ou n\u00e3o oferece firewall. Sem acesso \u00e0 camada de servidor, o bloqueio fica dependente do PHP, que \u00e9 justamente o que o ataque est\u00e1 derrubando.<\/p>\n

      Nesses casos, as sa\u00eddas pr\u00e1ticas s\u00e3o: 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 \u00e9 instant\u00e2nea, e por isso o monitoramento cont\u00ednuo importa mais do que a regra isolada.<\/p>\n

      Para ataques que miram a camada de banco, vale comparar com o padr\u00e3o descrito em SQL injection WordPress: blindar v\u00e1rios sites de uma vez<\/a>, porque a l\u00f3gica de bloqueio na origem \u00e9 parecida.<\/p>\n

      Erros comuns ao bloquear for\u00e7a bruta<\/h2>\n