Definições de Segurança do WordPress Que Tem de Conhecer

Por que a segurança do WordPress é crítica

O CMS mais utilizado dá vida a mais de 43% de todos os sites na internet, o que faz dele o alvo mais comum dos hackers. Cerca de 90.000 ataques a sites WordPress acontecem todos os dias. Os hackers utilizam ferramentas automatizadas que analisam a internet à procura de sites com vulnerabilidades conhecidas — não precisa de ser um alvo de alto perfil para ser atacado. Basta um plugin desatualizado ou uma palavra-passe fraca.

A boa notícia é que pode prevenir a maioria dos ataques aplicando definições de segurança básicas. Não tem de ser programador nem especialista em segurança — tudo o que precisa de fazer é seguir os passos comprovados deste guia e aplicá-los ao seu site.

Proteger o ficheiro wp-config.php

O wp-config.php é o ficheiro mais importante do seu site WordPress. Contém as credenciais da base de dados, as chaves de segurança, o prefixo das tabelas e outra configuração crítica. Se um atacante obtiver acesso a este ficheiro, terá controlo total do seu site.

Mover o wp-config.php

O WordPress procura automaticamente o wp-config.php um diretório acima da raiz web. Isso significa que pode mover este ficheiro de public_html/ para o diretório acima, onde não está acessível através de um navegador web. Esta é uma das medidas de proteção mais simples mas mais eficazes. Se o seu alojamento não permitir o acesso ao diretório acima de public_html, contacte o suporte do cPanel.

Chaves de segurança e salts

O wp-config.php contém 8 chaves de segurança (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e os respetivos pares SALT) que são utilizadas para encriptar cookies e sessões. Se estas chaves forem as predefinidas ou estiverem vazias, as sessões dos utilizadores ficam vulneráveis. Gere chaves únicas na página da WordPress.org Secret Key API e cole-as no wp-config.php. Rode estas chaves periodicamente — isso encerrará automaticamente a sessão de todos os utilizadores e invalidará os cookies existentes.

Desativar a edição de ficheiros

O WordPress tem um editor integrado que permite editar ficheiros PHP de temas e plugins diretamente a partir do painel de administração. Este é um enorme risco de segurança — se um atacante obtiver acesso a uma conta de administrador, pode injetar código malicioso diretamente através do editor. Desative-o adicionando a linha define('DISALLOW_FILE_EDIT', true); ao wp-config.php. Isto não impede as atualizações de plugins e temas, apenas desativa a edição direta de código.

Modo de depuração em produção

Nunca deixe o WP_DEBUG ativado num site em produção. O modo de depuração mostra erros e avisos do PHP aos visitantes, o que revela informação sobre a estrutura do site, os caminhos dos ficheiros e as versões do software. Defina define('WP_DEBUG', false); em produção. Se precisar de informação de depuração, utilize define('WP_DEBUG_LOG', true); com define('WP_DEBUG_DISPLAY', false); para que os erros sejam registados num ficheiro em vez de serem mostrados aos visitantes.

Permissões de ficheiros

Permissões de ficheiros adequadas são a primeira linha de defesa ao nível do servidor. Permissões erradas permitem aos atacantes ler, modificar ou executar ficheiros no seu servidor.

Permissões recomendadas

O WordPress recomenda as seguintes permissões: os diretórios devem ser 755 (o proprietário pode ler, escrever e executar; o grupo e os outros podem ler e executar), os ficheiros devem ser 644 (o proprietário pode ler e escrever; o grupo e os outros só podem ler), o wp-config.php deve ser 640 ou 600 (só o proprietário pode ler e escrever). Nunca utilize permissões 777 — isso significa que toda a gente no servidor pode ler, escrever e executar os seus ficheiros.

Proteger o diretório wp-includes

O diretório wp-includes contém ficheiros centrais do WordPress que nunca devem estar diretamente acessíveis. Adicione uma regra ao ficheiro .htaccess no diretório raiz que bloqueie o acesso direto aos ficheiros PHP em wp-includes. Isto impede os atacantes de executarem diretamente os ficheiros centrais, o que é uma técnica comum nos ataques ao WordPress.

Proteger o diretório uploads

wp-content/uploads é o único diretório no qual o WordPress tem de conseguir escrever (para imagens carregadas, documentos, etc.). Os atacantes tentam frequentemente carregar um ficheiro PHP malicioso disfarçado de imagem e depois executá-lo. Previna isto adicionando uma regra .htaccess ao diretório uploads que proíba a execução de ficheiros PHP. Isto significa que, mesmo que um atacante consiga carregar um ficheiro PHP, o servidor não o executará.

Desativar o XML-RPC

O XML-RPC (xmlrpc.php) é um protocolo mais antigo que permite a aplicações externas comunicar com o WordPress. Era útil antes da REST API, mas hoje representa um risco de segurança significativo.

Por que o XML-RPC é perigoso

O XML-RPC é utilizado para dois tipos de ataques: ataques de força bruta (um atacante pode testar centenas de palavras-passe num único pedido XML-RPC utilizando o método system.multicall, contornando a limitação de taxa na página de início de sessão) e ataques DDoS (a funcionalidade de pingback pode ser abusada para ataques DDoS de amplificação, em que o seu site se torna parte de uma botnet). A maioria das funcionalidades modernas do WordPress (aplicação móvel, Jetpack) utiliza a REST API em vez do XML-RPC.

Como desativar o XML-RPC

