cPanel & WHM Archivos de Registro: La Referencia Técnica Completa para Administradores de Servidores

cPanel & WHM mantiene una arquitectura de registro completa y multicapa que registra cada evento significativo en servicios web, entrega de correo, autenticación, bases de datos y operaciones del sistema. Cada archivo de registro tiene una ubicación, formato y propósito de diagnóstico distintos: saber qué registro consultar y cómo analizarlo eficientemente es la diferencia entre una solución de cinco minutos y una investigación de interrupción de varias horas.

Esta guía cubre todos los archivos de registro críticos en un entorno de producción de cPanel & WHM, incluyendo rutas de archivos, formatos de registro, casos de uso de diagnóstico del mundo real y técnicas de línea de comandos que los administradores de sistemas experimentados realmente utilizan.

Por qué los archivos de registro de cPanel & WHM merecen su atención

Los archivos de registro no son solo una pista de auditoría: son el instrumento de diagnóstico principal para cualquier stack de alojamiento basado en Linux. En un entorno cPanel específicamente, la superficie de registro abarca Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk y la propia capa de aplicación de cPanel/WHM.

Los administradores que tratan los registros de forma reactiva, consultándolos solo después de un fallo, pierden consistentemente las señales de advertencia tempranas: agotamiento gradual de memoria, campañas de fuerza bruta incrementales, acumulación de consultas lentas y fallos de entrega relacionados con certificados. El análisis proactivo de registros detecta estos patrones antes de que se conviertan en incidentes.

Tres objetivos operativos principales impulsan el análisis de registros en entornos cPanel:

• Diagnóstico de causa raíz: Correlacionar marcas de tiempo en los registros de Apache, PHP y MySQL para identificar el punto exacto de fallo en una cadena de solicitudes.
• Establecimiento de línea base de rendimiento: Identificar consultas lentas, respuestas HTTP de alta latencia y procesos con alto consumo de recursos antes de que saturen la capacidad del servidor.
• Análisis forense de seguridad: Reconstruir cronologías de ataques a partir de registros de autenticación SSH, registros de cPHulk y registros de rechazo de Exim para determinar el alcance y los pasos de remediación.

Archivos de registro de Apache

Apache es el servidor web predeterminado en entornos cPanel, aunque LiteSpeed es cada vez más común como reemplazo directo. Ambos escriben registros en formatos compatibles en las mismas rutas convencionales.

Registro de errores de Apache

Ubicación: /usr/local/apache/logs/error_log

Este es el registro más consultado en cualquier sesión de resolución de problemas de cPanel. Captura todos los errores que genera Apache: errores fatales de PHP (cuando PHP se ejecuta como módulo), fallos de sintaxis de .htaccess, discrepancias de reglas de mod_rewrite, denegaciones de permisos, fallos de negociación SSL y errores de proxy upstream.

Un detalle crítico que muchas guías omiten: también existen registros de errores por dominio y a menudo son más inmediatamente útiles que el registro de errores global. Se encuentran en:

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

Estos registros por VirtualHost aíslan los errores a una sola cuenta, reduciendo drásticamente el ruido cuando se diagnostica un sitio específico en un servidor compartido.

Patrón de diagnóstico común — bucle de reescritura de .htaccess:

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

Patrón de diagnóstico común — errores fatales de PHP por dominio:

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

Registro de acceso de Apache

Ubicación: /usr/local/apache/logs/access_log

El registro de acceso global registra cada solicitud HTTP/HTTPS en formato Combined Log Format de forma predeterminada:

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

Los registros de acceso por dominio se almacenan en /home/username/logs/domain.com-access_log y son la fuente correcta para el análisis de tráfico en cuentas individuales.

Casos de uso prácticos:

• Identificar una campaña DDoS o de scraping por frecuencia de IP:

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

• Encontrar todos los errores de la serie 500 en la última hora (requiere que las marcas de tiempo del registro sean recientes):

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

• Detectar escáneres de vulnerabilidades por cadena de user-agent:

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

Caso especial: En servidores con piped logging habilitado en WHM, el registro de acceso puede estar vacío o ser mínimo porque los registros se están canalizando directamente a un daemon de procesamiento de registros. Verifique WHM > Apache Configuration > Global Configuration para la directiva CustomLog si encuentra un registro de acceso inesperadamente vacío.

