Como Prevenir Ataques de Força Bruta no WordPress (9 Camadas de Proteção)

Se o seu site WordPress estiver no ar, ele provavelmente está sendo atacado agora mesmo.

Bots automatizados escaneiam a internet continuamente, testando /wp-login.php em todos os sites WordPress que encontram. Eles tentam logins "admin" primeiro, depois uma lista das senhas mais comuns.

Um site sem proteção recebe centenas dessas tentativas todos os dias, silenciosamente, sem nenhum sinal visível.

Pior ainda: ataques falhos não são gratuitos. Cada tentativa de login inicia um processo PHP no seu servidor.

Suficientes tentativas simultâneas e seu plano de hospedagem atinge seus limites.

Visitantes reais começam a ver tempos de carregamento lentos ou páginas de erro. Alguns hosts limitam sua conta automaticamente. Isso acontece mesmo quando nenhum invasor consegue entrar.

Um ataque bem-sucedido é um problema diferente. Acesso total de administrador significa alterações de conteúdo, malware injetado nos seus arquivos de tema, contas de backdoor criadas, spam de SEO embutido nas suas postagens ou dados de clientes expostos.

A recuperação de uma violação bem-sucedida leva horas na melhor das hipóteses; dias se você não tiver um backup limpo.

Nesta postagem, darei as melhores maneiras de defender seu site contra ataques de força bruta.

Aqui estão os principais pontos:

• Mesmo ataques de força bruta falhos prejudicam seu site. Eles esgotam os workers PHP, diminuem os tempos de carregamento e podem acionar o estrangulamento da hospedagem antes que uma única senha seja adivinhada corretamente.
• Credential stuffing não é o mesmo que força bruta. Os invasores usam senhas reais vazadas de outras violações, o que significa que uma senha forte sozinha não é suficiente se seus usuários reutilizarem credenciais.
• O WordPress não tem proteção contra força bruta integrada. Limitação de login, 2FA e funcionalidade WAF exigem um plugin ou configuração de servidor.
• A autenticação de dois fatores é a etapa de maior retorno nesta lista. Ela impede ataques de força bruta e credential stuffing, mesmo quando uma senha está correta.
• O método system.multicall do XML-RPC contorna a maioria das defesas da página de login. Desabilitá-lo fecha uma superfície de ataque separada que os plugins de limitação de taxa não cobrem.
• Alterar seu URL de login reduz o volume de ataques, mas não é uma defesa primária. Trate-o como atrito, não como proteção.
• Um backup que você nunca restaurou é um backup que você realmente não tem. Teste seu processo de restauração trimestralmente antes de precisar dele sob pressão.
• Mais plugins de segurança não significam mais segurança. Um plugin bem configurado supera quatro mal configurados, que podem criar conflitos e sobrecarga.

Sumário

O Que É um Ataque de Força Bruta?

A maioria das pessoas imagina um ataque de força bruta como um bot testando senhas aleatórias até que uma funcione. Isso acontece, mas não é a única versão desse ataque, e nem é mais a mais comum.

Força Bruta Clássica vs. Credential Stuffing

Força bruta clássica é quando um software automatizado tenta todas as combinações possíveis de caracteres até encontrar uma senha que funcione.

Contra uma senha longa e aleatória, isso é impraticável. Uma senha aleatória de 16 caracteres levaria mais tempo para ser descoberta por força bruta do que o sol tem de vida restante.

Credential stuffing é diferente e mais perigoso.

Os atacantes compram ou baixam bancos de dados vazados de outras violações de dados: endereços de e-mail associados a senhas de serviços comprometidos. Em seguida, eles testam esses pares em sites WordPress.

Se um de seus usuários se cadastrou com o mesmo e-mail e senha que usa em todos os outros lugares, o credential stuffing pode obter acesso a eles e fazer login na primeira tentativa.

É por isso que "Eu tenho uma senha forte" não protege totalmente seus usuários. Sua senha pode ser forte. A deles pode não ser.

Ataques de dicionário ficam entre os dois. Em vez de todas as combinações possíveis, eles testam uma lista selecionada de senhas comuns, padrões conhecidos e variações de palavras reais. Mais rápido que força bruta real, mais direcionado que adivinhação aleatória.

O Multiplicador XML-RPC

O WordPress inclui um arquivo chamado xmlrpc.php, originalmente criado para publicação remota e integrações de API. Ele aceita um método chamado system.multicall que permite que uma única requisição HTTP teste milhares de combinações de nome de usuário/senha em uma única chamada.

