Reforçar a segurança da site: permissões, cabeçalhos e plugins de segurança

Módulo 7: Segurança · Tempo de leitura: 10 minutos

Objetivo de aprendizagem: Depois desta lição, saberá reforçar a segurança de um site WordPress com permissões, configurações e cabeçalhos de segurança, e avaliar plugins de segurança pelo seu verdadeiro valor.

Conceitos-chave: reforço de segurança (hardening), permissões de ficheiros (644, 755), DISALLOW_FILE_EDIT, nenhum PHP em uploads, listagem de pastas, ocultar versão, X-Powered-By, cabeçalhos de segurança, ficheiros de cópia de segurança e .git na pasta web, WAF no servidor, WAF num plugin, verificador de malware

O que é o reforço de segurança

Reforçar a segurança (hardening) significa: configurar o site de forma a que um erro ou uma falha de segurança cause menos danos. Não substitui as atualizações nem as palavras-passe fortes (lições 7.2 e 7.3), mas reduz as consequências. Pense numa casa: as atualizações são as fechaduras, o reforço de segurança garante que um intruso que, ainda assim, consiga entrar, não chegue ao cofre.

Permissões de ficheiros

Cada ficheiro e cada pasta no servidor tem permissões: quem pode ler, escrever e executar. São escritas como três algarismos, para o proprietário, o grupo e o resto do mundo. A recomendação da documentação do WordPress:

O valor que funciona para wp-config.php depende da forma como o seu alojamento executa o PHP: na maioria do alojamento partilhado, o PHP é executado como o seu próprio utilizador, e nesse caso 600 é suficiente. Experimente e verifique se o seu site continua a funcionar.

Nunca 777. Isso significa: qualquer pessoa no servidor pode escrever. Um manual que diga "configure a pasta como 777 se o carregamento não funcionar" resolve o problema da forma errada. Com um bom alojamento, isso também nunca é necessário.

Configurações em wp-config.php

Algumas linhas que fazem muita diferença (antes de "pare de editar"):

// Não editar ficheiros a partir do painel (Aparência > Editor de temas e Plugins > Editor de plugins).
define( 'DISALLOW_FILE_EDIT', true );

// Mensagens de erro nunca no ecrã dos visitantes (lição 5.4).
define( 'WP_DEBUG', false );

Com DISALLOW_FILE_EDIT desaparece o editor com o qual é possível alterar, a partir do painel, ficheiros PHP de temas e plugins. Um intruso que assuma o controlo de uma conta de administrador deixa assim de poder colocar código malicioso no seu tema com dois cliques. Ainda pode instalar plugins; se também quiser proibir isso (por exemplo, num site que gere para um cliente), existe DISALLOW_FILE_MODS, mas nesse caso as atualizações a partir do painel também deixam de funcionar.

Sem PHP em uploads, sem listagem de pastas

Em wp-content/uploads devem estar imagens e documentos, nunca ficheiros PHP. Intrusos que, através de uma falha, conseguem carregar um ficheiro, tentam precisamente colocar aí um ficheiro PHP e depois pedi-lo. Bloqueie isso com um .htaccess na pasta uploads (no LiteSpeed e no Apache):

<Files *.php>
Require all denied
</Files>

Desative também a listagem de pastas. Sem um index.php ou index.html numa pasta, alguns servidores web mostram uma lista de todos os ficheiros ("Index of /wp-content/uploads/2026/11"). Isso é uma montra para quem procura cópias de segurança ou documentos sensíveis. No .htaccess da sua pasta web:

Options -Indexes

Muitos fornecedores de alojamento já têm isto desativado por predefinição. O exercício desta lição verifica-o.

Sem restos na pasta web

Tudo o que está na pasta web pode ser consultado através da web, exceto o que o servidor executa como PHP ou bloqueia. São perigosos:

• cópias de wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ de um editor de texto): contêm a palavra-passe da sua base de dados e são enviadas como texto (lição 1.3);
• cópias de segurança como backup.zip, site.tar.gz ou database.sql na pasta web;
• uma pasta .git de um programador, com a qual alguém pode descarregar todo o seu código (e por vezes palavras-passe);
• debug.log em wp-content (lição 5.4);
• antigos ficheiros de instalação ou de teste como info.php com phpinfo().

Guarde as cópias de segurança fora da pasta web ou fora do servidor, e elimine os restos.

Ocultar a versão: ganho reduzido

O WordPress coloca, por predefinição, no HTML:

<meta name="generator" content="WordPress 7.1.4" />

e o mesmo no feed RSS. Também o PHP por vezes se identifica num cabeçalho: X-Powered-By: PHP/8.3.14. Ocultar isso é razoável, mas não espere demasiado: os programas dos intrusos simplesmente testam uma falha, independentemente da versão que mostra, e as versões também são muitas vezes dedutíveis a partir de ?ver= depois dos scripts. Ocultar é arrumar, não é segurança. Um site que oculta a sua versão mas não é atualizado continua igualmente vulnerável.

É assim que se faz, num pequeno plugin próprio ou no functions.php do seu tema filho:

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