Registro SSL/TLS de Apache

Ubicación: /usr/local/apache/logs/ssl_error_log

Este registro captura fallos de negociación TLS, errores de validación de certificados y discrepancias de conjuntos de cifrado. Es esencial al depurar problemas de conectividad HTTPS que no aparecen en el registro de errores principal. Consulte aquí primero cuando los usuarios reporten advertencias SSL del navegador o cuando la renovación automatizada de certificados mediante AutoSSL falle silenciosamente.

Registros de la aplicación cPanel y WHM

Registro de acceso de cPanel

Ubicación: /usr/local/cpanel/logs/access_log

Registra cada solicitud HTTP realizada a la interfaz de cPanel (puerto 2082/2083). Cada entrada incluye el nombre de usuario autenticado, la acción realizada y la IP de origen. Este registro es la fuente principal para auditar lo que un usuario específico hizo dentro de su cuenta de cPanel.

Encontrar todas las acciones realizadas por un usuario específico:

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

Registro de errores de cPanel

Ubicación: /usr/local/cpanel/logs/error_log

Captura errores internos de la capa de aplicación de cPanel: llamadas API fallidas, plugins de cPanel rotos, errores de scripts Perl en el backend de cPanel y fallos de renderizado de plantillas. Si la interfaz de cPanel está generando errores 500 o funciones específicas están rotas, este es el primer registro a verificar.

Registro de inicio de sesión de WHM

Ubicación: /usr/local/cpanel/logs/login_log

Registra todos los eventos de autenticación de WHM: inicios de sesión exitosos, intentos fallidos, desafíos de autenticación de dos factores y uso de tokens API. Este registro es crítico para detectar acceso administrativo no autorizado.

Encontrar todos los intentos fallidos de inicio de sesión en WHM:

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

Registro de protección contra fuerza bruta de cPHulk

Ubicación: /usr/local/cpanel/logs/cphulkd.log

Este es un registro que la mayoría de las guías omiten por completo, aunque es uno de los más importantes operativamente. cPHulk es el daemon de protección contra fuerza bruta integrado de cPanel. Monitorea los intentos de inicio de sesión en SSH, FTP, cPanel y WHM, y bloquea automáticamente las IPs que superan los límites de umbral.

Cuando un administrador legítimo queda bloqueado de WHM o SSH, la respuesta casi siempre está en este registro. También puede consultar la base de datos de cPHulk directamente:

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

Para desbloquear una IP específica desde la línea de comandos:

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

Registro de actualización e instalación de cPanel

Ubicación: /var/cpanel/updatelogs/

Cada ejecución de actualización de cPanel genera un archivo de registro con marca de tiempo en este directorio. Cuando una actualización de cPanel rompe un servicio o una función desaparece después de una actualización, este directorio contiene la salida completa del proceso de actualización, incluyendo cualquier error que ocurrió durante la instalación de paquetes o la migración de configuración.

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

Archivos de registro de correo electrónico

El correo electrónico es consistentemente el subsistema más complejo de solucionar en cPanel. Exim, el MTA predeterminado de cPanel, genera tres flujos de registro separados, cada uno con un propósito de diagnóstico distinto.

Registro principal de Exim

Ubicación: /var/log/exim_mainlog

Este es el registro principal de transacciones de correo electrónico. Cada mensaje que Exim procesa, entrante o saliente, genera entradas aquí que cubren la aceptación, las decisiones de enrutamiento, los intentos de entrega y la disposición final (entregado, diferido o rebotado).

Anatomía de una entrada de registro:

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

El ID de mensaje (1rPqXY-0003aB-Kc) es la clave para rastrear un único mensaje a través de todo el registro:

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

Rastrear todo el correo saliente de una cuenta específica (crítico para la investigación de spam):

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

Caso especial del mundo real: Cuando una instalación de WordPress comprometida está enviando spam, el registro principal de Exim mostrará al usuario remitente como nobody (el usuario del proceso Apache) en lugar de un nombre de usuario de cuenta cPanel. Filtre específicamente por esto:

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

Registro de rechazo de Exim

Ubicación: /var/log/exim_rejectlog