Isso é importante porque a maioria dos plugins de limitação de login monitora /wp-login.php. Um bot usando xmlrpc.php ignora completamente essa proteção. Limitar a taxa de sua página de login enquanto deixa o XML-RPC aberto é como trancar sua porta da frente e deixar a janela destrancada.

Se você não está usando XML-RPC, fechá-lo é uma das ações de maior retorno nesta lista. A Camada 5 cobre exatamente como.

O Que Até um Ataque Falho Custa a Você

Um ataque de força bruta que nunca adivinha uma única senha correta ainda lhe custa algo real.

Cada tentativa de login é uma requisição HTTP. Cada requisição inicia um processo PHP. Em hospedagem compartilhada, seu plano vem com um número finito de workers PHP simultâneos.

Um ataque de alto volume enche esses workers com tentativas de login em vez de atender seus visitantes reais. O resultado são tempos de carregamento lentos, timeouts e, em casos graves, uma suspensão temporária da hospedagem que você não viu chegando.

Ele também enterra eventos de segurança legítimos em ruído de log. Se um atacante eventualmente conseguir entrar, os logs de tentativas falhas que teriam sinalizado atividade incomum já estarão cheios de milhares de entradas. Você estará procurando uma agulha no palheiro.

Proteções no nível do plugin reduzem o dano. Proteções no nível do servidor e da borda o eliminam. Essa é a razão principal pela qual este guia é estruturado como camadas em vez de uma lista.

Como Prevenir Ataques de Força Bruta no WordPress

Não existe uma única configuração que torne seu site imune. O que funciona são camadas: cada uma captura o que a anterior perde.

Suas credenciais impedem a maioria dos bots automatizados. O rate limiting impede os que passam. Um WAF impede o volume antes que ele atinja seu servidor. Backups cobrem o cenário em que tudo mais falha.

As camadas abaixo estão ordenadas por impacto e facilidade de implementação. Comece pelo topo. Vá o mais longe que sua configuração de hospedagem permitir. Mesmo as três primeiras camadas reduzem drasticamente sua exposição.

Veja o que fazer:

• Camada 1: Credenciais: altere o nome de usuário administrador padrão, use senhas exclusivas em todas as contas e ative a autenticação de dois fatores para todos os administradores
• Camada 2: Limitar tentativas de login: limite as tentativas de login com falha por meio de um plugin ou, para proteção mais forte, por meio do Cloudflare ou do rate limiting no nível do servidor
• Camada 3: Alterar a URL de login padrão: move o endereço que a maioria dos bots visa, reduzindo o volume de ataques automatizados em seu formulário de login
• Camada 4: Adicionar CAPTCHA: filtra envios de bots automatizados no formulário de login; mais eficaz quando combinado com o rate limiting em vez de usado sozinho
• Camada 5: Desabilitar ou restringir XML-RPC: fecha uma superfície de ataque separada que permite aos invasores testar milhares de senhas em uma única solicitação HTTP, contornando as defesas da página de login
• Camada 6: Firewall de Aplicação Web: bloqueia tráfego malicioso e IPs conhecidos como ruins antes que cheguem à sua página de login; WAFs no nível de borda como o Cloudflare evitam o esgotamento de recursos durante ataques de alto volume
• Camada 7: Endurecimento no nível do servidor: restrinja wp-login.php por IP, implemente Fail2ban e use SFTP com autenticação de chave SSH; para proprietários de servidores VPS e dedicados
• Camada 8: Mantenha tudo atualizado: corrige as vulnerabilidades que os invasores exploram para estabelecer um ponto de apoio antes de forçar a entrada mais profundamente
• Camada 9: Faça backup do seu site: a camada final de defesa; um backup offsite testado com um caminho de restauração funcional é a única garantia de que um ataque bem-sucedido não acabará com seu site

Camada 1: Comece com Suas Credenciais

Toda ferramenta automatizada de força bruta começa com o nome de usuário “admin” e as senhas mais comuns. Remover ambos do seu site leva talvez cinco minutos e elimina imediatamente a maioria das tentativas de ataque automatizadas.

Não é uma defesa completa, mas é o retorno sobre o tempo mais rápido que você encontrará em qualquer lugar deste guia.

Use um Nome de Usuário Administrador Não Padrão

Quando o WordPress foi instalado pela primeira vez em seu site, ele sugeriu “admin” como o nome de usuário padrão. Muitos sites nunca o alteram. Os invasores sabem disso, e toda ferramenta de força bruta começa por aí.

