cPanel & WHM Arquivos de Log: A Referência Técnica Completa para Administradores de Servidor

O cPanel & WHM mantém uma arquitetura de registo abrangente e multicamadas que regista todos os eventos significativos em serviços web, entrega de correio, autenticação, bases de dados e operações do sistema. Cada ficheiro de registo tem uma localização, formato e finalidade de diagnóstico distintos — saber qual registo consultar e como analisá-lo de forma eficiente é a diferença entre uma correção de cinco minutos e uma investigação de interrupção de várias horas.

Este guia abrange todos os ficheiros de registo críticos num ambiente de produção cPanel & WHM, incluindo caminhos de ficheiros, formatos de registo, casos de uso de diagnóstico do mundo real e técnicas de linha de comandos que os administradores de sistemas experientes realmente utilizam.

Por que os Ficheiros de Registo do cPanel & WHM Merecem a Sua Atenção

Os ficheiros de registo não são apenas um registo de auditoria — são o principal instrumento de diagnóstico para qualquer pilha de alojamento baseada em Linux. Num ambiente cPanel especificamente, a superfície de registo abrange Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk e a própria camada de aplicação cPanel/WHM.

Os administradores que tratam os registos de forma reativa — verificando-os apenas após uma falha — perdem consistentemente sinais de aviso precoce: esgotamento gradual de memória, campanhas incrementais de força bruta, acumulação de consultas lentas e falhas de entrega relacionadas com certificados. A análise proativa de registos deteta estes padrões antes que se tornem incidentes.

Três objetivos operacionais fundamentais impulsionam a análise de registos em ambientes cPanel:

• Diagnóstico da causa raiz: Correlacionar marcas temporais nos registos do Apache, PHP e MySQL para identificar o ponto exato de falha numa cadeia de pedidos.
• Estabelecimento de linha de base de desempenho: Identificar consultas lentas, respostas HTTP de alta latência e processos com uso intensivo de recursos antes de saturarem a capacidade do servidor.
• Análise forense de segurança: Reconstruir cronologias de ataques a partir de registos de autenticação SSH, registos cPHulk e registos de rejeição do Exim para determinar o âmbito e as etapas de remediação.

Ficheiros de Registo do Apache

O Apache é o servidor web predefinido em ambientes cPanel, embora o LiteSpeed seja cada vez mais comum como substituto direto. Ambos escrevem registos em formatos compatíveis nos mesmos caminhos convencionais.

Registo de Erros do Apache

Localização: /usr/local/apache/logs/error_log

Este é o registo mais consultado em qualquer sessão de resolução de problemas do cPanel. Captura todos os erros que o Apache gera: erros fatais do PHP (quando o PHP é executado como módulo), falhas de sintaxe .htaccess, incompatibilidades de regras mod_rewrite, negações de permissão, falhas de handshake SSL e erros de proxy upstream.

Um detalhe crítico que muitos guias omitem: os registos de erros por domínio também existem e são frequentemente mais imediatamente úteis do que o registo de erros global. Estão localizados em:

/home/username/logs/domain.com-ssl_error_log
/home/username/logs/domain.com-error_log

Estes registos por VirtualHost isolam erros numa única conta, reduzindo drasticamente o ruído quando está a diagnosticar um site específico num servidor partilhado.

Padrão de diagnóstico comum — ciclo de reescrita .htaccess:

grep "RewriteRule" /usr/local/apache/logs/error_log | tail -50

Padrão de diagnóstico comum — erros fatais do PHP por domínio:

grep "PHP Fatal" /home/username/logs/domain.com-error_log | tail -30

Registo de Acesso do Apache

Localização: /usr/local/apache/logs/access_log

O registo de acesso global regista todos os pedidos HTTP/HTTPS no Formato de Registo Combinado por predefinição:

IP - username [timestamp] "METHOD /path HTTP/version" status_code bytes_sent "referer" "user_agent"

Os registos de acesso por domínio são armazenados em /home/username/logs/domain.com-access_log e são a fonte correta para análise de tráfego em contas individuais.

Casos de uso práticos:

• Identificar uma campanha DDoS ou de scraping por frequência de IP:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