Registra todos los mensajes que Exim se negó a aceptar en la etapa de conexión SMTP, antes de que fueran encolados. Los rechazos ocurren debido a coincidencias en listas negras RBL, fallos de SPF/DKIM/DMARC, cadenas HELO no válidas, denegación de retransmisión o limitación de velocidad.

Este registro es esencial para dos escenarios: diagnosticar por qué el correo entrante legítimo está siendo rechazado y auditar la efectividad de sus reglas de filtrado de spam.

Encontrar las razones de rechazo más comunes:

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

Registro de pánico de Exim

Ubicación: /var/log/exim_paniclog

El registro de pánico captura errores fatales de Exim: fallos de análisis de archivos de configuración, incapacidad para vincularse al puerto 25, fallos de conexión a la base de datos y errores de la biblioteca TLS. Si este archivo no está vacío, Exim ha experimentado un fallo crítico. En muchos casos, un registro de pánico no vacío significa que la cola de correo ha dejado de procesarse por completo.

# 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

Registro de Dovecot

Ubicación: /var/log/dovecot.log (y /var/log/dovecot-info.log para eventos informativos)

Dovecot gestiona las conexiones IMAP y POP3 en entornos cPanel. Los fallos de autenticación, los límites de conexión, los problemas de bloqueo de buzones y los eventos de aplicación de cuotas aparecen aquí. Cuando los usuarios no pueden conectarse a su cliente de correo electrónico, el registro de Dovecot es el lugar correcto donde buscar, no Exim.

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

Archivos de registro de bases de datos

Registro de errores de MySQL/MariaDB

Ubicación: /var/lib/mysql/$(hostname).err

Este registro registra los eventos de inicio y apagado de MySQL/MariaDB, las operaciones de recuperación de InnoDB, los errores de replicación, las advertencias de corrupción de tablas y cualquier consulta que cause un error a nivel de servidor. Es la fuente definitiva para diagnosticar fallos de bases de datos y reinicios inesperados.

Obtener la ruta real de forma dinámica:

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

Verificar eventos de corrupción de InnoDB o recuperación tras fallos:

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

Registro de consultas lentas de MySQL

Ubicación: /var/lib/mysql/slowquery.log (cuando está habilitado)

El registro de consultas lentas está deshabilitado de forma predeterminada en la mayoría de las instalaciones de cPanel. Habilitarlo es una de las acciones de ajuste de rendimiento de mayor valor que puede realizar en un servidor con uso intensivo de bases de datos.

Habilitar el registro de consultas lentas en tiempo de ejecución (sin necesidad de reinicio):

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';"

Una vez habilitado, use mysqldumpslow para agregar y clasificar los peores infractores:

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

Esto genera las 10 consultas principales por tiempo total de ejecución, el punto de partida más útil para la optimización de consultas.

Matiz crítico: Un long_query_time de 1 segundo es un umbral inicial razonable para la mayoría de las aplicaciones, pero los sitios de alto tráfico deberían considerar 0,5 segundos o incluso 0,25 segundos para detectar consultas que son individualmente rápidas pero acumulativamente costosas bajo carga.

Registro general de consultas de MySQL

Ubicación: Configurable, típicamente /var/lib/mysql/general.log

El registro general de consultas registra cada instrucción SQL enviada al servidor. No habilite esto en producción sin una razón de diagnóstico específica y con límite de tiempo. En un servidor ocupado, este registro puede crecer a gigabytes por hora y por sí mismo causará degradación del rendimiento. Habilítelo brevemente, reproduzca el problema y luego deshabilítelo inmediatamente.

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';"

Archivos de registro del sistema

Registro de mensajes del sistema

Ubicación: /var/log/messages

El registro de mensajes del kernel y del daemon del sistema. Los errores de hardware (fallos de E/S de disco, errores ECC de memoria), los eventos del eliminador OOM (Out of Memory), los cambios de estado de la interfaz de red y los eventos de carga de módulos del kernel aparecen aquí. Este es el primer registro a verificar cuando un servidor deja de responder o se reinicia inesperadamente.

Verificar eventos del eliminador OOM (un servidor que silenciosamente elimina procesos debido al agotamiento de memoria):

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

Verificar errores de E/S de disco que puedan indicar fallo de unidad:

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

Registro de autenticación segura

Ubicación: /var/log/secure

