Voc\u00ea abre o painel de um dos seus sites e o Google Search Console acusa p\u00e1ginas com redirecionamento estranho. Em outro site, o cliente reclama que o formul\u00e1rio de contato come\u00e7ou a enviar spam. Quando voc\u00ea percebe, j\u00e1 s\u00e3o tr\u00eas sites com sintomas diferentes. Proteger WordPress de malware em v\u00e1rios sites n\u00e3o \u00e9 instalar um plugin de firewall em cada um e esperar o melhor. A ordem importa, e a maioria das receitas come\u00e7a pelo lugar errado.<\/p>\n
Este artigo mostra uma sequ\u00eancia de defesa pensada para quem administra v\u00e1rios sites: o que bloquear primeiro no servidor, o que d\u00e1 para padronizar no painel da hospedagem e o que exige a\u00e7\u00e3o site a site. Tamb\u00e9m mostra como comparar sites entre si para achar o que j\u00e1 foi comprometido antes de o cliente perceber.<\/p>\n
O conselho padr\u00e3o \u00e9 instalar um plugin de seguran\u00e7a e configurar um firewall de aplica\u00e7\u00e3o (WAF). Isso ajuda, mas tem dois furos graves. Primeiro: se o malware entrou por uma credencial de administrador vazada, ele j\u00e1 est\u00e1 dentro. O firewall bloqueia tentativas novas, n\u00e3o remove o que j\u00e1 est\u00e1 instalado. Segundo: se a entrada foi um plugin abandonado com vulnerabilidade conhecida, o firewall pode n\u00e3o cobrir aquela falha espec\u00edfica, porque a regra de prote\u00e7\u00e3o depende do fornecedor do plugin de seguran\u00e7a ter publicado a assinatura.<\/p>\n
Al\u00e9m disso, quando voc\u00ea tem dez sites, instalar e configurar o mesmo plugin dez vezes consome tempo e cria pontos de configura\u00e7\u00e3o diferentes. Um site fica com a regra ativa, outro com a regra desligada por conflito, e voc\u00ea perde a vis\u00e3o do conjunto. Por isso a defesa em camadas come\u00e7a no servidor, n\u00e3o no painel do WordPress.<\/p>\n
Essas a\u00e7\u00f5es valem para todos os sites da mesma conta de hospedagem, ent\u00e3o voc\u00ea faz uma vez e protege v\u00e1rios. O caminho depende do acesso que voc\u00ea tem.<\/p>\n
A pasta No Nginx, a regra vai no bloco do servidor, com Permiss\u00e3o errada \u00e9 porta aberta. O padr\u00e3o seguro \u00e9 Com SSH, voc\u00ea corrige em lote:<\/p>\n Sem SSH, o gerenciador de arquivos do painel da hospedagem permite alterar permiss\u00f5es por pasta, mas \u00e9 lento. Nesse caso, foque nas pastas cr\u00edticas: raiz do site, Muitas hospedagens oferecem um WAF gerenciado, que filtra requisi\u00e7\u00f5es antes de chegarem ao WordPress. A vantagem sobre o plugin \u00e9 que ele protege todos os sites da conta de uma vez e n\u00e3o depende de configura\u00e7\u00e3o individual. Verifique no painel da hospedagem se h\u00e1 op\u00e7\u00e3o de firewall de aplica\u00e7\u00e3o ou prote\u00e7\u00e3o contra ataques comuns. Se houver, ative e revise as regras padr\u00e3o.<\/p>\n Se voc\u00ea administra v\u00e1rios sites em contas diferentes, esse \u00e9 o momento de considerar um painel central. O 100% WP<\/a> re\u00fane atualiza\u00e7\u00f5es, backups e monitoramento de seguran\u00e7a em um s\u00f3 lugar, o que ajuda a enxergar quais sites est\u00e3o com camadas de prote\u00e7\u00e3o desalinhadas.<\/p>\n Antes de entrar site a site, veja o que a hospedagem oferece como padr\u00e3o para toda a conta.<\/p>\n Esses itens cobrem v\u00e1rios sites de uma vez. O que sobra exige a\u00e7\u00e3o individual.<\/p>\n Aqui n\u00e3o tem atalho. Cada site precisa de verifica\u00e7\u00e3o pr\u00f3pria, porque plugins, temas e usu\u00e1rios s\u00e3o diferentes.<\/p>\n Quando voc\u00ea cuida de v\u00e1rios sites, a compara\u00e7\u00e3o entre eles \u00e9 a ferramenta mais eficiente. Um site limpo serve de refer\u00eancia para achar anomalias nos outros.<\/p>\n Comece pela lista de plugins instalados. Se dois sites usam o mesmo conjunto de plugins e um tem um plugin a mais que ningu\u00e9m instalou, esse \u00e9 o primeiro suspeito. O mesmo vale para temas: tema ativo diferente do que voc\u00ea lembra, ou tema na lista que n\u00e3o \u00e9 usado.<\/p>\n Depois, compare os arquivos. Com SSH, gere a lista de arquivos de cada site e compare:<\/p>\n Arquivos PHP modificados depois da instala\u00e7\u00e3o do WordPress merecem inspe\u00e7\u00e3o. Outra pista \u00e9 arquivo com nome estranho na raiz ou em No banco de dados, procure por scripts injetados. Uma consulta simples no phpMyAdmin ajuda:<\/p>\n Ajuste o prefixo da tabela conforme o seu site. Se aparecer script em post que deveria ser texto puro, h\u00e1 inje\u00e7\u00e3o. O processo completo de limpeza est\u00e1 em site WordPress hackeado: diagnosticar e limpar em v\u00e1rios sites<\/a>.<\/p>\n Por fim, verifique tarefas agendadas. O WordPress usa o A sequ\u00eancia acima funciona para sites que ainda est\u00e3o no ar e que voc\u00ea pode ajustar. Existem casos em que ela n\u00e3o serve.<\/p>\n Se o site j\u00e1 est\u00e1 com o painel inacess\u00edvel ou redirecionando todos os visitantes, a prioridade \u00e9 outra: isolar o site, restaurar backup limpo e s\u00f3 depois aplicar as camadas. Nesse cen\u00e1rio, siga WordPress invadido: como confirmar e agir<\/a> antes de qualquer hardening.<\/p>\n Se a hospedagem n\u00e3o permite acesso SSH nem edi\u00e7\u00e3o de E se o site \u00e9 novo, sem tr\u00e1fego e sem cliente ainda, o esfor\u00e7o de varredura comparativa pode n\u00e3o compensar. Instale limpo, aplique as camadas e siga.<\/p>\n Confiar s\u00f3 no plugin de seguran\u00e7a.<\/strong> Ele \u00e9 uma camada, n\u00e3o a defesa inteira. Sem permiss\u00f5es corretas e sem bloqueio de execu\u00e7\u00e3o em uploads, o plugin cobre menos do que parece.<\/p>\n Usar a mesma senha de administrador em v\u00e1rios sites.<\/strong> Uma credencial vazada compromete todos de uma vez. Cada site precisa de senha pr\u00f3pria, guardada em gerenciador de senhas.<\/p>\n Ignorar logs.<\/strong> Sem registro de acesso, voc\u00ea n\u00e3o sabe por onde o invasor entrou e vai limpar o site para ele voltar na semana seguinte.<\/p>\n Restaurar backup sem corrigir a porta de entrada.<\/strong> Se a vulnerabilidade continua aberta, o backup limpo ser\u00e1 infectado de novo. Corrija a causa antes de restaurar.<\/p>\n N\u00e3o revisar plugins abandonados.<\/strong> Plugin sem atualiza\u00e7\u00e3o h\u00e1 mais de um ano \u00e9 risco. Substitua por alternativa mantida ou remova se n\u00e3o for essencial.<\/p>\n Defesa n\u00e3o \u00e9 evento \u00fanico. Depois de aplicar as camadas, monitore o que muda. Um painel central ajuda a ver, em uma tela, quais sites est\u00e3o com atualiza\u00e7\u00e3o pendente, quais tiveram arquivo alterado e quais est\u00e3o sem backup recente. O 100% WP faz esse tipo de acompanhamento para quem gerencia m\u00faltiplos sites, o que reduz a chance de um problema passar despercebido at\u00e9 o cliente reclamar.<\/p>\n Automatize o que for repetitivo: atualiza\u00e7\u00f5es, backups e verifica\u00e7\u00e3o de integridade. O que exige julgamento, como revisar usu\u00e1rios administradores e investigar arquivo suspeito, continua manual, mas fica mais r\u00e1pido quando voc\u00ea tem uma refer\u00eancia de site limpo para comparar.<\/p>\n Se o problema j\u00e1 passou do ponto de diagn\u00f3stico e voc\u00ea precisa de ajuda especializada, o servi\u00e7o de seguran\u00e7a e remo\u00e7\u00e3o de malware<\/a> pode assumir a limpeza enquanto voc\u00ea foca nos outros sites.<\/p>\nwp-content\/uploads<\/code> deve aceitar apenas imagens, PDFs e arquivos est\u00e1ticos. Se um invasor conseguir enviar um arquivo .php<\/code> disfar\u00e7ado de imagem, ele executa c\u00f3digo direto. A corre\u00e7\u00e3o \u00e9 uma regra no servidor web. No Apache, um arquivo .htaccess<\/code> dentro de wp-content\/uploads<\/code> com o conte\u00fado abaixo resolve:<\/p>\n<FilesMatch \"\\.php$\">\n Require all denied\n<\/FilesMatch><\/code><\/pre>\nlocation ~* \/wp-content\/uploads\/.*\\.php$ { deny all; }<\/code>. Quem s\u00f3 tem painel de hospedagem costuma encontrar essa op\u00e7\u00e3o como “bloquear execu\u00e7\u00e3o de scripts em uploads” ou similar. Se n\u00e3o encontrar, abra ticket: \u00e9 uma configura\u00e7\u00e3o comum e o suporte faz.<\/p>\nPadronizar permiss\u00f5es de arquivos e pastas<\/h3>\n
755<\/code> para pastas e 644<\/code> para arquivos. O arquivo wp-config.php<\/code> pode ficar em 600<\/code> ou 640<\/code>. Permiss\u00e3o 777<\/code> em qualquer coisa \u00e9 sinal de alerta: permite que qualquer processo escreva ali.<\/p>\nfind \/caminho\/do\/site -type d -exec chmod 755 {} \\;\nfind \/caminho\/do\/site -type f -exec chmod 644 {} \\;<\/code><\/pre>\nwp-content<\/code>, wp-content\/uploads<\/code> e wp-content\/plugins<\/code>.<\/p>\nAtivar WAF no n\u00edvel do servidor<\/h3>\n
Camada 2: o que d\u00e1 para padronizar no painel de hospedagem<\/h2>\n
\n
Camada 3: o que exige a\u00e7\u00e3o site a site<\/h2>\n
\n
wp-config.php<\/code>, defina define('DISALLOW_FILE_EDIT', true);<\/code>. Isso impede que um invasor com acesso ao painel edite o tema para inserir c\u00f3digo.<\/li>\nVarredura comparativa: como achar o que j\u00e1 foi comprometido<\/h2>\n
find \/caminho\/do\/site -type f -name \"*.php\" -newer \/caminho\/do\/site\/wp-config.php<\/code><\/pre>\nwp-content<\/code>, como wp-cache.php<\/code> ou index2.php<\/code> que voc\u00ea n\u00e3o criou.<\/p>\nSELECT * FROM wp_posts WHERE post_content LIKE '%<script%';<\/code><\/pre>\nwp-cron<\/code>, e malware costuma registrar eventos falsos. Plugins como o WP Crontrol mostram a lista. Evento com nome aleat\u00f3rio ou fun\u00e7\u00e3o desconhecida \u00e9 suspeito.<\/p>\nQuando essa ordem n\u00e3o se aplica<\/h2>\n
.htaccess<\/code>, a camada 1 fica limitada ao que o painel oferece. Nesse caso, avalie migrar para uma hospedagem que d\u00ea esse controle, porque sem ele a defesa fica dependente s\u00f3 de plugin.<\/p>\nErros comuns ao proteger WordPress de malware em v\u00e1rios sites<\/h2>\n
Preven\u00e7\u00e3o cont\u00ednua para quem administra v\u00e1rios sites<\/h2>\n