• Encontrar todos os erros da série 500 na última hora (requer que as marcas temporais do registo sejam recentes):

grep " 5[0-9][0-9] " /usr/local/apache/logs/access_log | tail -200

• Detetar scanners de vulnerabilidades pela string do agente de utilizador:

grep -i "sqlmap|nikto|masscan|nmap" /usr/local/apache/logs/access_log

Caso especial: Em servidores com piped logging ativado no WHM, o registo de acesso pode estar vazio ou mínimo porque os registos estão a ser encaminhados diretamente para um daemon de processamento de registos. Verifique WHM > Configuração do Apache > Configuração Global para a diretiva CustomLog se encontrar um registo de acesso inesperadamente vazio.

Registo SSL/TLS do Apache

Localização: /usr/local/apache/logs/ssl_error_log

Este registo captura falhas de negociação TLS, erros de validação de certificados e incompatibilidades de conjuntos de cifras. É essencial ao depurar problemas de conectividade HTTPS que não aparecem no registo de erros principal. Consulte aqui primeiro quando os utilizadores reportam avisos SSL no navegador ou quando a renovação automática de certificados via AutoSSL falha silenciosamente.

Registos da Aplicação cPanel e WHM

Registo de Acesso do cPanel

Localização: /usr/local/cpanel/logs/access_log

Regista todos os pedidos HTTP feitos à interface cPanel (porta 2082/2083). Cada entrada inclui o nome de utilizador autenticado, a ação realizada e o IP de origem. Este registo é a principal fonte para auditar o que um utilizador específico fez dentro da sua conta cPanel.

Encontrar todas as ações realizadas por um utilizador específico:

grep "username" /usr/local/cpanel/logs/access_log | grep -v "GET /favicon"

Registo de Erros do cPanel

Localização: /usr/local/cpanel/logs/error_log

Captura erros internos da camada de aplicação cPanel — chamadas de API falhadas, plugins cPanel com problemas, erros de script Perl no backend do cPanel e falhas de renderização de modelos. Se a interface cPanel estiver a gerar erros 500 ou funcionalidades específicas estiverem com problemas, este é o primeiro registo a verificar.

Registo de Login do WHM

Localização: /usr/local/cpanel/logs/login_log

Regista todos os eventos de autenticação WHM — logins bem-sucedidos, tentativas falhadas, desafios de autenticação de dois fatores e utilização de tokens de API. Este registo é crítico para detetar acesso administrativo não autorizado.

Encontrar todas as tentativas de login WHM falhadas:

grep "FAILED" /usr/local/cpanel/logs/login_log | awk '{print $NF}' | sort | uniq -c | sort -rn

Registo de Proteção contra Força Bruta do cPHulk

Localização: /usr/local/cpanel/logs/cphulkd.log

Este é um registo que a maioria dos guias ignora completamente, mas é um dos mais importantes operacionalmente. O cPHulk é o daemon de proteção contra força bruta integrado do cPanel. Monitoriza tentativas de login SSH, FTP, cPanel e WHM e bloqueia automaticamente IPs que excedam os limites de threshold.

Quando um administrador legítimo fica bloqueado do WHM ou SSH, a resposta está quase sempre neste registo. Também pode consultar diretamente a base de dados do cPHulk:

mysql -u root cphulkd -e "SELECT ip, user, type, timestamp FROM brutes ORDER BY timestamp DESC LIMIT 20;"

Para desbloquear um IP específico a partir da linha de comandos:

/usr/local/cpanel/bin/cphulk_pam_ctl --unblock=192.168.1.1

Registo de Atualização e Instalação do cPanel

Localização: /var/cpanel/updatelogs/

Cada execução de atualização do cPanel gera um ficheiro de registo com marca temporal neste diretório. Quando uma atualização do cPanel interrompe um serviço ou uma funcionalidade desaparece após uma atualização, este diretório contém a saída completa do processo de atualização, incluindo quaisquer erros que ocorreram durante a instalação de pacotes ou migração de configuração.

ls -lt /var/cpanel/updatelogs/ | head -5

Ficheiros de Registo de Email