Registra todos los eventos de autenticación basados en PAM: inicios de sesión SSH (exitosos y fallidos), ejecución de comandos sudo, intentos de su y autenticación iniciada por cron. Este es el registro principal para el análisis forense de seguridad SSH.

Identificar las IPs atacantes principales por número de intentos fallidos de inicio de sesión SSH:

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

Auditar todos los comandos sudo ejecutados en el servidor:

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

Caso especial del mundo real: En servidores con UseDNS yes en sshd_config, las entradas de inicio de sesión fallido pueden mostrar nombres de host en lugar de direcciones IP, lo que rompe el patrón de extracción de IP awk anterior. Verifique su configuración de sshd_config y ajuste el índice de campo en consecuencia.

Buffer de anillo del kernel

Ubicación: Solo en tiempo de ejecución: accesible mediante dmesg

El buffer de anillo del kernel no es un archivo persistente, pero es esencial para diagnosticar eventos a nivel de hardware que ocurren en el momento del arranque o poco después, antes de que syslog se inicialice. En sistemas basados en systemd (CentOS 7+, CloudLinux 7+), los registros persistentes del kernel están disponibles mediante:

journalctl -k --since "1 hour ago"

Archivos de registro de FTP

Registro de ProFTPd

Ubicación: /var/log/proftpd/proftpd.log

ProFTPd es el daemon FTP predeterminado en entornos cPanel. Este registro registra todos los eventos de sesión FTP: intentos de autenticación, navegación por directorios, cargas de archivos, descargas y desconexiones.

Encontrar todos los intentos fallidos de inicio de sesión FTP:

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

Identificar cargas de archivos grandes (posible preparación de malware):

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

Registro de Pure-FTPd

Ubicación: /var/log/pureftpd.log

Los registros de Pure-FTPd se escriben en syslog de forma predeterminada en algunas configuraciones, lo que significa que las entradas pueden aparecer en /var/log/messages en lugar de en un archivo dedicado. Verifique el destino de registro activo:

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

Registros de PHP y a nivel de aplicación

Registro de errores de PHP

Los errores de PHP en entornos cPanel pueden registrarse en múltiples ubicaciones dependiendo del manejador PHP en uso:

La ruta del registro del pool de PHP-FPM incluye el número de versión de PHP. Para PHP 8.2 gestionado por EasyApache 4:

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

El registro de errores de PHP por cuenta puede habilitarse añadiendo lo siguiente al php.ini o .htaccess de la cuenta:

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

Registros de servicios y seguridad específicos de cPanel

Registro del gestor de servicios de cPanel

Ubicación: /usr/local/cpanel/logs/safeapacherestart_log

Registra cada evento de reinicio de Apache activado por el gestor de servicios de cPanel, incluyendo el motivo del reinicio y si tuvo éxito. Útil para correlacionar el tiempo de inactividad de Apache con cambios de configuración.

Registro de copias de seguridad de cPanel

Ubicación: /usr/local/cpanel/logs/cpbackup/

Cada ejecución de copia de seguridad genera un archivo de registro por cuenta en este directorio. Cuando una copia de seguridad falla silenciosamente, este directorio contiene el error específico, ya sea un problema de espacio en disco, un fallo en el volcado de la base de datos o un problema de permisos.

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

Registro de AutoSSL de cPanel

Ubicación: /var/cpanel/logs/autossl/

AutoSSL es el sistema automatizado de aprovisionamiento de certificados Let’s Encrypt / Sectigo de cPanel. Cuando falla la renovación de un certificado SSL, el motivo detallado (fallo de DCV, limitación de velocidad, discrepancia en la validación del dominio) se registra aquí. Este registro es crítico para diagnosticar problemas de vencimiento de certificados HTTPS antes de que causen advertencias en el navegador.

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

Si gestiona certificados SSL en múltiples dominios o necesita certificados más allá de lo que proporciona AutoSSL, los Certificados SSL de un proveedor dedicado ofrecen opciones de validación extendida y comodín que Let’s Encrypt no proporciona.

Referencia comparativa de archivos de registro

Técnicas de análisis de registros en línea de comandos

Comandos esenciales para análisis en tiempo real e histórico

Seguir un registro en tiempo real (el flujo de trabajo más común del administrador de sistemas):

