Você abre o painel de um dos seus sites e o Google Search Console acusa páginas com redirecionamento estranho. Em outro site, o cliente reclama que o formulário de contato começou a enviar spam. Quando você percebe, já são três sites com sintomas diferentes. Proteger WordPress de malware em vários sites não é instalar um plugin de firewall em cada um e esperar o melhor. A ordem importa, e a maioria das receitas começa pelo lugar errado.
Este artigo mostra uma sequência de defesa pensada para quem administra vários sites: o que bloquear primeiro no servidor, o que dá para padronizar no painel da hospedagem e o que exige ação site a site. Também mostra como comparar sites entre si para achar o que já foi comprometido antes de o cliente perceber.
Por que a receita do plugin de firewall falha ao proteger WordPress de malware
O conselho padrão é instalar um plugin de segurança e configurar um firewall de aplicação (WAF). Isso ajuda, mas tem dois furos graves. Primeiro: se o malware entrou por uma credencial de administrador vazada, ele já está dentro. O firewall bloqueia tentativas novas, não remove o que já está instalado. Segundo: se a entrada foi um plugin abandonado com vulnerabilidade conhecida, o firewall pode não cobrir aquela falha específica, porque a regra de proteção depende do fornecedor do plugin de segurança ter publicado a assinatura.
Além disso, quando você tem dez sites, instalar e configurar o mesmo plugin dez vezes consome tempo e cria pontos de configuração diferentes. Um site fica com a regra ativa, outro com a regra desligada por conflito, e você perde a visão do conjunto. Por isso a defesa em camadas começa no servidor, não no painel do WordPress.
Camada 1: o que bloquear no servidor antes de qualquer plugin
Essas ações valem para todos os sites da mesma conta de hospedagem, então você faz uma vez e protege vários. O caminho depende do acesso que você tem.
Impedir execução de PHP na pasta de uploads
A pasta wp-content/uploads deve aceitar apenas imagens, PDFs e arquivos estáticos. Se um invasor conseguir enviar um arquivo .php disfarçado de imagem, ele executa código direto. A correção é uma regra no servidor web. No Apache, um arquivo .htaccess dentro de wp-content/uploads com o conteúdo abaixo resolve:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>No Nginx, a regra vai no bloco do servidor, com location ~* /wp-content/uploads/.*\.php$ { deny all; }. Quem só tem painel de hospedagem costuma encontrar essa opção como “bloquear execução de scripts em uploads” ou similar. Se não encontrar, abra ticket: é uma configuração comum e o suporte faz.
Padronizar permissões de arquivos e pastas
Permissão errada é porta aberta. O padrão seguro é 755 para pastas e 644 para arquivos. O arquivo wp-config.php pode ficar em 600 ou 640. Permissão 777 em qualquer coisa é sinal de alerta: permite que qualquer processo escreva ali.
Com SSH, você corrige em lote:
find /caminho/do/site -type d -exec chmod 755 {} \;
find /caminho/do/site -type f -exec chmod 644 {} \;Sem SSH, o gerenciador de arquivos do painel da hospedagem permite alterar permissões por pasta, mas é lento. Nesse caso, foque nas pastas críticas: raiz do site, wp-content, wp-content/uploads e wp-content/plugins.
Ativar WAF no nível do servidor
Muitas hospedagens oferecem um WAF gerenciado, que filtra requisições antes de chegarem ao WordPress. A vantagem sobre o plugin é que ele protege todos os sites da conta de uma vez e não depende de configuração individual. Verifique no painel da hospedagem se há opção de firewall de aplicação ou proteção contra ataques comuns. Se houver, ative e revise as regras padrão.
Se você administra vários sites em contas diferentes, esse é o momento de considerar um painel central. O 100% WP reúne atualizações, backups e monitoramento de segurança em um só lugar, o que ajuda a enxergar quais sites estão com camadas de proteção desalinhadas.
Camada 2: o que dá para padronizar no painel de hospedagem
Antes de entrar site a site, veja o que a hospedagem oferece como padrão para toda a conta.
- Backups automáticos: confirme a frequência e onde ficam armazenados. Backup que fica no mesmo servidor do site não serve para recuperação após invasão.
- Versão do PHP: versões antigas acumulam vulnerabilidades conhecidas. Padronize a versão mais recente compatível com os sites.
- Certificado SSL: deve estar ativo e renovando automaticamente em todos os domínios.
- Acesso SSH e SFTP: desative FTP puro, que trafega senha sem criptografia.
- Registro de acessos: verifique se os logs ficam disponíveis por tempo suficiente para investigar um incidente.
Esses itens cobrem vários sites de uma vez. O que sobra exige ação individual.
Camada 3: o que exige ação site a site
Aqui não tem atalho. Cada site precisa de verificação própria, porque plugins, temas e usuários são diferentes.
- Atualize tudo: núcleo, plugins e temas. Plugin abandonado é uma das principais portas de entrada. Se um plugin não recebe atualização há mais de um ano, avalie substituí-lo. Veja como priorizar em vulnerabilidade em plugin WordPress: triagem em vários sites.
- Revise usuários administradores: remova contas que não deveriam ter esse papel. Um usuário administrador desconhecido no WordPress é sinal claro de invasão. O passo a passo está em logins WordPress: auditar admins em vários sites.
- Ative autenticação em dois fatores: para todos os administradores, sem exceção. Senha vazada deixa de ser suficiente para entrar.
- Desative edição de arquivos no painel: no
wp-config.php, definadefine('DISALLOW_FILE_EDIT', true);. Isso impede que um invasor com acesso ao painel edite o tema para inserir código. - Instale um plugin de segurança: sim, ele entra, mas depois das camadas anteriores. Escolha um e padronize a configuração entre os sites. Se houver conflito com outro plugin, isole antes de desistir: plugins de segurança WordPress: como isolar conflitos.
Varredura comparativa: como achar o que já foi comprometido
Quando você cuida de vários sites, a comparação entre eles é a ferramenta mais eficiente. Um site limpo serve de referência para achar anomalias nos outros.
Comece pela lista de plugins instalados. Se dois sites usam o mesmo conjunto de plugins e um tem um plugin a mais que ninguém instalou, esse é o primeiro suspeito. O mesmo vale para temas: tema ativo diferente do que você lembra, ou tema na lista que não é usado.
Depois, compare os arquivos. Com SSH, gere a lista de arquivos de cada site e compare:
find /caminho/do/site -type f -name "*.php" -newer /caminho/do/site/wp-config.phpArquivos PHP modificados depois da instalação do WordPress merecem inspeção. Outra pista é arquivo com nome estranho na raiz ou em wp-content, como wp-cache.php ou index2.php que você não criou.
No banco de dados, procure por scripts injetados. Uma consulta simples no phpMyAdmin ajuda:
SELECT * FROM wp_posts WHERE post_content LIKE '%<script%';Ajuste o prefixo da tabela conforme o seu site. Se aparecer script em post que deveria ser texto puro, há injeção. O processo completo de limpeza está em site WordPress hackeado: diagnosticar e limpar em vários sites.
Por fim, verifique tarefas agendadas. O WordPress usa o wp-cron, e malware costuma registrar eventos falsos. Plugins como o WP Crontrol mostram a lista. Evento com nome aleatório ou função desconhecida é suspeito.
Quando essa ordem não se aplica
A sequência acima funciona para sites que ainda estão no ar e que você pode ajustar. Existem casos em que ela não serve.
Se o site já está com o painel inacessível ou redirecionando todos os visitantes, a prioridade é outra: isolar o site, restaurar backup limpo e só depois aplicar as camadas. Nesse cenário, siga WordPress invadido: como confirmar e agir antes de qualquer hardening.
Se a hospedagem não permite acesso SSH nem edição de .htaccess, a camada 1 fica limitada ao que o painel oferece. Nesse caso, avalie migrar para uma hospedagem que dê esse controle, porque sem ele a defesa fica dependente só de plugin.
E se o site é novo, sem tráfego e sem cliente ainda, o esforço de varredura comparativa pode não compensar. Instale limpo, aplique as camadas e siga.
Erros comuns ao proteger WordPress de malware em vários sites
Confiar só no plugin de segurança. Ele é uma camada, não a defesa inteira. Sem permissões corretas e sem bloqueio de execução em uploads, o plugin cobre menos do que parece.
Usar a mesma senha de administrador em vários sites. Uma credencial vazada compromete todos de uma vez. Cada site precisa de senha própria, guardada em gerenciador de senhas.
Ignorar logs. Sem registro de acesso, você não sabe por onde o invasor entrou e vai limpar o site para ele voltar na semana seguinte.
Restaurar backup sem corrigir a porta de entrada. Se a vulnerabilidade continua aberta, o backup limpo será infectado de novo. Corrija a causa antes de restaurar.
Não revisar plugins abandonados. Plugin sem atualização há mais de um ano é risco. Substitua por alternativa mantida ou remova se não for essencial.
Prevenção contínua para quem administra vários sites
Defesa não é evento único. Depois de aplicar as camadas, monitore o que muda. Um painel central ajuda a ver, em uma tela, quais sites estão com atualização pendente, quais tiveram arquivo alterado e quais estão sem backup recente. O 100% WP faz esse tipo de acompanhamento para quem gerencia múltiplos sites, o que reduz a chance de um problema passar despercebido até o cliente reclamar.
Automatize o que for repetitivo: atualizações, backups e verificação de integridade. O que exige julgamento, como revisar usuários administradores e investigar arquivo suspeito, continua manual, mas fica mais rápido quando você tem uma referência de site limpo para comparar.
Se o problema já passou do ponto de diagnóstico e você precisa de ajuda especializada, o serviço de segurança e remoção de malware pode assumir a limpeza enquanto você foca nos outros sites.