O email é consistentemente o subsistema mais complexo de resolver problemas no cPanel. O Exim, o MTA predefinido do cPanel, gera três fluxos de registo separados, cada um servindo uma finalidade de diagnóstico distinta.

Registo Principal do Exim

Localização: /var/log/exim_mainlog

Este é o registo principal de transações de email. Cada mensagem que o Exim processa — de entrada ou saída — gera entradas aqui cobrindo aceitação, decisões de encaminhamento, tentativas de entrega e disposição final (entregue, adiada ou devolvida).

Anatomia de uma entrada de registo:

2024-01-15 14:23:01 1rPqXY-0003aB-Kc <= sender@example.com H=mail.example.com [203.0.113.10] P=esmtps S=4821 id=<abc123@example.com>
2024-01-15 14:23:02 1rPqXY-0003aB-Kc => recipient@domain.com R=virtual_user_delivery T=virtual_userdelivery_pipe
2024-01-15 14:23:02 1rPqXY-0003aB-Kc Completed

O ID da mensagem (1rPqXY-0003aB-Kc) é a chave para rastrear uma única mensagem em todo o registo:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog

Rastrear todo o correio de saída de uma conta específica (crítico para investigação de spam):

grep "U=username" /var/log/exim_mainlog | grep "<=" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Caso especial do mundo real: Quando uma instalação WordPress comprometida está a enviar spam, o registo principal do Exim mostrará o utilizador remetente como nobody (o utilizador do processo Apache) em vez de um nome de utilizador de conta cPanel. Filtre especificamente para isto:

grep "U=nobody" /var/log/exim_mainlog | grep "<=" | tail -50

Registo de Rejeição do Exim

Localização: /var/log/exim_rejectlog

Regista todas as mensagens que o Exim recusou aceitar na fase de ligação SMTP — antes mesmo de serem colocadas em fila. As rejeições ocorrem devido a hits em listas negras RBL, falhas SPF/DKIM/DMARC, strings HELO inválidas, negação de relay ou limitação de taxa.

Este registo é essencial para dois cenários: diagnosticar por que o correio de entrada legítimo está a ser rejeitado e auditar a eficácia das suas regras de filtragem de spam.

Encontrar os motivos de rejeição mais comuns:

grep "rejected" /var/log/exim_rejectlog | grep -oP "(?<=: ).*" | sort | uniq -c | sort -rn | head -10

Registo de Pânico do Exim

Localização: /var/log/exim_paniclog

O registo de pânico captura erros fatais do Exim — falhas de análise do ficheiro de configuração, incapacidade de vincular à porta 25, falhas de ligação à base de dados e erros da biblioteca TLS. Se este ficheiro não estiver vazio, o Exim sofreu uma falha crítica. Em muitos casos, um registo de pânico não vazio significa que a fila de correio parou de processar completamente.

# Check if the panic log has content — a non-zero exit means there are critical errors
[ -s /var/log/exim_paniclog ] && echo "CRITICAL: Exim panic log has entries" && tail -20 /var/log/exim_paniclog

Registo do Dovecot

Localização: /var/log/dovecot.log (e /var/log/dovecot-info.log para eventos informativos)

O Dovecot gere ligações IMAP e POP3 em ambientes cPanel. Falhas de autenticação, limites de ligação, problemas de bloqueio de caixa de correio e eventos de aplicação de quotas aparecem todos aqui. Quando os utilizadores não conseguem ligar ao seu cliente de email, o registo do Dovecot é o lugar correto para consultar — não o Exim.

grep "auth failed" /var/log/dovecot.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Ficheiros de Registo de Base de Dados

Registo de Erros MySQL/MariaDB

Localização: /var/lib/mysql/$(hostname).err

Este registo regista eventos de arranque e encerramento do MySQL/MariaDB, operações de recuperação InnoDB, erros de replicação, avisos de corrupção de tabelas e qualquer consulta que cause um erro ao nível do servidor. É a fonte definitiva para diagnosticar falhas de base de dados e reinícios inesperados.

Obter o caminho real dinamicamente:

mysql -u root -e "SHOW VARIABLES LIKE 'log_error';"

Verificar eventos de corrupção InnoDB ou recuperação de falhas:

grep -i "crash|corrupt|recovery|innodb" /var/lib/mysql/$(hostname).err | tail -30

