Proteger o wp-config.php: 10 definições a verificar

O wp-config.php guarda a palavra-passe da base de dados, as chaves que assinam cada cookie de início de sessão e os interruptores que decidem se os erros são mostrados aos visitantes. A maioria dos responsáveis por sites nunca o abriu. Este guia para proteger o wp-config.php é uma auditoria de dez pontos a esse único ficheiro. Em cada verificação encontra a linha exata, o valor para produção, a forma de confirmar e aquilo contra o que a definição não protege.

O que o wp-config.php controla e como o editar sem um ecrã branco

O ficheiro contém três tipos de coisas. Primeiro, as credenciais da base de dados. Segundo, oito chaves de segurança e salts. Terceiro, constantes que alteram o comportamento do WordPress. Quem consegue ler o ficheiro consegue entrar na sua base de dados. Quem consegue escrever nele consegue executar código em cada carregamento de página.

É também o ficheiro mais fácil de estragar. Um ponto e vírgula em falta produz um ecrã branco ou um erro fatal para todos os visitantes. Siga este procedimento sempre:

1. Descarregue para o seu computador uma cópia do ficheiro atual.
2. Edite por SFTP ou SSH, não num gestor de ficheiros no navegador nem através de um plugin.
3. Se tiver acesso à shell, execute php -l wp-config.php. Deve devolver "No syntax errors detected".
4. Recarregue o site e /wp-admin/ numa janela privada.
5. Se algo falhar, volte a carregar a sua cópia. Depois corrija a edição com calma.
6. Se funcionar, apague as cópias temporárias que tenha criado no servidor (como wp-config.php.bak). Guarde a cópia no seu computador.

A posição conta. Perto do fim do ficheiro encontra o comentário /* That's all, stop editing! Happy publishing. */, seguido de require_once ABSPATH . 'wp-settings.php';. As constantes definidas depois dessa linha chegam tarde demais para a maioria das definições. Coloque cada novo define() acima do comentário. A referência oficial é a página do wp-config.php na documentação para programadores do WordPress.

Segredos: credenciais da base de dados e chaves de segurança e salts únicos

Verificação 1: credenciais da base de dados. DB_USER deve ser um utilizador da base de dados que exista apenas para este site, com uma palavra-passe longa e aleatória. Se três sites partilham o mesmo utilizador, uma fuga num deles expõe os três. Nunca reutilize aqui a palavra-passe do painel de alojamento. Esta verificação não ajuda se o atacante já executar código no servidor, porque nesse caso consegue ler o ficheiro de qualquer forma.

Verificação 2: chaves e salts. São oito: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e as quatro constantes _SALT correspondentes. Têm de ser longas, aleatórias e únicas para este site. Se alguma ainda disser put your unique phrase here, corrija-o hoje. Pode gerar um conjunto novo em api.wordpress.org/secret-key/1.1/salt/ e colá-lo sobre o bloco antigo. Com o WP-CLI, basta um comando:

wp config shuffle-salts

Mude os salts depois de uma intrusão, quando sair um administrador ou uma agência com acesso aos ficheiros, ou se o ficheiro alguma vez tiver ficado exposto.

Depois de um comprometimento, a rotação destes segredos é apenas um passo de uma limpeza mais ampla. Veja a remoção de malware no WordPress para a ordem completa.

Depuração em produção: WP_DEBUG, WP_DEBUG_DISPLAY e WP_DEBUG_LOG

Verificação 3: WP_DEBUG. Num site em produção deve estar a false. Os erros apresentados no ecrã revelam caminhos do servidor, nomes de plugins e, por vezes, fragmentos de consultas. Um atacante pode aproveitar isso para escolher o alvo.

define( 'WP_DEBUG', false );

Pôr WP_DEBUG a false não desliga a definição display_errors do próprio PHP. Se o seu alojamento a tiver ativa, os avisos podem continuar a aparecer na página. Pergunte ao fornecedor ou verifique a configuração do PHP, se gere o seu próprio servidor.

Verificação 4: se precisar de registos, esconda-os e mude-os de sítio. Por vezes é preciso depurar em produção. Nesse caso, nunca mostre erros na página e não use a localização predefinida do registo. WP_DEBUG_LOG com o valor true escreve em wp-content/debug.log, que muitas vezes pode ser descarregado publicamente. Indique antes um caminho de ficheiro fora da raiz web:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

A diretoria tem de existir e ter permissão de escrita para o utilizador do PHP. Depois confirme que nenhum registo antigo continua público:

curl -I https://example.com/wp-content/debug.log

Deve obter 403 ou 404. Um 200 significa que qualquer pessoa pode ler o registo. Apague-o.

Os registos contêm muitas vezes endereços de email, endereços IP e dados de formulários, ou seja, dados pessoais. Desligue o registo quando terminar e apague ou rode os ficheiros de registo antigos. Os pormenores de cada constante estão na documentação de depuração do WordPress.

HTTPS e ambiente: FORCE_SSL_ADMIN e WP_ENVIRONMENT_TYPE

Verificação 5: FORCE_SSL_ADMIN. Mantém a página de início de sessão, o painel de controlo e os cookies de administração em HTTPS:

define( 'FORCE_SSL_ADMIN', true );

Abrange apenas a área de administração e os inícios de sessão. Não substitui um redirecionamento de HTTP para HTTPS em todo o site, feito no servidor, e não é HSTS.

