Hardening e troubleshooting em HestiaCP: guia prático de sobrevivência

Hardening e Troubleshooting em HestiaCP: Guia prático de Sobrevivência#

Este artigo consolida uma sequência real de troubleshooting e hardening em ambiente HestiaCP + Nginx + PHP-FPM + Flysystem. O foco aqui é a investigação profunda de causa-raiz, segurança defensiva de verdade e a aplicação de correções na camada correta da stack, o que sustenta a alta disponibilidade operacional.

1. Entendendo os incidentes por camadas#

Em ambientes administrados pelo painel HestiaCP, as interrupções de serviço raramente acontecem de forma isolada. A complexidade do ecossistema, combinando proxy reverso Nginx, pools PHP-FPM independentes, regras de isolamento no sistema de arquivos e certificados SSL, cria pontos comuns de falha.

Uma permissão incorreta de arquivo pode se manifestar como um erro do Flysystem na aplicação, escalando para processos PHP-FPM zumbis e gerando quedas de 504 no Nginx. Entender e atuar em cada uma dessas camadas é indispensável para manter a estabilidade do servidor.

2. "Renomear usuário" e protocolo de backups#

Não existe um recurso nativo no HestiaCP para renomear contas de usuários devido ao acoplamento estrito das estruturas do painel com caminhos físicos em /home/, identificadores de usuário e grupo (UID/GID), prefixos de nomes de banco de dados e arquivos de logs.

Para migrar a estrutura de um usuário antigo para um usuário novo, é necessário executar um workflow de migração limpo. Antes de iniciar esse processo, a execução de backups preventivos completos é obrigatória.

Scripts de backup e cópia preventiva:#

# 1. Compactação completa do diretório home do usuário antigo
tar czf /root/user-antigo-backup-$(date +%Y%m%d).tar.gz /home/antigo/

# 2. Cópia preventiva das configurações de host do Nginx
cp /etc/nginx/conf.d/*.conf /root/nginx-backup-$(date +%Y%m%d)/

# 3. Backup lógico de todas as bases de dados ativas
mysqldump -u root -p --all-databases > /root/all-databases-$(date +%Y%m%d).sql

Após os backups, crie a nova conta no painel do HestiaCP, configure os domínios e a zona DNS correspondente, execute a migração manual dos dados do projeto preservando a propriedade correta das pastas com:

rsync -av /home/antigo/web/domain.com/public_html/ /home/novo/web/domain.com/public_html/
chown -R novo:novo /home/novo/web/domain.com/public_html

Por fim, faça a importação do banco atualizando os dados de acesso e prefixos nos fontes da aplicação.

3. Configuração de open_basedir e validação#

O recurso open_basedir do PHP restringe os arquivos que podem ser acessados pelo interpretador a uma árvore de diretórios autorizada. Isso previne ataques onde scripts PHP vulneráveis tentam ler arquivos confidenciais do sistema.

Aplicação da configuração segura:#

Seja no php.ini global ou através de arquivos .user.ini específicos na raiz da aplicação, garanta a restrição:

# Configuração segura recomendada para isolamento no .user.ini
open_basedir = /home/usuario/web/domain.com/public_html:/tmp:/usr/share/php

Comandos de validação e auditoria:#

# 1. Verifica as diretivas de open_basedir vigentes na sessão CLI
php -i | grep open_basedir

# 2. Busca pelas diretivas configuradas nos pools do PHP-FPM
grep -r "open_basedir" /etc/php/*/fpm/pool.d/

Assegure-se de manter o acesso liberado para diretórios comuns de utilitários como /tmp e a biblioteca /usr/share/php se a sua aplicação necessitar destas dependências.

4. Configuração de flysystem e uploads#

A biblioteca PHP League Flysystem fornece uma camada de abstração para o sistema de arquivos. Quando configurada com o adaptador de filesystem local, ela é extremamente rigorosa com as permissões de leitura e gravação da aplicação.

Configuração de flysystem (WordPress / custom PHP):#

use League\Flysystem\Local\LocalFilesystemAdapter;
use League\Flysystem\Filesystem;

$adapter = new LocalFilesystemAdapter(
    '/home/usuario/web/domain.com/public_html/uploads',
    LOCK_EX, // Garante locks exclusivos para escrita
    0,        // Ignora links simbólicos para segurança
    []        // Mappings customizados de mime-type
);

