Proteger o WordPress: a ordem que compensa

Quem pesquisa «proteger o WordPress» encontra listas com vinte pontos. O problema não é os pontos estarem errados, mas sim estarem lado a lado com o mesmo peso. Os três primeiros valem mais do que os outros dezassete juntos.

1.º lugar: atualizações, e atempadas

A maioria dos sites comprometidos não cai por um ataque sofisticado, mas por uma falha conhecida num plugin para a qual já existe uma atualização há semanas. As varreduras automáticas em massa procuram precisamente isso.

Na prática, isto significa: atualizações de segurança automáticas, atualizações de funcionalidades à mão depois de uma verificação rápida — e um ponto de backup antes de cada atualização, para que o medo da atualização não se torne motivo para a adiar.

Um plugin que não recebe uma atualização há dois anos é um risco, mesmo que funcione. Aproveita para arrumar: o que não é usado deve ser apagado, não desativado.

2.º lugar: o login

A segunda porta mais frequente é uma palavra-passe. Quatro medidas, por esta ordem:

1. Limitar tentativas falhadas — isso tira a base às tentativas automáticas de adivinhar palavras-passe.
2. Impor palavras-passe fortes, pelo menos para todos os que podem publicar.
3. Ativar um segundo fator, pelo menos para os administradores.
4. Nenhuma conta com o nome de utilizador «admin», e nenhuma função acima do necessário.

Mudar o endereço de login é um quinto ponto, mas mais fraco: afasta as varreduras em massa e poupa carga, mas não substitui nenhuma das quatro medidas acima. Quem o usar deve anotar o novo endereço antes de guardar.

3.º lugar: blindagem — configurar uma vez e depois esquecer

• Desativar a edição de ficheiros no backend — é aí que o código malicioso é colocado de preferência
• Desativar o XML-RPC, se nada precisar dele
• Impedir a listagem de diretórios
• Impedir a execução de PHP na pasta de uploads
• Restringir a enumeração de utilizadores através da REST API
• Definir cabeçalhos de segurança

Estes interruptores não custam nada em funcionamento e fecham, cada um, um atalho conhecido. São o ponto com a melhor relação esforço-benefício de toda a lista.

4.º lugar: ver o que muda

A partir daqui já não se trata de impedir, mas de dar por isso. Há duas coisas que compensam:

A verificação do core compara os ficheiros do WordPress com as somas de verificação de api.wordpress.org. Um ficheiro do core alterado é um sinal muito claro — ninguém tem um motivo legítimo para alterar lá alguma coisa.

O vigia de ficheiros regista um estado de referência e assinala desvios. Só é tão bom quanto o momento em que esse estado foi registado: um estado registado depois de uma infeção declara o código malicioso como estado normal.

Regista o estado de referência enquanto o site estiver comprovadamente limpo — de preferência logo após uma instalação nova ou após um restauro verificado.

5.º lugar: firewall e varredura

Ambas fazem sentido e ambas estão, deliberadamente, aqui em baixo. Uma firewall em PHP só corre quando o WordPress já está a arrancar — não substitui uma firewall à frente do servidor web. Uma varredura encontra o que se assemelha aos seus padrões, não todo o código malicioso.

Mais importante do que o número de regras é a forma de lidar com falsos positivos. Uma ferramenta cujo resumo está permanentemente a vermelho já não protege nada — treina o hábito de descartar com um clique. Por isso, deixa a firewall primeiro uma semana apenas a reportar e revê o registo antes de a pores a bloquear.

O que costuma estar no topo e não pertence lá

O ponto que quase todas as listas esquecem

Um plugin de segurança evita incidentes; um backup sobrevive a eles. Quem tivesse de escolher entre os dois deveria ficar com o backup — é a única medida que continua a ajudar mesmo quando todas as outras falharam.

Perguntas frequentes