Segurança WordPress: 10 medidas de hardening para sites de clientes

WordPress alimenta mais de 40% da web. Esta popularidade tem um custo: é também o CMS mais atacado do mundo. A Sucuri reporta que mais de 90% dos sites infectados que analisa correm WordPress — não porque o core seja inseguro, mas porque a maioria das instalações nunca foi devidamente protegida. Hardening não é luxo para grandes sites; é a prática mínima que qualquer agência deve aplicar em todos os sites de clientes sob gestão.

Por que o hardening é necessário (e o que não é)

Hardening é o processo de reduzir a superfície de ataque de uma instalação WordPress — ou seja, eliminar ou restringir pontos de entrada que um atacante poderia explorar. É diferente de manutenção regular (updates, backups) e de resposta a incidentes (limpeza após infecção).

A superfície de ataque típica de um WordPress não configurado inclui: o endpoint de autenticação /wp-login.php acessível sem limitações, o XML-RPC activo e exposto, o prefixo de tabelas padrão wp_, a versão do WordPress visível no HTML, o directório /wp-admin/ acessível por qualquer IP, e ficheiros de configuração na webroot com permissões demasiado permissivas.

Cada uma destas exposições, individualmente, pode não ser suficiente para comprometer um site. Em conjunto, constroem um perfil de vulnerabilidade que os scanners automatizados de botnets identificam em segundos. Hardening visa eliminar o máximo possível deste perfil sem quebrar a funcionalidade do site.

Medidas 1 a 3: Configuração base

Medida 1 — Proteger ou mover o acesso ao wp-admin

O URL /wp-login.php é conhecido por todos os atacantes do mundo. A protecção mínima é restringir o acesso por IP (se os administradores tiverem IP fixo) ou adicionar uma camada de autenticação HTTP Basic antes de o WordPress sequer carregar. No .htaccess (Apache):

AuthType Basic
AuthName "Restricted"
AuthUserFile /caminho/.htpasswd
Require valid-user

Uma alternativa menos invasiva é usar um plugin como Wordfence ou iThemes Security para bloquear IPs após N tentativas falhadas. Para Nginx, a restrição por IP faz-se directamente na configuração do server block com allow e deny. O renomear do wp-login.php para um URL personalizado é uma medida adicional (security through obscurity) que não é suficiente por si só mas que reduz dramaticamente o ruído de ataques automatizados.

Medida 2 — Desactivar o XML-RPC

O XML-RPC é um protocolo legado que permite acesso remoto ao WordPress via pedidos HTTP POST para /xmlrpc.php. A Jetpack e o aplicativo móvel do WordPress usam-no, mas a maioria dos sites modernos não precisa. O XML-RPC é frequentemente usado em ataques de força bruta amplificados (uma única chamada pode testar centenas de combinações de credenciais) e em ataques DDoS via WordPress como proxy.

Para desactivar completamente via .htaccess:

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Em alternativa, o filtro WordPress xmlrpc_enabled pode ser usado para desactivar via código no functions.php ou num plugin de funcionalidades: add_filter('xmlrpc_enabled', '__return_false');. Se a Jetpack estiver activa e for necessária, mantenha o XML-RPC mas restrinja a IPs de Jetpack.

Medida 3 — Limitar tentativas de login

Por omissão, o WordPress não limita o número de tentativas de login — um atacante pode tentar milhões de combinações de password sem qualquer limitação do lado da aplicação. A solução é implementar bloqueio de IP após N tentativas falhadas.

Ao nível do servidor, o Fail2Ban monitoriza os logs do servidor web e bloqueia IPs via iptables após padrões de falha detectados. É a solução mais robusta porque actua antes de o pedido chegar ao PHP. Para configurar com WordPress, adicione um filtro ao Fail2Ban que detecte as entradas de log de autenticação falhada do WordPress.

Ao nível do plugin, Limit Login Attempts Reloaded, Wordfence ou Solid Security implementam esta funcionalidade sem acesso ao servidor. Configure: máximo 5 tentativas, bloqueio de 20 minutos após falha, notificação por email ao admin.

Medidas 4 a 6: Controlo de acesso

Medida 4 — 2FA obrigatório para todos os admins

Autenticação de dois factores (2FA) é a medida de segurança com melhor relação custo-benefício disponível. Uma password comprometida (via phishing, reutilização de credenciais ou leak numa outra plataforma) não é suficiente para aceder ao site se o segundo factor estiver activo. Para sites de clientes, 2FA deve ser obrigatório para todos os utilizadores com papel de administrator e editor.

Plugins como WP 2FA, Two Factor ou Google Authenticator implementam TOTP (Time-based One-Time Password) compatível com Google Authenticator, Authy e Bitwarden. Configure o plugin para tornar o 2FA obrigatório e defina um período de graça (ex: 72 horas) para que utilizadores existentes configurem os seus dispositivos antes do bloqueio.

Medida 5 — Gestão rigorosa de roles e permissões

O princípio do mínimo privilégio aplica-se directamente à gestão de utilizadores WordPress. Um redactor de conteúdo não precisa de papel administrator — o papel author ou editor é suficiente. Cada utilizador com mais permissões do que necessita é um vector de ataque adicional.

Auditoria de roles: listar todos os utilizadores e os seus papéis. Verificar que não há utilizadores administrator sem necessidade documentada. Se o site usa papéis personalizados (com plugins como Members ou User Role Editor), verificar que as capacidades atribuídas são mínimas para a função. Rever também utilizadores de aplicações — chaves de API, tokens de integração — que frequentemente ficam com permissões excessivas.