$filesystem = new Filesystem($adapter);

Validação física e direitos de escrita:#

# 1. Verifica permissões e propriedade do diretório de uploads
ls -la /home/usuario/web/domain.com/public_html/uploads/

# 2. Exibe metadados completos de propriedade e permissões com stat
stat /home/usuario/web/domain.com/public_html/uploads/

# 3. Aplica a permissão recomendada padrão de gravação para a pasta
chmod 755 /home/usuario/web/domain.com/public_html/uploads/

5. Validação de SSL e TLS#

A integridade do protocolo HTTPS é indispensável, principalmente para o registro estável de Service Workers em PWAs. Qualquer quebra de cadeia de certificação resulta em falha silenciosa de cache no navegador cliente.

Comandos de inspeção e diagnóstico de SSL:#

# 1. Valida datas de expiração e validade do certificado de borda
echo | openssl s_client -connect domain.com:443 2>/dev/null | openssl x509 -noout -dates

# 2. Conta a cadeia de certificados apresentados para detectar cadeias incompletas
echo | openssl s_client -connect domain.com:443 -showcerts 2>/dev/null | grep -c "BEGIN CERTIFICATE"

# 3. Verifica a ocorrência de conteúdo misto (Mixed Content HTTP) na página
curl -s https://domain.com/ | grep -i "http://"

# 4. Confirma o redirect HTTP to HTTPS (deve retornar 301/302)
curl -I http://domain.com/

6. Validação de configuração do Nginx#

O Nginx atua como o proxy reverso na entrada do HestiaCP. Um erro de sintaxe em uma única diretiva de domínio de usuário pode paralisar as requisições de todo o servidor.

Runbook de verificação do Nginx:#

# 1. Testa a integridade sintática global das regras configuradas
nginx -t

# 2. Consulta o status operacional do daemon do webserver
systemctl status nginx

# 3. Exibe as configurações virtuais do domínio ativo do usuário no HestiaCP
cat /usr/local/hestia/data/users/usuario/nginx.conf

# 4. Captura as últimas ocorrências de falhas no log de erros do Nginx
tail -50 /var/log/nginx/error.log | grep -i "error"

Assegure que caminhos de controle do Nginx como /usr/local/hestia/data/users/ estejam íntegros e que o log /var/log/nginx/error.log não reporte conflitos de upstream.

7. Validação de pool PHP-FPM#

Cada usuário no HestiaCP possui um pool PHP-FPM próprio para isolamento de processos. Um travamento ou configuração errada no arquivo de pool causa falha upstream imediata (502/504 Bad Gateway).

Diagnóstico de saúde do PHP-FPM:#

# 1. Consulta o status operacional do interpretador de backend
systemctl status php8.1-fpm

# 2. Exibe as configurações do arquivo de pool do usuário selecionado
cat /etc/php/8.1/fpm/pool.d/usuario.conf

# 3. Busca por isolamento de pastas ativo no arquivo de pool
grep -i "open_basedir" /etc/php/8.1/fpm/pool.d/usuario.conf

# 4. Monitora incidentes de timeout ou crash de workers do pool
tail -50 /var/log/php8.1-fpm.log | grep -i "error"

Inspecione sempre o arquivo /var/log/php8.1-fpm.log para rastrear limites de execução excedidos.

8. Auditoria de permissões e ownership#

No ambiente Linux do HestiaCP, cada arquivo web deve pertencer ao usuário correspondente do domínio. Permissões de escrita abusivas (ex: 777) criam vetores críticos para infecções cruzadas de vírus ou invasões.

Verificação de permissões críticas:#

# 1. Lista a propriedade dos arquivos na pasta pública do domínio
ls -la /home/usuario/web/domain.com/public_html/

# 2. Confirma a propriedade do arquivo wp-config.php (deve ser 600 ou 640)
stat -c "%a %U:%G %n" /home/usuario/web/domain.com/public_html/wp-config.php

# 3. Verifica ownership da pasta de uploads
ls -la /home/usuario/web/domain.com/public_html/uploads/

Correção e hardening do sistema de arquivos:#

Execute estes comandos para padronizar a segurança do projeto:

# Padroniza permissões de escrita em pastas do projeto
find /home/usuario/web -type d -exec chmod 755 {} \;

# Padroniza leitura segura em arquivos comuns
find /home/usuario/web -type f -exec chmod 644 {} \;

# Restringe a permissão do arquivo de chaves de banco de dados
chmod 600 /home/usuario/web/domain.com/public_html/wp-config.php

9. Verificação pós-migração#

Após transferir o site e o banco, a checagem pós-migração valida se o ambiente está 100% pronto para tráfego real.

Verificação sistêmica:#

# 1. Testa a resposta do domínio no protocolo seguro
curl -I https://domain.com/

# 2. Confirma a conectividade e autenticação do banco de dados
mysql -u novo -p -e "SHOW DATABASES"

# 3. Monitora os logs das duas principais camadas por erros imediatos
tail -50 /var/log/nginx/error.log | grep -i "error"
tail -50 /var/log/php8.1-fpm.log | grep -i "error"

# 4. Confirma se o Flysystem possui escrita imediata no uploads
ls -la /home/usuario/web/domain.com/public_html/uploads/

10. Hardening do open_basedir e diretivas globais#

Para uma segurança aprimorada de nível empresarial, o isolamento com open_basedir deve ser complementado com o bloqueio de funções PHP perigosas de execução de comandos do sistema.

Hardening avançado do pool FPM:#

Insira estas diretivas no arquivo /etc/php/8.1/fpm/pool.d/usuario.conf ou equivalente:

[usuario]
open_basedir = /home/usuario/web/domain.com/public_html:/tmp:/usr/share/php
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,show_source,symlink

Garante-se assim que mesmo se um invasor explorar uma falha de injeção de código, ele não conseguirá executar comandos no terminal do Linux ou ler arquivos do sistema como /etc/passwd.

11. Logs para debug e telemetria#

Os caminhos das principais saídas de logs do HestiaCP e do sistema Linux devem ser mapeados em ferramentas de monitoramento ou visualizados em tempo real durante manutenções.

Localização dos principais logs:#

• Logs do Nginx: /var/log/nginx/error.log e /var/log/nginx/access.log
• Logs do PHP-FPM: /var/log/php8.1-fpm.log
• Logs de Ações do HestiaCP: /usr/local/hestia/log/error.log

Comandos de telemetria dinâmica:#

# 1. Acompanha os logs de erros do Nginx em tempo real
tail -f /var/log/nginx/error.log

# 2. Exibe eventos de logs do PHP-FPM na última hora
journalctl -u php8.1-fpm --since "1 hour ago"

# 3. Exibe eventos do daemon do Nginx na última hora
journalctl -u nginx --since "1 hour ago"

12. Checklist de hardening e matriz de riscos#

Checklist: hardening HestiaCP#

1. Migração de usuário#

• [ ] Backup realizado: tar czf /root/user-backup.tar.gz /home/antigo/
• [ ] Novo usuário criado no HestiaCP
• [ ] Sincronização executada com rsync
• [ ] Ownership corrigido com chown -R novo:novo
• [ ] Dump/restore do banco concluído

2. Open_basedir e permissões#

• [ ] Configuração segura definida no arquivo /etc/php/8.1/fpm/pool.d/usuario.conf
• [ ] Funções perigosas desabilitadas em disable_functions
• [ ] Permissão do arquivo wp-config.php definida para 600
• [ ] Pastas com permissão 755 e arquivos com 644

3. Nginx e SSL#

• [ ] Teste de sintaxe nginx -t executado com sucesso
• [ ] Certificado SSL completo no Nginx com cadeia inteira ativa
• [ ] Redirecionamento HTTPS (301) validado no curl

4. Validação geral e logs#

• [ ] Logs do Nginx e FPM inspecionados por erros de execução
• [ ] Teste de escrita do Flysystem validado na pasta pública

Matriz de riscos no hardening de painéis web#

Veja também

Infraestrutura HestiaCP + IonCube: Instalação por Versão PHP, Correção de Arquivo Corrompido e Timeout 504

Infraestrutura Anatomia de um encerramento de sessão: debugando LiveZilla, PHP e sockets no Linux

Infraestrutura Nginx baixando arquivos PHP no aaPanel? Como resolver "address already in use" e sockets órfãos

Este post está licenciado sob CC BY-NC.