Hardening Avançado: Isolando o wp-config.php fora da Raiz Web

🛡️ Hardening Avançado: Isolando o wp-config.php fora da Raiz Web

O arquivo wp-config.php é o "coração" da sua instalação WordPress. Ele guarda as chaves de segurança e as credenciais de acesso ao banco de dados. Manter esse arquivo dentro da pasta pública (public_html ou www) aumenta o risco: em caso de falha de configuração no servidor web, o conteúdo pode ser exibido como texto puro no navegador.

Neste guia, documentei o procedimento que executo em ambiente real para isolar esse arquivo de forma profissional, com validação e rollback.

---

1. O conceito de isolamento de configuração

A estratégia é mover o arquivo para um nível acima da raiz pública. Se a sua raiz web é /home/accountuser/public_html/, o wp-config.php pode ficar em /home/accountuser/.

Como esse nível não é servido por HTTP/HTTPS, o arquivo fica fora do alcance de requisições diretas na web.

Benefício técnico imediato

1. Redução da superfície exposta para varredura automatizada.
2. Blindagem contra leak acidental por parser/PHP handler quebrado.
3. Separação mais limpa entre código público e segredos de aplicação.

---

2. Procedimento de movimentação (método nativo do WordPress)

O WordPress já suporta esse fluxo nativamente: se não encontrar wp-config.php na raiz, ele procura na pasta pai.

Passo a passo operacional

1. Backup completo

• Backup de arquivos.
• Dump do banco.

1. Acesso ao servidor

• SSH ou FTP.

1. Identificação da raiz WordPress

• Confirme presença de wp-admin e wp-includes.

1. Movimentação do arquivo

cd /home/accountuser/
cp public_html/wp-config.php public_html/wp-config.php.bak.$(date +%F-%H%M)
mv public_html/wp-config.php ./wp-config.php

1. Validação de sintaxe

php -l /home/accountuser/wp-config.php

1. Validação funcional

• Abrir home.
• Acessar /wp-admin.
• Publicar ou atualizar um post de teste.

Na prática, quando a estrutura está padrão, não é necessário editar index.php ou bootstrap adicional.

---

3. Método para diretórios customizados (stub loader)

Se você quer guardar a configuração em um caminho específico (por exemplo, /home/accountuser/config/wp-config.php), a abordagem mais estável é usar um stub na raiz pública.

Fluxo recomendado

1. Mova o arquivo real:

mkdir -p /home/accountuser/config
mv /home/accountuser/public_html/wp-config.php /home/accountuser/config/wp-config.php

1. Crie wp-config.php mínimo em public_html:

<?php
/** Carrega as configurações de um diretório seguro */
require_once('/home/accountuser/config/wp-config.php');

Essa técnica evita mexer no index.php e reduz chance de quebra em atualização de core.

Checklist de segurança do stub

1. Caminho absoluto correto no require_once.
2. Arquivo real fora da pasta pública.
3. Teste de carga da aplicação e painel após alteração.

---

4. Camada extra: permissões de arquivo no sistema operacional

Mover arquivo não resolve sozinho se permissões estiverem frouxas.

Permissões recomendadas

Para cenário mais restritivo:

chmod 400 /home/accountuser/config/wp-config.php

Para leitura por grupo do processo web (quando necessário):

chmod 440 /home/accountuser/config/wp-config.php

Imunidade contra alteração acidental

chattr +i /home/accountuser/config/wp-config.php

Atenção operacional: para editar depois, remova temporariamente: chattr -i /home/accountuser/config/wp-config.php.

---

5. Validação técnica pós-hardening

Depois de aplicar isolamento, faço um ciclo de validação com evidência:

1. php -l no config final.
2. Resposta HTTP do site e /wp-admin.
3. Upload de mídia e atualização de plugin.
4. Verificação de erro em log (error_log, php-fpm.log, apache/nginx).

Teste rápido:

curl -I https://domain.tld/
curl -I https://domain.tld/wp-login.php

Resultado esperado: aplicação responde normal, sem leak de configuração.

---

6. Erros comuns que vejo em campo

Erro A: tela branca após mover config

Causas frequentes:

1. caminho errado no require_once;
2. permissões incompatíveis com usuário do processo;
3. typo no arquivo durante edição manual.

Ação:

1. validar php -l;
2. revisar ownership/permissão;
3. restaurar backup rapidamente.

Erro B: plugin de cache/WAF deixa de reconhecer ambiente

Causa:

plugin depende de leitura indireta de constantes e falha com stub mal montado.

Ação:

1. limpar cache;
2. revisar ordem de bootstrap;
3. validar constantes carregadas com script de teste.

---

7. Plano de rollback (sempre pronto)

Se algo sair do esperado, rollback deve ser imediato:

mv /home/accountuser/wp-config.php /home/accountuser/public_html/wp-config.php
# ou, no cenário com stub:
cp /home/accountuser/public_html/wp-config.php.bak.YYYY-MM-DD-HHMM /home/accountuser/public_html/wp-config.php

Depois:

1. validar sintaxe;
2. recarregar serviços web/PHP se necessário;
3. testar home/admin novamente.

---

🏁 Conclusão estratégica

Mover o wp-config.php para fora da raiz pública adiciona uma barreira crítica contra vazamento de credenciais e reduz risco em cenário de falha de interpretação do servidor.

É uma medida simples, mas com impacto alto quando combinada com:

1. permissões restritas (400/440);
2. controle de imutabilidade (chattr +i);
3. validação operacional e rollback planejado.

Esse tipo de disciplina é o que transforma WordPress de "site funcional" para infraestrutura robusta de produção.

Este post está licenciado sob CC BY-NC.