Registo de Consultas Lentas do MySQL

Localização: /var/lib/mysql/slowquery.log (quando ativado)

O registo de consultas lentas está desativado por predefinição na maioria das instalações cPanel. Ativá-lo é uma das ações de ajuste de desempenho de maior valor que pode realizar num servidor com uso intensivo de base de dados.

Ativar o registo de consultas lentas em tempo de execução (sem necessidade de reinício):

mysql -u root -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/lib/mysql/slowquery.log';"

Uma vez ativado, use mysqldumpslow para agregar e classificar os piores infratores:

mysqldumpslow -s t -t 10 /var/lib/mysql/slowquery.log

Isto produz as 10 principais consultas por tempo total de execução — o ponto de partida mais acionável para otimização de consultas.

Nuance crítica: Um long_query_time de 1 segundo é um threshold inicial razoável para a maioria das aplicações, mas sites de alto tráfego devem considerar 0,5 segundos ou mesmo 0,25 segundos para capturar consultas que são individualmente rápidas mas cumulativamente dispendiosas sob carga.

Registo de Consultas Gerais do MySQL

Localização: Configurável, tipicamente /var/lib/mysql/general.log

O registo de consultas gerais regista cada instrução SQL enviada ao servidor. Não ative isto em produção sem uma razão de diagnóstico específica e com limite de tempo. Num servidor ocupado, este registo pode crescer a gigabytes por hora e causará por si só degradação de desempenho. Ative-o brevemente, reproduza o problema e desative-o imediatamente.

mysql -u root -e "SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/lib/mysql/general.log';"
# ... reproduce the issue ...
mysql -u root -e "SET GLOBAL general_log = 'OFF';"

Ficheiros de Registo do Sistema

Registo de Mensagens do Sistema

Localização: /var/log/messages

O registo de mensagens do kernel e daemon do sistema. Erros de hardware (falhas de I/O de disco, erros ECC de memória), eventos do eliminador OOM (Out of Memory), alterações de estado da interface de rede e eventos de carregamento de módulos do kernel aparecem todos aqui. Este é o primeiro registo a verificar quando um servidor fica sem resposta ou reinicia inesperadamente.

Verificar eventos do eliminador OOM (um servidor a eliminar silenciosamente processos devido a esgotamento de memória):

grep -i "oom|killed process|out of memory" /var/log/messages | tail -20

Verificar erros de I/O de disco que possam indicar falha de unidade:

grep -i "I/O error|blk_update_request|ata.*error" /var/log/messages | tail -20

Registo de Autenticação Segura

Localização: /var/log/secure

Regista todos os eventos de autenticação baseados em PAM: logins SSH (bem-sucedidos e falhados), execução de comandos sudo, tentativas su e autenticação iniciada por cron. Este é o registo principal para análise forense de segurança SSH.

Identificar os principais IPs atacantes por contagem de logins SSH falhados:

grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

Auditar todos os comandos sudo executados no servidor:

grep "sudo:" /var/log/secure | grep "COMMAND" | tail -50

Caso especial do mundo real: Em servidores com UseDNS yes em sshd_config, as entradas de login falhado podem mostrar nomes de host em vez de endereços IP, o que quebra o padrão awk de extração de IP acima. Verifique a sua configuração sshd_config e ajuste o índice de campo em conformidade.

Buffer de Anel do Kernel

Localização: Apenas em tempo de execução — acedido via dmesg

O buffer de anel do kernel não é um ficheiro persistente, mas é essencial para diagnosticar eventos ao nível de hardware que ocorrem durante ou pouco após o arranque, antes do syslog inicializar. Em sistemas baseados em systemd (CentOS 7+, CloudLinux 7+), os registos persistentes do kernel estão disponíveis via:

journalctl -k --since "1 hour ago"

Ficheiros de Registo FTP

Registo do ProFTPd

Localização: /var/log/proftpd/proftpd.log

O ProFTPd é o daemon FTP predefinido em ambientes cPanel. Este registo regista todos os eventos de sessão FTP: tentativas de autenticação, travessia de diretórios, uploads de ficheiros, downloads e desconexões.