Usar um nome de usuário diferente força um invasor a adivinhar dois desconhecidos em vez de um. Isso não é uma melhoria drástica contra um ataque direcionado sofisticado, mas elimina a grande maioria dos bots automatizados que nunca passam pela suposição de “admin”.

Para verificar seu nome de usuário atual, vá para Usuários » Perfil no wp-admin. O campo nome de usuário está nas configurações de Nome.

O WordPress não permite que você altere seu nome de usuário diretamente, mas você pode criar uma nova conta de administrador com um nome de usuário diferente, transferir a propriedade do seu conteúdo e excluir a antiga conta de "admin".

Usuários do WP-CLI podem fazer isso em um único comando:

wp user update 1 --user_login=yourname

Use Senhas Fortes e Únicas para Cada Conta

Cada conta de administrador em seu site precisa de sua própria senha exclusiva.

A "credential stuffing" funciona testando pares de nome de usuário/senha conhecidos de outros vazamentos. Se um usuário reutilizou sua senha de e-mail em vários sites e essa senha vazou em outro lugar, a "credential stuffing" poderia fazer login na primeira tentativa.

O WordPress inclui um medidor de força de senha integrado que sinaliza senhas fracas na tela de perfil. Isso impede as piores escolhas, mas não impõe um comprimento mínimo nem impede a reutilização.

Para mais controle, o Gerenciador de Políticas de Senha permite definir requisitos de senha em todo o site e forçar redefinições para contas que não os atendem.

Ative a Autenticação de Dois Fatores

Com o 2FA ativado, uma senha correta não é suficiente para fazer login. O invasor também precisa de um código sensível ao tempo de um dispositivo físico que ele não possui.

Isso impede ataques clássicos de força bruta, "credential stuffing" e de dicionário. Mesmo que um invasor tenha sua senha exata de um vazamento de dados, ele não poderá fazer login sem o segundo fator.

O núcleo do WordPress não inclui 2FA. Você precisa de um plugin.

O WP 2FA é gratuito, ativamente mantido e simples de configurar. Ele suporta aplicativos autenticadores como Google Authenticator, Authy e 1Password.

miniOrange 2FA e o plugin Two Factor são outras opções amplamente utilizadas com flexibilidade adicional de configuração.

As "passkeys" são a alternativa mais nova. Elas usam o padrão WebAuthn e são resistentes a phishing por design: não há código para interceptar, SMS para "sim-swap" ou aplicativo autenticador para comprometer. O suporte a plugins ainda está amadurecendo, mas se sua configuração o suportar, as "passkeys" valem a pena considerar.

Aplique o 2FA a todas as contas de administrador do site. Não apenas à sua. Uma conta de administrador desprotegida é tudo que um invasor precisa.

Camada 2: Limite as Tentativas de Login

Por padrão, o WordPress permite tentativas de login ilimitadas. Um bot pode tentar dez mil senhas no tempo que você leva para fazer um café.

A limitação de taxa interrompe isso após algumas tentativas, bloqueando o IP ofensor antes que ele chegue perto de uma credencial correta.

Limitação de Login Baseada em Plugin

Plugins de limitação de login funcionam rastreando tentativas falhas por endereço IP. Após um certo número de falhas, o plugin bloqueia esse IP por um período definido. O bot do invasor segue em frente.

O Limit Login Attempts Reloaded é a opção gratuita mais utilizada, com uma tela de configuração simples e sem "bloat".

O Wordfence inclui limitação como parte de seu conjunto mais amplo de recursos, o que o torna digno de consideração se você deseja um único plugin cobrindo várias camadas de segurança.

Para a maioria dos sites, 5-10 tentativas falhas antes de um bloqueio temporário é um ponto de partida razoável.

Limiares mais baixos aumentam a segurança, mas podem criar dores de cabeça no suporte. Escritórios corporativos, universidades e redes móveis geralmente compartilham um único IP entre centenas de usuários. Uma pessoa digitando a senha incorretamente três vezes bloqueia todos os outros.

Teste seu limiar em relação a como seus usuários realmente fazem login.

Uma limitação que vale a pena saber: plugins de camada de aplicativo ainda invocam o PHP em cada solicitação que processam. Sob um ataque de alto volume genuíno, seu servidor ainda está recebendo todo esse tráfego.

O plugin impede que o invasor tenha sucesso, mas não impede o consumo de recursos. É disso que a próxima seção trata.

Quando Mover a Proteção para Cima na Pilha

O plano gratuito da Cloudflare permite criar regras personalizadas de limitação de taxa direcionadas especificamente a /wp-login.php e /xmlrpc.php.