E o cabeçalho PHP com expose_php = Off nas configurações de PHP do seu fornecedor de alojamento (no DirectAdmin em Select PHP version, Options), ou com Header unset X-Powered-By no .htaccess.

Cabeçalhos de segurança

Com alguns cabeçalhos, indica ao navegador como deve tratar o seu site. Os mais importantes:

No .htaccess (no LiteSpeed e no Apache):

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Depois, teste se tudo continua a funcionar: conteúdo incorporado, botões de pagamento, um widget de chat. Ferramentas externas como securityheaders.com e internet.nl mostram o que o seu site envia.

Plugins de segurança, avaliados com honestidade

Existem muitos plugins de segurança (por exemplo, Wordfence, Solid Security, All-In-One Security, Sucuri). Combinam frequentemente: uma firewall, um verificador de malware, proteção de início de sessão, autenticação de dois fatores, notificações e uma lista de reforço de segurança. Úteis, mas com limites:

• Uma firewall num plugin (WAF) só começa a atuar quando o PHP está em execução. Um pedido malicioso tem de passar primeiro pelo servidor web e pelo PHP antes de o plugin o ver. Uma falha num ficheiro PHP chamado diretamente, ou um ataque que sobrecarrega o próprio PHP, nem sempre é impedido. Uma firewall no servidor (por exemplo, ModSecurity, Imunify360 ou uma firewall do seu fornecedor de alojamento) está mais atrás na cadeia e impede mais, sem que o seu pacote tenha de fazer o processamento. Pergunte ao seu fornecedor de alojamento o que está em execução no servidor.
• Um verificador deteta depois do facto. Um verificador de malware avisa-o de que algo está errado. Isso é valioso, mas não previne nada. E um verificador no mesmo servidor de um site invadido também pode ter sido alterado pelo próprio intruso.
• Não substituem as atualizações. Um plugin com uma falha conhecida continua vulnerável, mesmo com um plugin de segurança ao lado. Alguns serviços de segurança oferecem "patches virtuais" que bloqueiam ataques conhecidos até à atualização; útil como medida provisória, não como substituto.
• São eles próprios um plugin. Mais código, mais para atualizar, por vezes com uma falha própria. E dois plugins de segurança ao mesmo tempo entram frequentemente em conflito.
• Consomem capacidade de processamento, sobretudo os verificadores que são executados no próprio servidor.

Uma escolha razoável: verifique primeiro o que o seu fornecedor de alojamento já faz (firewall, verificação de malware, bloqueio de tentativas de início de sessão). Complete o que falta, normalmente a autenticação de dois fatores e a limitação de tentativas de início de sessão. Um plugin de segurança completo é sobretudo útil com um alojamento que, por si só, faz pouco.

Resumo

• O reforço de segurança limita os danos de um erro ou de uma falha; não substitui as atualizações nem as palavras-passe.
• Pastas 755, ficheiros 644, wp-config.php mais restritivo; nunca 777.
• Ative o DISALLOW_FILE_EDIT, bloqueie PHP em uploads, desative a listagem de pastas e elimine cópias de segurança, .git e debug.log da pasta web.
• Ocultar a versão é arrumar, não é segurança; os cabeçalhos de segurança ajudam o navegador a proteger os seus visitantes.
• Uma firewall no servidor impede mais do que um plugin; os plugins de segurança são um complemento, não um substituto.

Questionário

Exercício

Exercício A7.4: O que o seu site mostra a toda a gente? Indique o endereço do seu site. O programa lê a página inicial e o feed RSS (/feed/) e verifica: se não consta nenhuma versão do WordPress na etiqueta generator do HTML e do feed, se o cabeçalho X-Powered-By não mostra uma versão de PHP, e se o seu site envia X-Content-Type-Options: nosniff, uma proteção contra frames (X-Frame-Options ou frame-ancestors) e uma Referrer-Policy. A ausência de HSTS (lição 3.1) e de Permissions-Policy é aceitável (laranja).

Exercício A7.4b: Nenhum resto na pasta web. Prove que é o seu próprio site (registo TXT ou ficheiro com o código do exercício). O programa consulta depois uma pequena lista fixa: a pasta /wp-content/uploads/ (sem listagem de pastas), /.git/HEAD, /wp-content/debug.log e alguns nomes comuns de cópias de wp-config.php. É positivo se nenhum deles devolver conteúdo (404 ou 403). O programa não tenta mais nada e não altera nada.

Leitura adicional

Estes artigos descrevem os passos nos painéis da WebOké; noutros painéis funcionam de forma semelhante.

• Manual DirectAdmin 11.5: Permissões de ficheiros e pastas (chmod)
• Manual DirectAdmin 11.4: Mostrar e editar ficheiros ocultos como .htaccess
• Manual DirectAdmin 15.10: Firewall de Aplicações Web
• Manual DirectAdmin 15.11: Imunify360: analisar o seu website em busca de malware
• Bloquear ficheiros através do .htaccess, por exemplo plugin-googlemap2-proxy.php
• Segurança do PHP
• Reforçar a segurança do WordPress (developer.wordpress.org, inglês): https://developer.wordpress.org/advanced-administration/security/hardening/
• Cabeçalhos de segurança (MDN, inglês): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security