Encontrar todas as tentativas de login FTP falhadas:

grep "USER|PASS" /var/log/proftpd/proftpd.log | grep -i "failed|incorrect" | tail -30

Identificar uploads de ficheiros grandes (potencial preparação de malware):

grep "STOR" /var/log/proftpd/proftpd.log | awk '{print $NF, $0}' | sort -rn | head -20

Registo do Pure-FTPd

Localização: /var/log/pureftpd.log

Os registos do Pure-FTPd são escritos no syslog por predefinição em algumas configurações, o que significa que as entradas podem aparecer em /var/log/messages em vez de um ficheiro dedicado. Verifique o destino de registo ativo:

grep "VerboseLog|AltLog" /etc/pure-ftpd.conf

Registos PHP e ao Nível de Aplicação

Registo de Erros PHP

Os erros PHP em ambientes cPanel podem ser registados em múltiplas localizações dependendo do handler PHP em uso:

O caminho do registo do pool PHP-FPM inclui o número da versão PHP. Para PHP 8.2 gerido pelo EasyApache 4:

tail -f /opt/cpanel/ea-php82/root/usr/var/log/php-fpm/error.log

O registo de erros PHP por conta pode ser ativado adicionando o seguinte ao php.ini ou .htaccess da conta:

log_errors = On
error_log = /home/username/logs/php_errors.log

Registos de Serviço e Segurança Específicos do cPanel

Registo do Gestor de Serviços do cPanel

Localização: /usr/local/cpanel/logs/safeapacherestart_log

Regista todos os eventos de reinício do Apache desencadeados pelo gestor de serviços do cPanel, incluindo o motivo do reinício e se foi bem-sucedido. Útil para correlacionar o tempo de inatividade do Apache com alterações de configuração.

Registo de Cópia de Segurança do cPanel

Localização: /usr/local/cpanel/logs/cpbackup/

Cada execução de cópia de segurança gera um ficheiro de registo por conta neste diretório. Quando uma cópia de segurança falha silenciosamente, este diretório contém o erro específico — seja um problema de espaço em disco, uma falha de dump de base de dados ou um problema de permissões.

ls -lt /usr/local/cpanel/logs/cpbackup/ | head -10
grep -i "error|fail" /usr/local/cpanel/logs/cpbackup/username.log

Registo AutoSSL do cPanel

Localização: /var/cpanel/logs/autossl/

O AutoSSL é o sistema automatizado de provisionamento de certificados Let’s Encrypt / Sectigo do cPanel. Quando a renovação de certificados SSL falha, o motivo detalhado — falha DCV, limitação de taxa, incompatibilidade de validação de domínio — é registado aqui. Este registo é crítico para diagnosticar problemas de expiração de certificados HTTPS antes que causem avisos no navegador.

ls -lt /var/cpanel/logs/autossl/ | head -5
tail -100 /var/cpanel/logs/autossl/$(ls -t /var/cpanel/logs/autossl/ | head -1)

Se gerir certificados SSL em múltiplos domínios ou precisar de certificados além do que o AutoSSL fornece, os Certificados SSL de um fornecedor dedicado oferecem opções de validação estendida e wildcard que o Let’s Encrypt não oferece.

Referência de Comparação de Ficheiros de Registo

Técnicas de Análise de Registos na Linha de Comandos

Comandos Essenciais para Análise em Tempo Real e Histórica

Seguir um registo em tempo real (o fluxo de trabalho mais comum do administrador de sistemas):

tail -f /var/log/exim_mainlog

Seguir múltiplos registos simultaneamente usando multitail (instalar via yum install multitail):

multitail /usr/local/apache/logs/error_log /var/log/exim_mainlog

Extrair e contar valores únicos de um campo específico:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

Pesquisar em arquivos de registo rotacionados comprimidos:

zgrep "keyword" /var/log/exim_mainlog.*.gz

Filtrar entradas de registo dentro de uma janela de tempo específica:

awk '/15/Jan/2024:14:00/,/15/Jan/2024:15:00/' /usr/local/apache/logs/access_log

Contar a distribuição de códigos de estado HTTP:

awk '{print $9}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn

Rotação de Registos no cPanel