Medida 6 — Remover utilizadores inativos

Contas de utilizadores inactivos são alvos preferidos de ataques: frequentemente têm passwords antigas (potencialmente comprometidas em leaks), não têm 2FA activo, e a sua actividade suspeita pode passar despercebida mais tempo. Definir uma política clara: contas sem login há mais de 90 dias são revistas e desactivadas ou removidas.

Isto é especialmente relevante para agências: ex-colaboradores, freelancers de projectos anteriores, contas de teste criadas durante o desenvolvimento. Uma auditoria semestral de utilizadores deve fazer parte da checklist técnica regular.

Medidas 7 a 9: Ficheiros e servidor

Medida 7 — Desabilitar execução de PHP em /uploads/

O directório /wp-content/uploads/ é acessível ao público e aceita uploads de utilizadores — torna-se num vector de ataque clássico se um atacante conseguir fazer upload de um ficheiro PHP malicioso (webshell). A defesa é impedir a execução de PHP nesse directório, mesmo que um ficheiro PHP seja carregado.

Via .htaccess no directório uploads/:

<Files *.php>
deny from all
</Files>

Para Nginx, adicione à configuração do location correspondente: location ~* /(?:uploads|files)/.*\.php$ { deny all; }. Esta medida deve ser aplicada também aos directórios /wp-content/upgrade/ e temporários de plugins.

Medida 8 — Headers de segurança HTTP

Os headers de segurança HTTP instruem o browser a aplicar políticas de segurança que mitigam classes inteiras de ataques como XSS, clickjacking e injecção de conteúdo. São configurados ao nível do servidor (Apache/Nginx) ou via plugin (Headers Security Advanced & HSTS).

Headers essenciais a configurar:

• Strict-Transport-Security: max-age=31536000; includeSubDomains — força HTTPS por um ano
• X-Content-Type-Options: nosniff — impede MIME type sniffing
• X-Frame-Options: SAMEORIGIN — impede clickjacking via iframes
• Referrer-Policy: strict-origin-when-cross-origin — controla informação de referrer
• Permissions-Policy: camera=(), microphone=(), geolocation=() — desactiva APIs desnecessárias

Para verificar os headers actuais de qualquer site: securityheaders.com oferece uma análise instantânea com classificação e sugestões.

Medida 9 — wp-config.php fora da webroot

O ficheiro wp-config.php contém as credenciais da base de dados, as chaves secretas do WordPress e outras configurações sensíveis. Por omissão fica na raiz da instalação WordPress, que normalmente corresponde à webroot do servidor. Se a configuração do servidor tiver alguma falha que sirva ficheiros PHP como texto, as credenciais ficam expostas.

Mover o wp-config.php um nível acima da webroot elimina este risco. O WordPress detecta automaticamente o ficheiro um nível acima — não é necessária qualquer configuração adicional. Se o hosting não permitir escrita fora da webroot, adicione no .htaccess:

<Files wp-config.php>
Order allow,deny
Deny from all
</Files>

Além disso, defina permissões de ficheiro restritivas: chmod 440 wp-config.php — legível pelo owner e grupo, não executável nem acessível por outros.

Medida 10 + manutenção contínua: monitorização de integridade

Medida 10 — Monitorização de integridade de ficheiros

Hardening é uma fotografia num momento no tempo. Um site bem configurado hoje pode ter ficheiros modificados amanhã por um ataque que explorou uma vulnerabilidade desconhecida (zero-day) ou uma credencial comprometida que não activou 2FA. Monitorização de integridade de ficheiros (FIM — File Integrity Monitoring) detecta alterações não autorizadas comparando hashes dos ficheiros actuais com um baseline conhecido.

O plugin Wordfence inclui FIM e compara os ficheiros core do WordPress e dos plugins com os originais do repositório oficial. O Sucuri Security faz o mesmo com alertas por email. Para uma solução mais robusta ao nível do servidor, AIDE (Advanced Intrusion Detection Environment) ou Tripwire monitorizam o sistema de ficheiros independentemente do WordPress.

Configure alertas por email para qualquer modificação de ficheiro fora de /uploads/ — modificações legítimas acontecem durante updates e raramente no meio da semana às 03:00. Um alerta em horário suspeito é sinal de que algo aconteceu.

Porque o hardening precisa de ser repetido

As medidas de hardening não são permanentes. Cada update major do WordPress ou de um tema pode restaurar configurações de wp-config.php, regenerar o .htaccess, ou introduzir novos endpoints que não estavam cobertos pelo hardening anterior. Uma mudança de tema pode activar o XML-RPC que estava desactivado. Um novo plugin pode adicionar utilizadores de serviço com permissões excessivas.

A prática correcta é rever as configurações de hardening após cada update major e incluir uma verificação de segurança na manutenção regular. O nosso serviço de monitorização 24/7 inclui alertas de alterações suspeitas em tempo real, complementando o hardening estático com vigilância contínua. Para situações onde o hardening não foi suficiente, o nosso suporte urgente cobre resposta a incidentes de segurança. E para garantir que os updates que aplicamos não desfazem configurações de segurança, o processo de atualizações mensais controladas inclui verificação de integridade pós-update.

Segurança é um processo, não um estado. Um site que foi hacked apesar de todas as medidas acima é uma situação diferente de um site que nunca foi protegido — no primeiro caso, o atacante fez um esforço extraordinário ou explorou algo genuinamente novo; no segundo, foi apenas mais um site apanhado num scan automatizado. Para entender o que acontece depois de um compromisso, veja o nosso guia sobre recuperação de WordPress hackeado.