Verificação 6: WP_ENVIRONMENT_TYPE. Esta definição diz ao WordPress e aos plugins em que tipo de site estão a correr. Os valores válidos são production, staging, development e local. O valor predefinido é production.

define( 'WP_ENVIRONMENT_TYPE', 'production' );

A definição tem efeitos reais. No núcleo, um ambiente development ativa o WP_DEBUG quando não o definiu você. Alguns plugins e alojamentos leem o valor para bloquear o envio de email ou alterar a cache em sites que não são de produção. O ponto mais importante é a identificação. Uma cópia de testes (staging) costuma conter uma cópia integral dos dados reais de clientes e encomendas. Marque-a como staging e proteja-a com autenticação HTTP ou restrição por IP. Apague-a quando o projeto terminar. Um subdomínio de staging esquecido, com a base de dados de clientes do ano passado, é uma fonte frequente de fugas.

Editor de ficheiros e modificações de ficheiros: DISALLOW_FILE_EDIT e DISALLOW_FILE_MODS

Verificação 7: Adicione esta linha a todos os sites:

define( 'DISALLOW_FILE_EDIT', true );

Remove do painel de controlo os editores de ficheiros de temas e de plugins. Assim, um início de sessão de administrador roubado não pode ser transformado em execução de código com meia dúzia de cliques. Não trava um atacante que consiga carregar um plugin.

Verificação 8: DISALLOW_FILE_MODS vai mais longe. Bloqueia também a instalação e a atualização de plugins e temas a partir do painel de controlo e desliga as atualizações automáticas em segundo plano. Ative-o só quando tiver outra via de atualização, como o WP-CLI, um pipeline de implementação ou atualizações geridas pelo alojamento. Caso contrário, acabou de congelar o site nas versões vulneráveis de hoje. Ambas as definições e o fluxo de atualização estão tratados em DISALLOW_FILE_EDIT: desativar o editor de ficheiros do WordPress.

Permissões, localização e cópias esquecidas do wp-config.php

Verificação 9: permissões. O valor certo depende do utilizador com que o PHP corre:

• 400 ou 440: use quando o proprietário do ficheiro é um utilizador diferente do PHP. O grupo tem de incluir o utilizador do PHP, que então só precisa de acesso de leitura.
• 600: use quando o PHP corre como proprietário do ficheiro, o que é comum com pools PHP-FPM por conta.

Evite 644 em alojamento partilhado, porque outras contas no mesmo servidor podem conseguir lê-lo. Nunca use 777.

ls -l wp-config.php
chmod 440 wp-config.php

Para a propriedade e as permissões no resto da instalação, veja web shells e permissões de ficheiros.

Mover o ficheiro para uma diretoria acima da raiz web é permitido. O WordPress procura-o aí automaticamente quando a pasta superior não tem uma instalação WordPress própria. O benefício é pequeno. Só conta se o PHP deixar de ser executado e o servidor servir os ficheiros .php como texto simples. Faça-o se for fácil, mas não o conte como uma correção.

Verificação 10: cópias esquecidas. Este é o risco maior e mais comum. Ficheiros como wp-config.php.bak, wp-config.php.old, wp-config.php.save, wp-config.php~ ou um ficheiro temporário de editor como .wp-config.php.swp não terminam em .php. O servidor web pode entregá-los como texto simples, com a palavra-passe da base de dados incluída. Procure-os:

find /var/www/example -name '*wp-config*' -type f

Só devem ficar o wp-config.php e o inofensivo wp-config-sample.php. Apague os restantes. Mudar-lhes o nome não resolve. Se alguma cópia esteve acessível pela web, mude também a palavra-passe da base de dados e os salts.

As 10 verificações do wp-config.php numa tabela

Um resultado limpo aqui não diz nada sobre plugins vulneráveis, palavras-passe fracas de administradores ou uma versão desatualizada do PHP. Para isso, use a lista de verificação de segurança do WordPress.

O plugin Security Audit & Compliance, da secaudit.eu, inclui uma análise de reforço e configuração e verifica segredos e ficheiros expostos, como cópias de segurança esquecidas. Tem ainda um interruptor opcional para desativar os editores de ficheiros do painel de controlo → secaudit.eu

O seu próximo passo: descarregue agora uma cópia do wp-config.php e execute o comando find para procurar cópias esquecidas. Demora dois minutos e cobre a exposição mais frequentemente ignorada.

FAQ

Mudar os salts vai estragar o meu site?

Não. Conteúdos, definições e palavras-passe mantêm-se. Todos os utilizadores com sessão iniciada ficam sem sessão e têm de voltar a entrar, por isso avise antes os seus editores e os clientes da loja.

Devo mudar o prefixo das tabelas num site existente?

Normalmente não. Um prefixo personalizado acrescenta pouca proteção real e, num site em produção, mudá-lo implica renomear tabelas e atualizar entradas nas tabelas options e usermeta. Um erro pode bloquear todos os utilizadores. Deixe como está, a menos que vá reconstruir o site de qualquer forma.

Um plugin pode gerir o wp-config.php por mim?

Alguns podem. No entanto, um plugin com permissão de escrita no wp-config.php é, em si, um risco, porque uma vulnerabilidade nele passa a ser acesso de escrita ao seu ficheiro mais sensível. Prefira edições manuais por SFTP ou SSH e guarde uma cópia da última versão que funcionava.