Uma conta de administrador esquecida continua podendo instalar plugins e alterar o site. Abra Usuários > Todos os usuários, filtre essa função e veja quem ainda precisa desse acesso. Esse é um ajuste de segurança no WordPress que você consegue revisar antes de instalar qualquer proteção adicional.
Depois, confira o login, as versões instaladas e os backups. As seções abaixo mostram como configurar cada item e testar o efeito da mudança. Salve uma cópia privada do arquivo antes de editar código. Se o site já está redirecionando visitantes ou publicando spam, faça primeiro a recuperação da instalação invadida.
Checklist de segurança para aplicar no WordPress
Use esta lista para localizar os ajustes que ainda faltam. As seções seguintes mostram os caminhos e os testes.
- Manter o WordPress, os plugins e os temas em versões corrigidas, retirando os componentes sem uso.
- Usar um ramo do PHP que ainda recebe correções de segurança e testar a compatibilidade antes de trocá-lo.
- Reservar a função Administrador para quem precisa gerenciar a instalação.
- Ativar 2FA, guardar os códigos de recuperação e limitar tentativas de login.
- Desativar o editor de arquivos no painel com
DISALLOW_FILE_EDIT. - Bloquear o XML-RPC quando nenhum serviço da instalação depende dele.
- Revisar permissões de escrita e impedir a execução de PHP na pasta de uploads quando ela só deve receber mídias.
- Guardar backups fora da instalação e testar uma restauração.
- Receber alertas de arquivos alterados, novas contas administrativas e falhas de backup numa caixa acompanhada.
Não precisa instalar um plugin para cada item. Veja o que a hospedagem e o plugin de segurança atual já fazem para evitar dois sistemas bloqueando o mesmo login com regras diferentes.
Proteja as contas e configure a autenticação em duas etapas
Em Usuários > Todos os usuários, filtre os administradores. Mantenha apenas as contas que precisam instalar componentes, alterar configurações e administrar a instalação. Para publicar textos, escolha a função compatível com esse trabalho.
Ao retirar uma conta, preserve a autoria dos conteúdos. Se alguém deixou de prestar serviço, revise também seu acesso à hospedagem, ao domínio, ao SFTP e às integrações. Uma senha do WordPress não cancela essas outras entradas.
Como ativar o 2FA no Wordfence
No Wordfence, abra Segurança de acesso e a área de autenticação em dois fatores. Cadastre o autenticador, guarde os códigos de recuperação e informe o código atual para concluir a ativação da sua conta. Em outra janela, faça um novo login para confirmar que a senha e o segundo fator estão funcionando.
Depois, nas configurações de segurança de acesso, defina a exigência para as funções apropriadas e um prazo para os outros usuários concluírem o cadastro. O e-mail que recupera a hospedagem e as contas administrativas também precisa de senha única e segundo fator.
O WP 2FA é uma alternativa para quem quer um plugin dedicado à autenticação. Escolha um responsável pelo 2FA do formulário e teste os códigos de reserva antes de encerrar sua sessão. Se perder o acesso, os métodos de recuperação do painel dependem do recurso que ficou bloqueado.
Limite as tentativas de login
No Wordfence, abra Firewall > Todas as opções do firewall > Proteção contra força bruta. A opção que ativa essa proteção deve estar ligada. Configure quantas falhas provocam o bloqueio, em qual intervalo elas são contadas e por quanto tempo o IP fica bloqueado.
Por exemplo, cinco falhas em cinco minutos e bloqueio por quinze minutos formam um ponto de partida para testar uma instalação com poucos administradores. Ajuste conforme o uso real: uma rede em que várias pessoas compartilham o mesmo IP pode atingir o limite com erros de contas diferentes. O teste deve confirmar tanto o bloqueio de tentativas repetidas quanto o acesso legítimo depois do período.
O plugin conhecido como Limit Login Attempts Reloaded, hoje apresentado como Limit Login Attempts Security, também oferece controle de tentativas. Se esse controle já está ativo no Wordfence ou na hospedagem, configure um deles como responsável e evite sobrepor regras sem conhecer seus efeitos.
Não deixe cadastro aberto criando administradores
Abra Configurações > Geral. Se o site não precisa de cadastro público, deixe desmarcada a opção que permite registrar novos usuários. Se precisa, escolha uma função inicial com as permissões correspondentes, nunca Administrador.
Uma loja pode precisar cadastrar clientes e um portal pode receber colaboradores. Nesses casos, teste o formulário que o visitante realmente usa: plugins também podem manter seus próprios fluxos de cadastro, além da opção geral do WordPress.
Desative a edição de arquivos pelo painel
No gerenciador de arquivos da hospedagem ou por SFTP, baixe uma cópia privada do wp-config.php. Abra o original num editor de texto e acrescente esta linha antes do comentário final que manda parar a edição e antes de carregar wp-settings.php:
define( 'DISALLOW_FILE_EDIT', true );Se a constante já existe, ajuste a definição existente em vez de duplicá-la. Salve e entre no painel: o editor de arquivos de temas e plugins deve ficar indisponível. A edição de páginas e artigos continua funcionando.
Essa configuração retira um caminho de alteração de código pelo painel. Ela preserva a instalação e a atualização normal de plugins. Já DISALLOW_FILE_MODS é mais ampla e também bloqueia instalações e atualizações pelo WordPress; use-a apenas se você mantém outro modo de publicar essas mudanças.
Para desfazer o ajuste, remova a linha acrescentada ou altere seu valor para false. Se um erro de digitação impedir o site de carregar, recoloque a cópia do arquivo pelo mesmo gerenciador que usou para editar.
Revise as chaves de segurança depois de um acesso indevido
As constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e as quatro constantes terminadas em _SALT ficam no wp-config.php. Elas precisam ter valores únicos e privados, em vez do texto padrão de instalação.
Depois de limpar uma invasão e corrigir as contas comprometidas, trocar esses valores invalida os cookies de autenticação anteriores e exige novos logins. Com SSH e WP-CLI, execute na pasta da instalação:
wp config shuffle-saltsO comando atualiza as chaves no arquivo. Confirme antes que tem como entrar novamente e avise as pessoas que usam o painel, porque suas sessões por cookies serão encerradas. Senhas de aplicativo e credenciais de integrações precisam ser revogadas separadamente quando estiverem comprometidas.
Sem WP-CLI, gere um conjunto novo pelo gerador de chaves do WordPress e substitua as oito definições existentes. Não copie o conjunto de outro site nem publique seus valores numa captura. O arquivo continua privado depois da edição.
Quando bloquear o XML-RPC
Se nenhuma integração usa xmlrpc.php, bloqueie esse endereço no servidor ou no firewall. Antes, verifique serviços como Jetpack e aplicativos de publicação remota. Eles podem depender dessa entrada.
Em Apache 2.4 com regras permitidas em .htaccess, este bloco impede o acesso ao arquivo. Coloque-o fora da área entre # BEGIN WordPress e # END WordPress, que o próprio WordPress pode reescrever:
<Files "xmlrpc.php">
Require all denied
</Files>Num servidor Nginx que você administra, a regra equivalente entra no bloco server, não em um arquivo .htaccess:
location = /xmlrpc.php {
deny all;
}No Nginx, valide a configuração com nginx -t antes de recarregar o serviço. Se você usa hospedagem gerenciada sem acesso a essa configuração, procure o bloqueio de XML-RPC no firewall oferecido pelo plano.
Depois, consulte /xmlrpc.php: com as regras acima aplicadas, a resposta esperada é 403. Teste também qualquer integração que você decidiu manter. A mensagem “XML-RPC server accepts POST requests only” mostra que o arquivo está acessível, mesmo que a visita comum por GET não execute um método.
O filtro PHP xmlrpc_enabled desativa métodos que exigem autenticação, mas não bloqueia todo o arquivo nem todos os métodos, como pingbacks. Para retirar o endpoint inteiro, use a regra do servidor ou um controle equivalente do firewall. A API REST em /wp-json/ é outro recurso e participa do editor do WordPress; bloquear as duas por tentativa pode interromper o trabalho.
Mantenha o PHP e os componentes em versões corrigidas
Em Ferramentas > Diagnóstico > Informação > Servidor, leia Versão do PHP. Algumas traduções chamam essa área de Saúde do site. Compare o ramo instalado com a tabela de versões com suporte do PHP.
Escolha um ramo ainda suportado e instale a correção mais recente disponível para ele na hospedagem. Antes de trocar de ramo, teste a cópia do site com os plugins e o tema em uso. Depois, envie um formulário e percorra as funções da loja. O PHP mostrado por php -v no SSH pode ser diferente daquele usado pelo servidor web; a informação do painel refere-se ao WordPress que está atendendo as páginas.
Em Painel > Atualizações, aplique as correções do WordPress e dos componentes instalados. Retire os plugins sem uso e os temas que não precisam permanecer como alternativa. Preserve o tema pai quando um tema filho depende dele.
Se um plugin abandonado tem uma vulnerabilidade sem correção disponível, substitua ou retire sua função. Instalar um scanner não atualiza o componente vulnerável. Baixe plugins e temas do repositório ou do fornecedor autorizado, inclusive os pagos.
Em Plugins > Plugins instalados, a opção Ativar atualizações automáticas permite manter componentes escolhidos recebendo as novas versões. Para um plugin de checkout ou outra função que exige validação antes de mudar, mantenha uma rotina de atualização com teste e backup. Deixar a versão vulnerável parada à espera de uma revisão que nunca acontece prolonga a exposição.
Permissões e arquivos PHP dentro de uploads
Confira o proprietário dos arquivos e as permissões no gerenciador ou no SFTP. Os valores 755 para diretórios e 644 para arquivos são uma referência comum; a aplicação precisa ter a escrita exigida pela configuração da hospedagem. Não aplique 777 ao site inteiro para resolver um erro de envio.
A pasta wp-content/uploads/ normalmente guarda mídias. Se a instalação não precisa executar PHP ali, em Apache 2.4 você pode colocar um .htaccess dentro dessa pasta com:
<FilesMatch "(?i)\.(php[0-9]*|phtml|phar)$">
Require all denied
</FilesMatch>Em Nginx, faça o bloqueio correspondente na configuração do site:
location ~* ^/wp-content/uploads/.*\.(php[0-9]*|phtml|phar)(/|$) {
deny all;
}Esses exemplos consideram o caminho padrão de uploads. Se a instalação usa outra pasta ou há regras Nginx que prevalecem sobre expressões regulares, adapte e valide o alcance. Teste uma mídia que já existe e a resposta para um caminho PHP sob uploads. As imagens devem continuar abrindo. Uma resposta 404 apenas informa ausência do arquivo; a regra de bloqueio precisa ser confirmada na configuração e no teste apropriado.
Se você mantém vários sites na mesma hospedagem, confira quais contas SFTP e usuários do servidor alcançam cada diretório. Separe acessos por site quando o plano permite e retire cópias antigas abertas em pastas como /old/ ou /backup/. Uma instalação esquecida no mesmo espaço pode continuar oferecendo arquivos e credenciais ao invasor.
Escolha o plugin pelo que vai usar e verifique os arquivos
Para reunir firewall, scanner e 2FA, o Wordfence é uma opção disponível no repositório. Para autenticação dedicada, há o WP 2FA. Para controlar tentativas no login, há o Limit Login Attempts Security. Compare as funções já presentes na sua hospedagem antes de instalar mais de um.
No scanner, leia o nome e o caminho do arquivo apontado. Compare um arquivo de plugin público com a versão do repositório; num tema personalizado, compare com a cópia legítima do projeto. Não repare automaticamente uma personalização que você precisa manter.
Com WP-CLI, a conferência dos arquivos do núcleo pode ser feita sem alterar o site:
wp core verify-checksums --include-rootO comando compara os arquivos com os checksums da versão oficial e aponta divergências ou arquivos extras na raiz. Ele não faz a mesma validação de todo o banco, do tema personalizado ou dos uploads. Use a lista para abrir os arquivos indicados e comparar com sua origem.
No Feito por Preto, encontrei arquivos maliciosos no tema que mantinham o acesso do invasor. A recuperação incluiu removê-los e revisar os acessos à instalação. Esse é um motivo para conferir o tema e as pastas adicionais, além dos arquivos do núcleo.
Guarde backups fora do site e saiba restaurá-los
Configure cópias de arquivos e banco num armazenamento separado, com acesso protegido e versões anteriores disponíveis. Uma cópia guardada apenas numa pasta pública pode expor o banco e ser apagada junto com a instalação.
Defina o intervalo pela quantidade de trabalho que você aceita refazer. Uma loja que recebe pedidos ao longo do dia precisa preservar esses registros entre as cópias. Faça um teste de restauração do WordPress em um ambiente protegido e confirme páginas, mídias e os dados recentes.
Direcione os avisos de backup interrompido, arquivo modificado e administrador criado para um e-mail acompanhado. Um alerta com o caminho exato e o horário permite comparar a alteração com uma atualização autorizada. Se a mudança é desconhecida, preserve o registro antes de apagar arquivos.
Conclusão
Deixe o acesso de recuperação pronto antes de testar bloqueios. Em seguida, aplique os ajustes que faltam e confira seu efeito: editor de arquivos indisponível, 2FA funcionando, tentativas limitadas e backup restaurável. Nas configurações do servidor, salve a versão anterior para reverter somente o trecho que causar erro.
Se você precisa manter essa revisão junto das atualizações e dos testes do site, a manutenção WordPress pode incluir esse acompanhamento. Para avaliar o trabalho, me diga quais proteções já usa e quais funções o site precisa continuar oferecendo.