O tráfego é filtrado na borda da Cloudflare antes mesmo de chegar ao seu servidor. Seus workers PHP ficam livres para visitantes reais.

Esta é a atualização mais acessível a partir da proteção em nível de plugin e não custa nada.

Camada 3: Altere o URL de Login Padrão

A maioria dos bots automatizados tem como alvo /wp-login.php porque é onde o WordPress coloca o formulário de login por padrão. Movê-lo para um URL personalizado significa que a maioria dos bots nunca o encontra. Eles recebem um 404, registram seu site como um beco sem saída e seguem em frente.

Esta é uma camada de atrito, não uma defesa primária. Um invasor determinado visando especificamente seu site pode encontrar um URL de login personalizado por outros meios.

Mas reduzir o volume de ataques automatizados tem valor real:

• Menos tentativas de login falhadas
• Menos ruído no log de atividades
• Menos sobrecarga de processos PHP de plugins de aceleração processando solicitações inválidas

O principal risco é perder o URL. Se você esquecer seu caminho de login personalizado e seu host não oferecer acesso de emergência ao wp-admin, você ficará bloqueado do seu próprio site.

Antes de fazer essa alteração, armazene o URL personalizado em seu gerenciador de senhas e confirme o método de acesso de emergência do seu host. Alguns hosts oferecem acesso ao phpMyAdmin ou um redefinição de login assistida pelo suporte.

WPS Hide Login lida com isso com configuração mínima: instale-o, defina seu caminho personalizado e salve.

Uma adição que torna esta etapa mais eficaz: crie uma regra da Cloudflare que retorne um 403 no caminho original /wp-login.php após você o ter movido.

Sem essa regra, o URL antigo ainda existe e responde, o que significa que um scanner persistente ainda pode encontrá-lo sondando caminhos comuns. Bloquear o URL antigo na borda fecha essa lacuna.

Camada 4: Adicione CAPTCHA ao Formulário de Login

O CAPTCHA impede que bots automatizados enviem formulários de login, exigindo prova de interação humana. Um script que atinge sua página de login milhares de vezes por hora não consegue resolver um desafio visual ou comportamental da maneira que uma pessoa consegue.

Para a maioria dos sites, adicionar CAPTCHA ao formulário de login reduz significativamente o volume de envios automatizados.

Tenha em mente que não é imbatível. Existem serviços de resolução de CAPTCHA: humanos reais pagos frações de centavo para resolver desafios em escala ou modelos de aprendizado de máquina treinados para quebrar formatos mais antigos de CAPTCHA.

Contra um invasor direcionado e bem-resourced, o CAPTCHA é um obstáculo. Contra os bots automatizados responsáveis pela vasta maioria do tráfego de força bruta, ele é eficaz.

As três opções que valem a pena considerar adotam uma abordagem diferente.

1. O Google reCAPTCHA v3 roda invisivelmente em segundo plano, pontuando o comportamento do usuário e sinalizando solicitações suspeitas sem pedir nada aos usuários.
2. O hCaptcha adota uma postura focada em privacidade e é uma alternativa direta de substituição.
3. O Cloudflare Turnstile é gratuito, sem atritos para a maioria dos usuários e não envia dados comportamentais para o Google.

Das três, o Turnstile é minha recomendação atual para novas configurações. As trocas de privacidade são melhores e a experiência do usuário é mais limpa.

O Wordfence inclui opções de CAPTCHA. Se você já o está usando, verifique se o CAPTCHA integrado dele cobre seu formulário de login antes de adicionar um plugin separado.

Camada 5: Desabilite ou Restrinja o XML-RPC

XML-RPC foi a API de publicação remota original do WordPress, criada para uma época antes da existência da API REST. A maioria dos sites não a utiliza mais. Deixá-la habilitada dá aos invasores uma superfície de ataque separada que contorna a maioria das defesas da página de login que você configurou até agora.

Xmlrpc.php aceita um método chamado system.multicall que agrupa milhares de tentativas de login em uma única solicitação HTTP.

Um plugin de limitação de taxa monitorando /wp-login.php não a verá. Seu CAPTCHA não será acionado. O ataque atinge abaixo de suas defesas porque é direcionado a uma porta diferente.

Antes de desabilitá-lo, verifique se você realmente o está usando. O Jetpack se conecta ao WordPress.com via XML-RPC. Alguns fluxos de trabalho de publicação móvel mais antigos dependem dele.

