Ataques brute force no WordPress: como prevenir
Um ataque brute force tenta adivinhar a palavra-passe do admin testando milhares de combinações automaticamente. Bots percorrem a Internet a procurar páginas de login do WordPress (/wp-login.php e /wp-admin/) e tentam combinações comuns de utilizador e palavra-passe. Se a palavra-passe é fraca, é uma questão de tempo até ser descoberta.
Sinais de ataque
Site mais lento (o servidor processa milhares de pedidos de login), aumento de uso de CPU no cPanel, entradas nos logs com centenas de tentativas de login falhadas, notificações do Wordfence sobre lockouts, e-mails de “palavra-passe reset” que não pediu.
Protecções essenciais
1. Limitar tentativas de login: o Wordfence bloqueia automaticamente IPs após X tentativas falhadas (configurável). Após 5 tentativas erradas, o IP é bloqueado por 4 horas (ou o tempo que definir).
2. Palavra-passe forte: uma palavra-passe de 16+ caracteres com letras, números e símbolos torna brute force impraticável: mesmo com milhões de tentativas, nunca acerta.
3. 2FA: mesmo que adivinhem a palavra-passe (improvável com palavra-passe forte), o segundo fator bloqueia o acesso.
4. Não usar “admin”: os bots tentam “admin” como utilizador por defeito. Use um nome de utilizador único e não previsível.
5. Alterar URL de login: plugins como WPS Hide Login alteram o URL de login de /wp-login.php para algo personalizado. Os bots não encontram a página de login. Simples e eficaz.
6. CAPTCHA no login: adicione reCAPTCHA ou hCaptcha à página de login. Bloqueia bots automatizados sem incomodar utilizadores humanos.
Bloquear xmlrpc.php
O xmlrpc.php é outro vector de brute force: permite tentativas de login via XML-RPC sem passar pela página de login normal. Se não usa a app mobile do WordPress ou Jetpack, bloqueie-o via .htaccess:
Este exemplo é ilustrativo. Adapte domínio, caminhos e valores ao ambiente e teste numa cópia antes de aplicar. Não repita constantes já definidas nem regras geridas por outra ferramenta.
<Files "xmlrpc.php">
Require all denied
</Files>Proteger a autenticação sem bloquear a equipa
Use contas individuais, palavras-passe distintas e 2FA quando suportado. Limite tentativas com uma política que permita recuperar acesso e tenha em conta clientes atrás de redes partilhadas.
Bloquear um nome de utilizador comum ou mudar o URL de login pode reduzir ruído, mas não substitui os controlos principais. Monitorize falhas e acessos bem-sucedidos inesperados. Se existir suspeita de comprometimento, termine sessões, reveja utilizadores e corrija a origem antes de voltar à operação normal.
Como verificar a proteção sem criar uma falsa sensação de segurança
Uma instalação protegida combina medidas no servidor com medidas na aplicação. Atualize os componentes mantidos pelos respetivos fabricantes, elimine extensões que já não utiliza, aplique permissões adequadas e proteja as contas de administração. Uma firewall pode bloquear determinadas tentativas, mas não corrige vulnerabilidades de um plugin desatualizado.
Registe os eventos relevantes e confirme a existência de backups recuperáveis antes de intervenções de maior risco. Se houver suspeita de comprometimento, preservar registos e identificar o ponto de entrada é tão importante como repor os ficheiros. Limpar apenas a página afetada pode deixar contas fraudulentas ou tarefas maliciosas ativas. A resposta deve distinguir contenção, análise, recuperação e prevenção de reincidência.
Como agir nas primeiras horas depois de um alerta
Identifique o sistema afetado, limite acessos desnecessários e preserve registos. Não elimine ficheiros ou reinstale tudo sem compreender o alcance do incidente. Se suspeita que houve exposição de passwords, substitua-as a partir de um dispositivo de confiança e reveja os administradores existentes.
Depois da contenção, analise a origem e teste a recuperação. Restaurar um backup contaminado pode reproduzir a falha. Distinga factos confirmados de hipóteses para que a resposta não seja orientada por suposições.
Camadas de proteção com funções diferentes
SSL, firewall, proteção contra malware e backups têm objetivos distintos. O HTTPS cifra a comunicação, mas não elimina vulnerabilidades de plugins. Uma cópia de segurança apoia a recuperação, mas não substitui prevenção. A firewall pode bloquear padrões de ataque sem impedir que uma password roubada seja utilizada.
Reveja periodicamente versões, utilizadores e permissões. A empresa deve saber o que é responsabilidade do alojamento e o que pertence à manutenção da aplicação. Esta distinção facilita a resposta quando surge um incidente.
Reforçar o login mantendo acesso à equipa
Valide limitações e autenticação, tendo uma forma segura de recuperar o acesso.
Conheça os nossos planos de alojamento WordPress e indique as funções que precisa de manter a funcionar. Fale connosco se precisa de ajuda a escolher.