tail -f /var/log/exim_mainlog

Seguir múltiples registros simultáneamente usando multitail (instalar mediante yum install multitail):

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

Extraer y contar valores únicos de un campo específico:

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

Buscar en archivos de registro rotados comprimidos:

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

Filtrar entradas de registro dentro de una ventana de tiempo específica:

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

Contar la distribución de códigos de estado HTTP:

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

Rotación de registros en cPanel

cPanel usa logrotate para gestionar el tamaño de los archivos de registro. La configuración de rotación para los registros gestionados por cPanel está en /etc/logrotate.d/. Los registros de Apache son rotados por el propio mecanismo splitlogs de cPanel, que también divide el registro de acceso global en archivos por dominio.

Verificar la configuración actual de logrotate para un servicio específico:

cat /etc/logrotate.d/syslog

Activar manualmente la rotación de registros para pruebas:

logrotate -f /etc/logrotate.d/syslog

Trampa crítica: Si la rotación de registros está mal configurada o el espacio en disco está agotado, los archivos de registro pueden crecer hasta llenar toda la partición, causando que todos los servicios fallen simultáneamente. Monitoree el uso del disco en la partición que contiene /var/log y /usr/local/apache/logs como práctica operativa estándar.

Gestión centralizada de registros y alertas

Para entornos de producción, particularmente en un Alojamiento VPS o un Servidor Dedicado, depender de la inspección manual de registros es insuficiente a escala. Implemente uno de los siguientes enfoques:

Agregación de registros con reenvío de rsyslog: Configure /etc/rsyslog.conf para reenviar registros a un servidor syslog centralizado o a una plataforma SIEM. Esto preserva los registros incluso si el propio servidor está comprometido.

ELK Stack (Elasticsearch, Logstash, Kibana): Ingiera registros de cPanel mediante agentes Filebeat, analícelos con pipelines de Logstash y visualice patrones en Kibana. Este enfoque permite la búsqueda de texto completo en meses de historial de registros en segundos.

Integración con Fail2ban: Fail2ban lee /var/log/secure y /var/log/exim_mainlog y crea automáticamente reglas de iptables para bloquear IPs atacantes. Opera independientemente de cPHulk y proporciona una capa de defensa adicional.

GoAccess para análisis de registros de Apache: GoAccess es un analizador de registros en tiempo real basado en terminal que produce informes HTML a partir de registros de acceso de Apache sin requerir un despliegue completo de ELK:

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

Los administradores que gestionan múltiples cuentas de cPanel o configuraciones de revendedor en un VPS con cPanel se benefician significativamente de la visibilidad centralizada de registros, ya que los registros de cuentas individuales están de otro modo aislados bajo cada directorio de inicio.

Correlación de registros de infraestructura de correo electrónico

Una de las técnicas de diagnóstico más subestimadas en entornos cPanel es la correlación cruzada de registros de Exim con registros de Dovecot y el registro de autenticación del sistema para rastrear el ciclo de vida completo de un incidente de seguridad de correo electrónico.

Escenario: Un usuario informa que su cuenta está enviando spam que no escribió.

Paso 1 — Identificar los IDs de mensaje de Exim asociados con la cuenta:

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

Paso 2 — Verificar si el envío se originó desde una aplicación web (PHP mail()) o SMTP autenticado:

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

P=esmtpa indica envío SMTP autenticado. P=local o P=pipe indica un script local (probablemente una aplicación web comprometida).

Paso 3 — Si P=esmtpa, encontrar la IP de origen en el registro de autenticación de Dovecot o Exim:

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

Paso 4 — Correlacionar esa IP con /var/log/secure para actividad SSH y con el registro de acceso de cPanel para inicios de sesión en el panel de control.

Esta técnica de correlación de cuatro pasos responde definitivamente si el compromiso fue un robo de credenciales, una aplicación web vulnerable o una cuenta SMTP forzada por fuerza bruta, y esa distinción determina completamente el camino de remediación.

Para organizaciones que ejecutan su propia infraestructura de correo, un entorno de Alojamiento de Correo Electrónico correctamente configurado con monitoreo dedicado de registros proporciona el aislamiento necesario para prevenir daños a la reputación del correo entre cuentas.