Se você não está usando o Jetpack ou publicando de um aplicativo móvel, provavelmente não precisa dele.

Plugins de segurança como o Wordfence têm um alternador de um clique na seção de configurações de login.

O plugin Disable XML-RPC-API é uma alternativa leve se você preferir não instalar uma suíte de segurança completa.

No Nginx ou Apache, você pode bloquear xmlrpc.php no nível do servidor para que a solicitação nunca chegue ao PHP.

Se você precisar de XML-RPC para Jetpack ou outra integração, a correção direcionada é bloquear especificamente system.multicall em vez do endpoint inteiro. Uma regra WAF do Cloudflare pode fazer isso sem quebrar a funcionalidade legítima do XML-RPC.

Restringir o acesso a xmlrpc.php a endereços IP específicos é outra opção para integrações com fontes conhecidas e estáveis.

A API REST é o substituto moderno para novas integrações. Se você estiver construindo algo que teria usado XML-RPC, construa-o contra a API REST em vez disso.

Camada 6: Use um Firewall de Aplicação Web

Um Web Application Firewall (WAF) fica entre o tráfego de entrada e seu site WordPress, inspecionando solicitações e bloqueando as maliciosas antes que cheguem à sua página de login.

Quanto mais perto da borda da rede ele opera, menos trabalho seu servidor faz sob ataque. Um WAF baseado em plugin interrompe ataques depois que eles chegam ao seu servidor. Um WAF de nível de borda os interrompe antes que eles cheguem lá.

WAFs Baseados em Plugin

Plugins WAFs como Wordfence e MalCare filtram requisições na camada de aplicação. Eles mantêm bancos de dados de endereços IP maliciosos conhecidos, assinaturas de bots e padrões de ataque, e bloqueiam requisições correspondentes antes que o WordPress as processe.

Para sites em hospedagem compartilhada onde a configuração do servidor não é acessível, um WAF de plugin é o ponto de partida certo.

A limitação é que seu servidor ainda recebe todas as requisições que o WAF avalia. Sob um ataque em larga escala, o PHP ainda é iniciado, o plugin ainda é executado e seus recursos de hospedagem ainda sofrem o impacto. O invasor não entra, mas o custo de recursos é real.

WAFs no Nível de Borda

O plano gratuito da Cloudflare filtra o tráfego em sua rede global antes que ele chegue ao seu servidor. Gerenciamento de bots, limitação de taxa e desafios de CAPTCHA Turnstile operam na borda.

Seu servidor só vê o tráfego que a Cloudflare já examinou. Durante um ataque de força bruta de alto volume, seu site permanece rápido para visitantes reais porque o tráfego de ataque nunca chega.

A Sucuri oferece um WAF gerenciado com conjuntos de regras específicos para WordPress e uma camada de CDN incluída. É um serviço pago, mas a manutenção de regras gerenciadas vale a pena considerar para sites que não têm um desenvolvedor monitorando ativamente as configurações de segurança.

Hospedagens WordPress gerenciadas, incluindo WP Engine e Kinsta, incluem WAFs de nível de infraestrutura como parte de sua pilha de hospedagem. Se você está em uma dessas plataformas, provavelmente já tem proteção de borda. Confirme com sua hospedagem o que o WAF deles cobre especificamente e se regras personalizadas estão disponíveis.

Uma configuração da Cloudflare que vale a pena implementar: uma regra de firewall personalizada bloqueando todo o tráfego para /wp-admin, exceto do seu endereço IP ou da faixa de IP da sua equipe.

Para sites gerenciados por uma pequena equipe que faz login de IPs previsíveis ou uma VPN compartilhada, este é um dos passos únicos mais eficazes disponíveis. Bots automatizados não conseguem acessar a área administrativa.

Apenas confirme que seu site não usa URLs /wp-admin para funcionalidades voltadas ao cliente (como páginas Minha Conta do WooCommerce ou logins de portal de membros) antes de habilitar esta regra.

Camada 7: Endurecimento no Nível do Servidor

Se você gerencia seu próprio servidor ou VPS, pode direcionar a proteção para cima do WordPress, bloqueando ataques antes que eles toquem o PHP ou qualquer código do WordPress.

Esta seção é para desenvolvedores e proprietários de servidores VPS ou dedicados. Se você está em hospedagem compartilhada sem acesso à configuração do servidor, pule para a Camada 8.

Restringir wp-login.php por IP

Se você e sua equipe sempre fazem login de endereços IP previsíveis, como uma rede de escritório ou uma VPN compartilhada, você pode restringir /wp-login.php a esses IPs no nível do servidor. Cada requisição de qualquer outro IP recebe um 403 antes do WordPress carregar.