A forma mais simples é adicionar uma regra .htaccess que bloqueie o acesso ao ficheiro xmlrpc.php e devolva um estado 403 Forbidden. Em alternativa, utilize o filtro no functions.php: add_filter('xmlrpc_enabled', '__return_false');. Isto desativa a funcionalidade do XML-RPC, mas ainda permite o acesso ao ficheiro (o que significa que o servidor continua a processar o pedido). Para um bloqueio completo, o método .htaccess é melhor.

Cabeçalhos de segurança

Os cabeçalhos de segurança HTTP são instruções que o servidor envia ao navegador para melhorar a segurança do site. A implementação destes cabeçalhos não requer alterações ao código do WordPress — são adicionados ao .htaccess ou à configuração do nginx.

Content-Security-Policy (CSP)

O cabeçalho CSP controla quais os recursos que o navegador pode carregar na sua página. Esta é a proteção mais poderosa contra ataques XSS (Cross-Site Scripting), porque impede a execução de código JavaScript não autorizado. Comece com o cabeçalho Content-Security-Policy-Report-Only para testar a política sem bloquear recursos e, depois, mude para o modo de aplicação. Para o WordPress, a configuração da CSP pode ser complexa devido aos scripts inline e aos recursos externos que os temas e plugins utilizam.

X-Content-Type-Options

O cabeçalho X-Content-Type-Options: nosniff impede o navegador de adivinhar o tipo MIME de um ficheiro. Sem este cabeçalho, um atacante pode carregar um ficheiro malicioso com a extensão errada e o navegador tentará executá-lo com base no conteúdo em vez da extensão. Este é um cabeçalho simples sem efeitos negativos — ative-o sempre.

X-Frame-Options

O cabeçalho X-Frame-Options: SAMEORIGIN impede o seu site de ser carregado dentro de um iframe noutro site. Isto protege contra ataques de clickjacking, em que um atacante sobrepõe um iframe transparente do seu site sobre o dele para enganar os utilizadores e levá-los a clicar em algo. SAMEORIGIN permite iframes apenas a partir do mesmo domínio.

Strict-Transport-Security (HSTS)

O cabeçalho HSTS força o navegador a utilizar sempre uma ligação HTTPS encriptada ao seu site. Assim que o navegador recebe o cabeçalho HSTS, redirecionará automaticamente todos os pedidos HTTP para HTTPS sem contactar o servidor. Isto protege contra ataques de SSL stripping. Utilize Strict-Transport-Security: max-age=31536000; includeSubDomains (1 ano). IMPORTANTE: ative o HSTS apenas depois de ter a certeza de que o SSL funciona corretamente em todas as páginas.

Referrer-Policy

O Referrer-Policy controla quanta informação o navegador envia no cabeçalho Referer quando um utilizador clica numa ligação. Referrer-Policy: strict-origin-when-cross-origin envia o URL completo para pedidos da mesma origem, apenas a origem para pedidos HTTPS de origem cruzada e nada para pedidos HTTP. Isto protege a privacidade dos utilizadores e impede que os parâmetros de URL vazem para sites externos.

Definições de segurança adicionais do WordPress

Alterar o URL de início de sessão

O URL de início de sessão predefinido do WordPress é /wp-admin/ ou /wp-login.php, que todos os atacantes conhecem. Alterar o URL de início de sessão para algo não padronizado (por exemplo, /o-meu-acesso/) elimina a maioria dos ataques de força bruta automatizados, porque os bots não encontrarão a página de início de sessão. Utilize um plugin como o WPS Hide Login para uma alteração fácil sem modificar os ficheiros centrais.

Autenticação de dois fatores (2FA)

A 2FA acrescenta uma segunda camada de proteção para além da palavra-passe. Mesmo que um atacante descubra a sua palavra-passe, não conseguirá aceder à conta sem o segundo fator (geralmente um código do telemóvel). Utilize um plugin como o Google Authenticator ou o Wordfence Login Security para implementar a 2FA em todas as contas de administrador. Esta é uma das medidas de proteção mais eficazes — elimina praticamente todos os ataques de força bruta e de credential stuffing.

Limitar as tentativas de início de sessão

Por defeito, o WordPress permite um número ilimitado de tentativas de início de sessão, o que possibilita os ataques de força bruta. Utilize um plugin como o Limit Login Attempts Reloaded, que bloqueia um endereço IP após um certo número de tentativas falhadas (recomendado: 3-5 tentativas). Combine com um CAPTCHA no formulário de início de sessão para uma proteção adicional.

Atualizações regulares

Esta é a medida de segurança mais importante de todas. 86% dos sites WordPress comprometidos utilizam uma versão desatualizada do WordPress, do tema ou de um plugin. Ative as atualizações automáticas para as versões menores do WordPress (correções de segurança) e verifique as atualizações de plugins e temas pelo menos uma vez por semana. Elimine os plugins e temas inativos, porque até um plugin desativado pode ter uma vulnerabilidade que pode ser explorada.

Conclusão

A segurança do WordPress não é uma tarefa pontual, mas um processo contínuo. Implemente as definições deste guia uma a uma: proteja o wp-config.php, defina as permissões de ficheiros corretas, desative o XML-RPC, adicione cabeçalhos de segurança, altere o URL de início de sessão, ative a 2FA e atualize tudo regularmente. Cada uma destas medidas elimina uma categoria inteira de ataques. Na BeoHosting, os nossos planos de alojamento vêm com proteção do lado do servidor pré-configurada, incluindo um WAF ModSecurity, cópias de segurança automatizadas e análise de malware, mas a proteção do lado do servidor funciona melhor em combinação com um WordPress corretamente configurado.