Consideraciones sobre registros relacionados con dominios y DNS

Los fallos de resolución DNS a menudo se manifiestan como errores en los registros de aplicaciones en lugar de en un registro DNS dedicado. Named (BIND), que cPanel usa para DNS, registra en /var/log/messages de forma predeterminada.

Verificar errores de BIND:

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

Cuando los problemas de propagación DNS afectan a dominios recién registrados o transferidos, correlacionar el registro de BIND con la configuración de dominio de cPanel ayuda a aislar si el problema es un error en el archivo de zona o un retraso de propagación a nivel del registrador. Si gestiona el registro de dominios y DNS a través de la misma plataforma, el Registro de Dominios con gestión DNS integrada simplifica esta cadena de diagnóstico.

Matriz de decisión práctica: qué registro verificar primero

Conclusiones técnicas clave

• Verifique siempre primero los registros por dominio (/home/username/logs/) antes que los registros globales de Apache: contienen los mismos datos con mucho menos ruido.
• Un /var/log/exim_paniclog no vacío es un incidente P1: Exim puede haber dejado de procesar la cola de correo por completo.
• El registro de cPHulk en /usr/local/cpanel/logs/cphulkd.log es la primera parada correcta para cualquier escenario de bloqueo, no /var/log/secure.
• Habilite el registro de consultas lentas de MySQL (long_query_time = 1) en cualquier servidor de base de datos de producción: la inteligencia de rendimiento que proporciona vale la mínima sobrecarga.
• Correlacione el campo P= de Exim con los registros de autenticación de Dovecot para determinar definitivamente si un incidente de spam se originó por robo de credenciales o una aplicación web comprometida.
• La mala configuración de la rotación de registros es un modo de fallo silencioso: una partición /var/log llena bloqueará todos los servicios simultáneamente sin advertencia.
• zgrep funciona en archivos comprimidos .gz rotados: el análisis histórico de registros no requiere descomprimir archivos manualmente.
• El reenvío centralizado de registros mediante rsyslog es la postura de seguridad mínima viable para cualquier servidor que maneje datos sensibles: los registros locales pueden ser eliminados por un atacante que obtenga acceso root.

Preguntas frecuentes

¿Dónde se encuentran los registros de errores de cPanel?

El registro de errores principal de la aplicación cPanel está en /usr/local/cpanel/logs/error_log. Los errores del servidor web Apache están en /usr/local/apache/logs/error_log, y los errores de PHP por cuenta están en /home/username/logs/domain.com-error_log. Cada servicio mantiene su propio archivo de registro en una ruta distinta.

¿Cómo rastro un mensaje de correo electrónico específico a través de los registros de Exim?

Cada mensaje que Exim procesa recibe un ID de mensaje único visible en /var/log/exim_mainlog. Ejecute grep "MESSAGE_ID" /var/log/exim_mainlog para recuperar cada entrada de registro asociada con ese mensaje, desde la aceptación hasta la entrega final o el rebote.

¿Por qué mi registro de pánico de Exim no está vacío y qué debo hacer?

Un /var/log/exim_paniclog no vacío indica que Exim ha encontrado un error fatal, típicamente un fallo de análisis de configuración, un problema de la biblioteca TLS o la incapacidad de vincularse al puerto 25. Lea las entradas del registro de pánico, luego verifique la sintaxis de configuración de Exim con exim -bV y compruebe que el puerto 25 no esté bloqueado por otro proceso usando ss -tlnp | grep :25.

¿Cómo encuentro qué script PHP está enviando spam a través de Apache?

Filtre el registro principal de Exim por mensajes enviados por el usuario de Apache: grep "U=nobody" /var/log/exim_mainlog. Luego correlacione las marcas de tiempo con las entradas del registro de acceso de Apache para identificar la URL que activó la función de correo. El encabezado X-PHP-Originating-Script (si está habilitado en php.ini) también identificará el archivo de script exacto.

¿Cuál es la forma más rápida de verificar si un servidor está bajo un ataque de fuerza bruta SSH?

Ejecute grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10 para ver las principales direcciones IP atacantes por número de intentos. Luego verifique si cPHulk ya las ha bloqueado comprobando /usr/local/cpanel/logs/cphulkd.log o consultando la base de datos de cPHulk directamente.