No Nginx, isso se parece com isto dentro do seu bloco de servidor:

location = /wp-login.php {

allow 203.0.113.10;

deny all;

}

Substitua o IP pelo seu. Adicione várias linhas de 'allow' para múltiplos IPs. A requisição de qualquer endereço não listado nunca chega ao PHP.

Isso não funciona para sites WooCommerce, plataformas de membros ou qualquer configuração onde os clientes fazem login através do WordPress. É mais adequado para sites de negócios ou portfólio com uma equipe pequena e estável de administradores.

Implementar Fail2ban

O Fail2ban lê os logs do seu servidor e bane automaticamente endereços IP que correspondem a padrões que você define. Para o WordPress, isso significa que um IP que gera entradas de login falhadas repetidas no log é adicionado à lista de bloqueio do seu firewall, geralmente via iptables ou nftables, antes que acumule tentativas suficientes para importar.

Requer um plugin de integração do WordPress para funcionar: o Fail2ban precisa ler as tentativas de login falhadas em um formato analisável, e o WordPress não as escreve nos logs do servidor por padrão.

WP fail2ban cuida disso, escrevendo eventos de autenticação em um formato que o Fail2ban pode analisar diretamente.

O resultado é uma proteção que opera na camada de rede: IPs bloqueados nunca chegam ao seu servidor web, muito menos ao WordPress. Combinado com o rate limiting do Nginx no endpoint de login, esta é a configuração não empresarial mais rigorosa disponível.

Use SFTP e Chaves SSH, Não FTP

Ataques de força bruta não visam apenas sua página de login. O FTP roda na porta 21 e transmite credenciais em texto puro. Atacantes escaneiam portas FTP abertas e executam a mesma abordagem de adivinhação de credenciais que usam no wp-login.php.

O SFTP criptografa a conexão. Se o seu host o suporta, mude para SFTP e desative o FTP completamente. A maioria dos hosts modernos suporta isso; alguns desativam o FTP por padrão.

Para acesso SSH ao seu servidor, use autenticação baseada em chave em vez de autenticação por senha. Um par de chaves SSH elimina o vetor de adivinhação de senha na camada do servidor: não há senha para força bruta.

Gere um par de chaves localmente, adicione a chave pública ao arquivo ~/.ssh/authorized_keys do seu servidor e desative o login SSH baseado em senha no seu sshd_config.

Se você está gerenciando um VPS e ainda não fez isso, é a primeira coisa que vale a pena configurar.

Camada 8: Mantenha o WordPress, Plugins e Temas Atualizados

A força bruta é frequentemente o segundo ataque, não o primeiro. Atacantes frequentemente exploram uma vulnerabilidade em um plugin desatualizado para estabelecer um ponto de apoio, criar uma conta backdoor ou escalar privilégios.

A força bruta vem depois, visando contas que já existem. Manter-se atualizado fecha os pontos de entrada que tornam a força bruta válida em primeiro lugar.

O núcleo do WordPress lida com atualizações de versão menor automaticamente por padrão. Grandes lançamentos exigem ação manual ou uma configuração explícita de atualização automática no painel do seu provedor de hospedagem.

Atualizações automáticas por plugin estão disponíveis diretamente no wp-admin. Vá para Plugins » Plugins Instalados e você verá um alternador Ativar atualizações automáticas na coluna da direita para cada plugin.

Para a maioria dos sites, ativar atualizações automáticas em todos os plugins ativos é a decisão correta. O risco de uma atualização quebrar algo é real, mas muito menor do que o risco de executar um plugin com uma vulnerabilidade conhecida por semanas após o lançamento de um patch.

Temas seguem a mesma lógica. Um tema inativo no seu servidor com uma vulnerabilidade sem patch ainda é explorável, mesmo que não seja o tema ativo.

Exclua tudo o que você não está usando. Desativado não significa seguro.

O mesmo se aplica a plugins. Os arquivos de um plugin desativado ainda estão no servidor e ainda acessíveis. Se existir uma vulnerabilidade nesses arquivos, ela pode ser explorada independentemente de o plugin estar ativo no WordPress.

Se você não estiver usando um plugin, exclua-o completamente em vez de deixá-lo desativado.

Para equipes gerenciando vários sites, ferramentas como ManageWP, MainWP e Jetpack Manage permitem monitorar e aplicar atualizações em todos os sites a partir de um único painel. Executar atualizações um site de cada vez em dez ou vinte instalações é o tipo de atrito que leva a patches perdidos.