O cPanel usa logrotate para gerir os tamanhos dos ficheiros de registo. A configuração de rotação para registos geridos pelo cPanel está em /etc/logrotate.d/. Os registos do Apache são rotacionados pelo próprio mecanismo splitlogs do cPanel, que também divide o registo de acesso global em ficheiros por domínio.

Verificar a configuração atual do logrotate para um serviço específico:

cat /etc/logrotate.d/syslog

Acionar manualmente a rotação de registos para teste:

logrotate -f /etc/logrotate.d/syslog

Armadilha crítica: Se a rotação de registos estiver mal configurada ou o espaço em disco estiver esgotado, os ficheiros de registo podem crescer até preencher toda a partição, causando a falha simultânea de todos os serviços. Monitorize o uso de disco na partição que contém /var/log e /usr/local/apache/logs como prática operacional padrão.

Gestão Centralizada de Registos e Alertas

Para ambientes de produção — particularmente num Alojamento VPS ou Servidor Dedicado — depender da inspeção manual de registos é insuficiente à escala. Implemente uma das seguintes abordagens:

Agregação de registos com encaminhamento rsyslog: Configure /etc/rsyslog.conf para encaminhar registos para um servidor syslog centralizado ou uma plataforma SIEM. Isto preserva os registos mesmo que o próprio servidor seja comprometido.

ELK Stack (Elasticsearch, Logstash, Kibana): Ingira registos cPanel via agentes Filebeat, analise-os com pipelines Logstash e visualize padrões no Kibana. Esta abordagem permite pesquisa de texto completo em meses de histórico de registos em segundos.

Integração com Fail2ban: O Fail2ban lê /var/log/secure e /var/log/exim_mainlog e cria automaticamente regras iptables para bloquear IPs atacantes. Opera independentemente do cPHulk e fornece uma camada de defesa adicional.

GoAccess para análise de registos Apache: O GoAccess é um analisador de registos em tempo real baseado em terminal que produz relatórios HTML a partir de registos de acesso Apache sem necessitar de uma implementação ELK completa:

goaccess /usr/local/apache/logs/access_log --log-format=COMBINED -o /var/www/html/report.html

Os administradores que gerem múltiplas contas cPanel ou configurações de revendedor num VPS com cPanel beneficiam significativamente da visibilidade centralizada de registos, uma vez que os registos de contas individuais estão de outra forma isolados sob cada diretório home.

Correlação de Registos de Infraestrutura de Email

Uma das técnicas de diagnóstico mais subestimadas em ambientes cPanel é a referência cruzada de registos Exim com registos Dovecot e o registo de autenticação do sistema para rastrear o ciclo de vida completo de um incidente de segurança de email.

Cenário: Um utilizador reporta que a sua conta está a enviar spam que não escreveu.

Passo 1 — Identificar os IDs de mensagem Exim associados à conta:

grep "U=username|from=<.*@userdomain.com>" /var/log/exim_mainlog | grep "<=" | head -20

Passo 2 — Verificar se o envio teve origem numa aplicação web (PHP mail()) ou SMTP autenticado:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog | grep -E "P=esmtpa|P=local"

P=esmtpa indica submissão SMTP autenticada. P=local ou P=pipe indica um script local (provavelmente uma aplicação web comprometida).

Passo 3 — Se P=esmtpa, encontrar o IP de origem no registo de autenticação Dovecot ou Exim:

grep "username" /var/log/dovecot.log | grep "Login" | tail -20

Passo 4 — Fazer referência cruzada desse IP com /var/log/secure para atividade SSH e com o registo de acesso cPanel para logins no painel de controlo.

Esta técnica de correlação em quatro passos responde definitivamente se o comprometimento foi roubo de credenciais, uma aplicação web vulnerável ou uma conta SMTP com força bruta — e essa distinção determina inteiramente o caminho de remediação.

Para organizações que gerem a sua própria infraestrutura de correio, um ambiente de Alojamento de Email devidamente configurado com monitorização dedicada de registos fornece o isolamento necessário para evitar danos à reputação de correio entre contas.

Considerações sobre Registos Relacionados com Domínio e DNS