Camada 9: Faça Backup do Seu Site e Saiba Como Restaurá-lo

O próprio guia de endurecimento contra força bruta do WordPress.org o afirma claramente: mantenha backups testados e capazes de funcionar offline e ensaie seus procedimentos de restauração.

Cada camada antes desta reduz o risco. Esta elimina o pior resultado possível.

Se um invasor conseguir passar por todas as outras camadas, um backup recente é a diferença entre uma recuperação de uma hora e uma reconstrução total. O backup não impede a violação. Ele determina o quão ruim a violação realmente é.

“Testado” é a palavra que mais importa nessa frase. Testar significa executar uma restauração em um ambiente de staging, confirmar que o site funciona corretamente e saber exatamente quais etapas o processo envolve antes que você precise fazê-lo sob pressão.

Agende um teste de restauração trimestralmente. Leva menos de uma hora e remove toda a incerteza do pior momento.

Automatize Backups e Restaurações com Duplicator

O que torna um backup útil especificamente em um cenário de violação por força bruta: ele precisa estar offsite, independente do servidor comprometido, com um caminho de restauração que funcione mesmo quando o WordPress estiver completamente bloqueado.

Duplicator Pro atende a cada um desses requisitos.

Backups automáticos agendados são executados em intervalos horários, diários, semanais ou mensais sem intervenção manual. Você define o agendamento uma vez e sempre tem um ponto de restauração recente.

Para armazenamento, o Duplicator Pro se conecta ao Amazon S3, Google Drive, Dropbox, OneDrive e outros serviços de nuvem de terceiros.

Duplicator Cloud é o próprio armazenamento do Duplicator: nenhuma conta separada é necessária, nenhum serviço de terceiros para configurar. Ao contrário de outras opções, ele foi construído especificamente para armazenamento de backup do WordPress.

Se algo ruim acontecer, você pode restaurar diretamente do armazenamento em nuvem sem fazer o upload de arquivos para o servidor primeiro. Quando seu servidor for comprometido e você não confiar no que está nele, você puxa a restauração diretamente da cópia na nuvem.

URLs de recuperação de desastres são a parte que a maioria das pessoas não conhece até precisar delas. Após um ataque bem-sucedido de força bruta, uma das primeiras coisas que um invasor faz é alterar a senha de administrador ou criar novas contas e bloquear o proprietário original.

Uma URL de recuperação de desastres ignora completamente o wp-admin, permitindo que você inicie uma restauração mesmo quando não consegue fazer login. Eu usei isso uma vez em um incidente real. É o recurso que faz a diferença entre recuperar em uma hora e passar um dia ao telefone com o suporte de hospedagem.

A restauração com um clique lida com recuperações padrão sem transferências manuais de arquivos ou acesso FTP. Selecione o backup, clique em restaurar e confirme. Esse é o processo.

Como Monitorar Atividade de Força Bruta

A maioria dos proprietários de sites WordPress descobre que está sob ataque por meio de um aviso de limitação de banda do provedor de hospedagem, e não por meio de seu próprio monitoramento. Nesse ponto, o ataque já consumiu recursos do servidor, encheu seus logs de ruído e, em alguns casos, foi bem-sucedido.

Configurar a visibilidade proativa leva menos de uma hora e significa que você sabe o que está acontecendo em seu site antes do seu provedor.

Monitoramento Proativo

Registro de Atividade fornece um registro de auditoria completo de cada ação realizada em seu site, como tentativas de login com falha, logins bem-sucedidos, alterações de função de usuário, ativações e desativações de plugins, modificações de configurações e edições de arquivos.

Esse escopo é importante após uma violação por força bruta. Um invasor que entra não apenas faz login; ele faz alterações.

O Registro de Atividade exibe essas alterações em uma linha do tempo legível para que você possa ver exatamente o que aconteceu e em que ordem. Essa é a informação que você precisa para avaliar o dano e saber o que limpar.

Faça com que o Registro de Atividade envie alertas por e-mail para atividades de login incomuns. Isso o ajudará a identificar e interromper imediatamente um ataque de força bruta em vez de limpar depois dele.

Seu painel de controle de hospedagem é outra camada de monitoramento. Picos inexplicáveis de workers PHP ou uso de CPU fora do horário comercial são frequentemente o primeiro sinal visível de um ataque de alto volume, aparecendo antes que seu plugin de segurança tenha registrado eventos suficientes para disparar um alerta.

Sinais de que você já está sob ataque

Alguns ataques se anunciam. Outros são mais silenciosos.

Um pico repentino em notificações de login com falha em seu registro de atividade é o sinal mais claro. Se você normalmente vê duas ou três tentativas com falha por dia e de repente está vendo centenas, algo mudou.

Avisos de bloqueio de usuários que na verdade não tentaram fazer login são um sinal mais sutil. Bloqueios baseados em IP afetam todos os usuários que compartilham esse IP: um escritório corporativo ou rede universitária onde uma pessoa aciona um bloqueio pode impedir todos os outros na mesma conexão.

Se sua caixa de entrada de suporte começar a encher com mensagens de "Não consigo fazer login" de pessoas que não estavam tentando redefinir suas senhas, verifique seu log de bloqueios.

Lentidão na resposta do wp-admin ou erros de esgotamento de workers PHP no log de erros da sua hospedagem indicam consumo de recursos por um ataque de alto volume. O site ainda funciona, mas está mais lento do que deveria, e os logs explicam o porquê.

Após qualquer incidente de segurança, vá para Usuários » Todos os Usuários no wp-admin e filtre pela função Administrador.

Uma conta de administrador não autorizada criada durante uma janela de ataque é um sinal de que o invasor foi bem-sucedido e deixou uma backdoor para si. Verifique isso antes de considerar um incidente encerrado.

O que não funciona (e por que as pessoas ainda o recomendam)

Alguns dos conselhos de segurança do WordPress mais repetidos soam razoáveis, mas oferecem pouca proteção real. Saber a diferença economiza o esforço de implementar coisas que dão uma falsa sensação de segurança.

Geobloqueio por País

O apelo é óbvio: se a maioria dos seus ataques vier de um país específico, bloqueie esse país. O problema é que as botnets não funcionam dessa maneira.

Uma botnet é uma rede de máquinas comprometidas: roteadores domésticos, servidores, dispositivos IoT, computadores comuns infectados com malware. Essas máquinas estão em todos os lugares, inclusive no seu próprio país.

Bloquear o tráfego da Rússia ou da China não impede uma botnet com nós nos Estados Unidos, Reino Unido e Austrália. Isso bloqueia visitantes legítimos desses países. Para a maioria dos sites, a troca não vale a pena.

Protegendo wp-admin com senha com Autenticação HTTP

Adicionar um segundo prompt de senha antes do diretório wp-admin parece uma camada extra útil. Na prática, pode quebrar o AJAX do WordPress, do qual o wp-admin depende para funcionalidades principais, incluindo salvar posts, executar configurações de plugins e lidar com uploads de mídia.

Sites que implementam isso corretamente com exclusões de AJAX cuidadosas podem fazer funcionar, mas para a maioria dos proprietários de sites, a complexidade da configuração supera o benefício.

Perguntas Frequentes (FAQs)

Antes do Próximo Ataque, Certifique-se de Que Você Pode Se Recuperar Dele

A execução de ataques de força bruta está cada vez mais barata. Botnets baseadas em nuvem, bancos de dados de credenciais de anos de vazamentos acumulados e serviços de resolução de CAPTCHA diminuíram o custo de execução de um ataque sustentado contra um site WordPress para quase zero.

Cada camada de proteção neste post reduz seu risco. Nenhuma delas o reduz a zero. A única garantia de que um ataque bem-sucedido não acabará com seu site é um backup testado do qual você possa restaurar, mesmo quando o wp-admin estiver completamente bloqueado.

Mais de 1,5 milhão de profissionais de WordPress usam o Duplicator Pro exatamente para isso: backups automáticos agendados para o Duplicator Cloud ou qualquer provedor de armazenamento em nuvem principal, recuperação remota sem reenviar arquivos para um servidor comprometido e URLs de recuperação de desastres que restauram seu site mesmo quando você não consegue fazer login.

Se este post fez você pensar sobre segurança e recuperação do WordPress, estes guias valem a pena ser lidos em seguida.

• Como Proteger Seu Site Contra Hackers (Guia Definitivo de Segurança)
• O WordPress é Seguro? Revelando a Verdade
• Checklist de Segurança do WordPress: Guia Passo a Passo para Proteger Seu Site
• Como Recuperar um Site WordPress Invadido (9 Dicas de Especialistas)
• Como Limpar um Site WordPress
• Dominando a Depuração do WordPress: Do Básico a Técnicas Avançadas
• 9 Melhores Plugins de Backup de Banco de Dados WordPress (Para Proteger Seus Dados)