As falhas de resolução DNS manifestam-se frequentemente como erros nos registos de aplicação em vez de num registo DNS dedicado. O Named (BIND), que o cPanel usa para DNS, regista em /var/log/messages por predefinição.

Verificar erros BIND:

grep "named" /var/log/messages | grep -i "error|failed|refused" | tail -20

Quando problemas de propagação DNS afetam domínios recentemente registados ou transferidos, correlacionar o registo BIND com a configuração de domínio cPanel ajuda a isolar se o problema é um erro no ficheiro de zona ou um atraso de propagação ao nível do registador. Se estiver a gerir o registo de domínio e DNS através da mesma plataforma, o Registo de Domínios com gestão DNS integrada simplifica esta cadeia de diagnóstico.

Matriz de Decisão Prática: Qual Registo Verificar Primeiro

Principais Conclusões Técnicas

• Verifique sempre os registos por domínio primeiro (/home/username/logs/) antes dos registos globais do Apache — contêm os mesmos dados com dramaticamente menos ruído.
• Um /var/log/exim_paniclog não vazio é um incidente P1 — o Exim pode ter parado de processar a fila de correio completamente.
• O registo cPHulk em /usr/local/cpanel/logs/cphulkd.log é a primeira paragem correta para qualquer cenário de bloqueio, não /var/log/secure.
• Ative o registo de consultas lentas MySQL (long_query_time = 1) em qualquer servidor de base de dados de produção — a inteligência de desempenho que fornece vale a sobrecarga mínima.
• Faça referência cruzada do campo P= do Exim com os registos de autenticação Dovecot para determinar definitivamente se um incidente de spam teve origem em roubo de credenciais ou numa aplicação web comprometida.
• A má configuração da rotação de registos é um modo de falha silencioso — uma partição /var/log cheia irá colapsar todos os serviços simultaneamente sem aviso.
• zgrep funciona em arquivos .gz rotacionados — a análise histórica de registos não requer descompressão manual de ficheiros.
• O encaminhamento centralizado de registos via rsyslog é a postura de segurança mínima viável para qualquer servidor que lide com dados sensíveis — os registos locais podem ser eliminados por um atacante que obtenha acesso root.

Perguntas Frequentes

Onde estão localizados os registos de erros do cPanel?

O registo de erros principal da aplicação cPanel está em /usr/local/cpanel/logs/error_log. Os erros do servidor web Apache estão em /usr/local/apache/logs/error_log, e os erros PHP por conta estão em /home/username/logs/domain.com-error_log. Cada serviço mantém o seu próprio ficheiro de registo num caminho distinto.

Como rastreio uma mensagem de email específica através dos registos Exim?

Cada mensagem que o Exim processa recebe um ID de mensagem único visível em /var/log/exim_mainlog. Execute grep "MESSAGE_ID" /var/log/exim_mainlog para recuperar todas as entradas de registo associadas a essa mensagem, desde a aceitação até à entrega final ou devolução.

Por que o meu registo de pânico Exim não está vazio e o que devo fazer?

Um /var/log/exim_paniclog não vazio indica que o Exim encontrou um erro fatal — tipicamente uma falha de análise de configuração, problema de biblioteca TLS ou incapacidade de vincular à porta 25. Leia as entradas do registo de pânico, depois verifique a sintaxe de configuração do Exim com exim -bV e verifique se a porta 25 não está bloqueada por outro processo usando ss -tlnp | grep :25.

Como encontro qual script PHP está a enviar spam através do Apache?

Filtre o registo principal do Exim para mensagens enviadas pelo utilizador Apache: grep "U=nobody" /var/log/exim_mainlog. Depois faça referência cruzada das marcas temporais com entradas do registo de acesso Apache para identificar o URL que acionou a função de correio. O cabeçalho X-PHP-Originating-Script (se ativado em php.ini) também identificará o ficheiro de script exato.

Qual é a forma mais rápida de verificar se um servidor está sob um ataque de força bruta SSH?

Execute grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10 para ver os principais endereços IP atacantes por contagem de tentativas. Depois verifique se o cPHulk já os bloqueou verificando /usr/local/cpanel/logs/cphulkd.log ou consultando diretamente a base de dados cPHulk.