cPanel & WHM Fichiers journaux : La référence technique complète pour les administrateurs de serveurs

cPanel & WHM maintient une architecture de journalisation complète et multicouche qui enregistre chaque événement significatif concernant les services web, la distribution du courrier, l’authentification, les bases de données et les opérations système. Chaque fichier journal possède un emplacement, un format et un objectif de diagnostic distincts — savoir quel journal consulter et comment l’analyser efficacement fait la différence entre une résolution en cinq minutes et une investigation de panne de plusieurs heures.

Ce guide couvre chaque fichier journal critique dans un environnement cPanel & WHM de production, notamment les chemins de fichiers, les formats de journaux, les cas d’utilisation diagnostiques réels et les techniques en ligne de commande qu’utilisent réellement les administrateurs système expérimentés.

Pourquoi les fichiers journaux de cPanel & WHM méritent votre attention

Les fichiers journaux ne sont pas seulement une piste d’audit — ils constituent le principal instrument de diagnostic pour toute pile d’hébergement basée sur Linux. Dans un environnement cPanel spécifiquement, la surface de journalisation couvre Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk et la couche applicative cPanel/WHM elle-même.

Les administrateurs qui traitent les journaux de manière réactive — en les consultant uniquement après une défaillance — ratent systématiquement les signaux d’alerte précoces : épuisement progressif de la mémoire, campagnes de force brute incrémentales, accumulation de requêtes lentes et échecs de distribution liés aux certificats. L’analyse proactive des journaux détecte ces schémas avant qu’ils ne deviennent des incidents.

Trois objectifs opérationnels fondamentaux motivent l’analyse des journaux dans les environnements cPanel :

• Diagnostic de la cause racine : Corrélation des horodatages entre les journaux Apache, PHP et MySQL pour identifier le point de défaillance exact dans une chaîne de requêtes.
• Établissement de référence de performance : Identification des requêtes lentes, des réponses HTTP à latence élevée et des processus gourmands en ressources avant qu’ils ne saturent la capacité du serveur.
• Forensique de sécurité : Reconstruction des chronologies d’attaque à partir des journaux d’authentification SSH, des enregistrements cPHulk et des journaux de rejet Exim pour déterminer la portée et les étapes de remédiation.

Fichiers journaux Apache

Apache est le serveur web par défaut dans les environnements cPanel, bien que LiteSpeed soit de plus en plus courant comme remplacement direct. Les deux écrivent des journaux dans des formats compatibles aux mêmes chemins conventionnels.

Journal d’erreurs Apache

Emplacement : /usr/local/apache/logs/error_log

Il s’agit du journal le plus consulté dans toute session de dépannage cPanel. Il capture chaque erreur générée par Apache : erreurs fatales PHP (lorsque PHP s’exécute en tant que module), échecs de syntaxe .htaccess, incompatibilités de règles mod_rewrite, refus de permission, échecs de négociation SSL et erreurs de proxy en amont.

Un détail critique que de nombreux guides omettent : les journaux d’erreurs par domaine existent également et sont souvent plus immédiatement utiles que le journal d’erreurs global. Ils sont situés à :

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

Ces journaux par VirtualHost isolent les erreurs à un seul compte, réduisant considérablement le bruit lorsque vous diagnostiquez un site spécifique sur un serveur partagé.

Schéma de diagnostic courant — boucle de réécriture .htaccess :

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

Schéma de diagnostic courant — erreurs fatales PHP par domaine :

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

Journal d’accès Apache

Emplacement : /usr/local/apache/logs/access_log

Le journal d’accès global enregistre chaque requête HTTP/HTTPS au format Combined Log Format par défaut :

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

Les journaux d’accès par domaine sont stockés à /home/username/logs/domain.com-access_log et constituent la source correcte pour l’analyse du trafic sur des comptes individuels.

Cas d’utilisation pratiques :

• Identification d’une campagne DDoS ou de scraping par fréquence d’IP :

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

• Recherche de toutes les erreurs de la série 500 au cours de la dernière heure (nécessite que les horodatages du journal soient récents) :

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

• Détection des scanners de vulnérabilités par chaîne user-agent :

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

Cas particulier : Sur les serveurs avec piped logging activé dans WHM, le journal d’accès peut être vide ou minimal car les journaux sont acheminés directement vers un démon de traitement des journaux. Vérifiez WHM > Apache Configuration > Global Configuration pour la directive CustomLog si vous trouvez un journal d’accès inopinément vide.

Journal SSL/TLS Apache

Emplacement : /usr/local/apache/logs/ssl_error_log

Ce journal capture les échecs de négociation TLS, les erreurs de validation de certificat et les incompatibilités de suite de chiffrement. Il est essentiel lors du débogage des problèmes de connectivité HTTPS qui n’apparaissent pas dans le journal d’erreurs principal. Consultez-le en premier lorsque les utilisateurs signalent des avertissements SSL du navigateur ou lorsque le renouvellement automatique de certificat via AutoSSL échoue silencieusement.

Journaux d’application cPanel et WHM

Journal d’accès cPanel

Emplacement : /usr/local/cpanel/logs/access_log

Enregistre chaque requête HTTP effectuée vers l’interface cPanel (port 2082/2083). Chaque entrée inclut le nom d’utilisateur authentifié, l’action effectuée et l’IP d’origine. Ce journal est la principale source pour auditer ce qu’un utilisateur spécifique a fait dans son compte cPanel.

Trouver toutes les actions effectuées par un utilisateur spécifique :

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

Journal d’erreurs cPanel

Emplacement : /usr/local/cpanel/logs/error_log

Capture les erreurs internes de la couche applicative cPanel — appels API échoués, plugins cPanel défaillants, erreurs de script Perl dans le backend de cPanel et échecs de rendu de modèles. Si l’interface cPanel génère des erreurs 500 ou si des fonctionnalités spécifiques sont défaillantes, c’est le premier journal à vérifier.

Journal de connexion WHM

Emplacement : /usr/local/cpanel/logs/login_log

Enregistre tous les événements d’authentification WHM — connexions réussies, tentatives échouées, défis d’authentification à deux facteurs et utilisation de jetons API. Ce journal est essentiel pour détecter les accès administratifs non autorisés.

Trouver toutes les tentatives de connexion WHM échouées :

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

Journal de protection contre la force brute cPHulk

Emplacement : /usr/local/cpanel/logs/cphulkd.log

Il s’agit d’un journal que la plupart des guides ignorent entièrement, pourtant c’est l’un des plus importants sur le plan opérationnel. cPHulk est le démon de protection contre la force brute intégré à cPanel. Il surveille les tentatives de connexion SSH, FTP, cPanel et WHM et bloque automatiquement les IP qui dépassent les limites de seuil.

Lorsqu’un administrateur légitime est bloqué hors de WHM ou SSH, la réponse se trouve presque toujours dans ce journal. Vous pouvez également interroger directement la base de données cPHulk :

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

Pour débloquer une IP spécifique depuis la ligne de commande :

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

Journal de mise à jour et d’installation cPanel

Emplacement : /var/cpanel/updatelogs/

Chaque exécution de mise à jour cPanel génère un fichier journal horodaté dans ce répertoire. Lorsqu’une mise à niveau cPanel casse un service ou qu’une fonctionnalité disparaît après une mise à jour, ce répertoire contient la sortie complète du processus de mise à jour, y compris les erreurs survenues lors de l’installation des paquets ou de la migration de configuration.

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

Fichiers journaux de messagerie

La messagerie est systématiquement le sous-système le plus complexe à dépanner dans cPanel. Exim, le MTA par défaut de cPanel, génère trois flux de journaux distincts, chacun servant un objectif de diagnostic particulier.

Journal principal Exim

Emplacement : /var/log/exim_mainlog

Il s’agit du journal principal des transactions de messagerie. Chaque message traité par Exim — entrant ou sortant — génère des entrées couvrant l’acceptation, les décisions de routage, les tentatives de distribution et la disposition finale (distribué, différé ou rejeté).

Anatomie d’une entrée de journal :

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

L’ID de message (1rPqXY-0003aB-Kc) est la clé pour tracer un seul message dans l’ensemble du journal :

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

Tracer tous les courriers sortants d’un compte spécifique (essentiel pour l’investigation du spam) :

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

Cas particulier réel : Lorsqu’une installation WordPress compromise envoie du spam, le journal principal Exim affichera l’utilisateur expéditeur comme nobody (l’utilisateur du processus Apache) plutôt qu’un nom d’utilisateur de compte cPanel. Filtrez spécifiquement pour cela :

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

Journal de rejet Exim

Emplacement : /var/log/exim_rejectlog

Enregistre tous les messages qu’Exim a refusé d’accepter au stade de la connexion SMTP — avant même qu’ils ne soient mis en file d’attente. Les rejets surviennent en raison de correspondances de liste noire RBL, d’échecs SPF/DKIM/DMARC, de chaînes HELO invalides, de refus de relais ou de limitation de débit.

Ce journal est essentiel pour deux scénarios : diagnostiquer pourquoi les courriers entrants légitimes sont rejetés, et auditer l’efficacité de vos règles de filtrage du spam.

Trouver les raisons de rejet les plus courantes :

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

Journal de panique Exim

Emplacement : /var/log/exim_paniclog

Le journal de panique capture les erreurs fatales d’Exim — échecs d’analyse du fichier de configuration, impossibilité de se lier au port 25, échecs de connexion à la base de données et erreurs de bibliothèque TLS. Si ce fichier n’est pas vide, Exim a subi une défaillance critique. Dans de nombreux cas, un journal de panique non vide signifie que la file d’attente des courriers a complètement cessé de traiter.

# 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

Journal Dovecot

Emplacement : /var/log/dovecot.log (et /var/log/dovecot-info.log pour les événements informatifs)

Dovecot gère les connexions IMAP et POP3 dans les environnements cPanel. Les échecs d’authentification, les limites de connexion, les problèmes de verrouillage de boîte aux lettres et les événements d’application de quota apparaissent tous ici. Lorsque les utilisateurs ne peuvent pas se connecter à leur client de messagerie, le journal de Dovecot est l’endroit correct où chercher — pas Exim.

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

Fichiers journaux de base de données

Journal d’erreurs MySQL/MariaDB

Emplacement : /var/lib/mysql/$(hostname).err

Ce journal enregistre les événements de démarrage et d’arrêt de MySQL/MariaDB, les opérations de récupération InnoDB, les erreurs de réplication, les avertissements de corruption de table et toute requête provoquant une erreur au niveau du serveur. C’est la source définitive pour diagnostiquer les plantages de base de données et les redémarrages inattendus.

Récupérer le chemin réel dynamiquement :

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

Vérifier les événements de corruption InnoDB ou de récupération après plantage :

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

Journal des requêtes lentes MySQL

Emplacement : /var/lib/mysql/slowquery.log (lorsqu’activé)

Le journal des requêtes lentes est désactivé par défaut dans la plupart des installations cPanel. L’activer est l’une des actions de réglage des performances les plus utiles que vous puissiez effectuer sur un serveur à forte utilisation de base de données.

Activer le journal des requêtes lentes à l’exécution (sans redémarrage requis) :

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

Une fois activé, utilisez mysqldumpslow pour agréger et classer les pires contrevenants :

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

Cela affiche les 10 premières requêtes par temps d’exécution total — le point de départ le plus exploitable pour l’optimisation des requêtes.

Nuance critique : Un long_query_time de 1 seconde est un seuil de départ raisonnable pour la plupart des applications, mais les sites à fort trafic devraient envisager 0,5 seconde voire 0,25 seconde pour détecter les requêtes individuellement rapides mais cumulativement coûteuses sous charge.

Journal général des requêtes MySQL

Emplacement : Configurable, généralement /var/lib/mysql/general.log

Le journal général des requêtes enregistre chaque instruction SQL envoyée au serveur. N’activez pas ceci en production sans une raison de diagnostic spécifique et limitée dans le temps. Sur un serveur occupé, ce journal peut croître à raison de gigaoctets par heure et causera lui-même une dégradation des performances. Activez-le brièvement, reproduisez le problème, puis désactivez-le immédiatement.

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

Fichiers journaux système

Journal des messages système

Emplacement : /var/log/messages

Le journal des messages du noyau et des démons système. Les erreurs matérielles (échecs d’E/S disque, erreurs ECC de mémoire), les événements du tueur OOM (Out of Memory), les changements d’état des interfaces réseau et les événements de chargement des modules du noyau apparaissent tous ici. C’est le premier journal à vérifier lorsqu’un serveur devient non réactif ou redémarre de manière inattendue.

Vérifier les événements du tueur OOM (un serveur qui tue silencieusement des processus en raison d’un épuisement de la mémoire) :

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

Vérifier les erreurs d’E/S disque pouvant indiquer une défaillance du disque :

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

Journal d’authentification sécurisée

Emplacement : /var/log/secure

Enregistre tous les événements d’authentification basés sur PAM : connexions SSH (réussies et échouées), exécution de commandes sudo, tentatives su et authentification initiée par cron. C’est le journal principal pour la forensique de sécurité SSH.

Identifier les IP attaquantes les plus actives par nombre de tentatives de connexion SSH échouées :

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

Auditer toutes les commandes sudo exécutées sur le serveur :

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

Cas particulier réel : Sur les serveurs avec UseDNS yes dans sshd_config, les entrées de connexion échouée peuvent afficher des noms d’hôtes au lieu d’adresses IP, ce qui casse le schéma d’extraction IP awk ci-dessus. Vérifiez votre paramètre sshd_config et ajustez l’index de champ en conséquence.

Tampon circulaire du noyau

Emplacement : Exécution uniquement — accessible via dmesg

Le tampon circulaire du noyau n’est pas un fichier persistant mais est essentiel pour diagnostiquer les événements au niveau matériel qui surviennent au démarrage ou peu après, avant l’initialisation de syslog. Sur les systèmes basés sur systemd (CentOS 7+, CloudLinux 7+), les journaux du noyau persistants sont disponibles via :

journalctl -k --since "1 hour ago"

Fichiers journaux FTP

Journal ProFTPd

Emplacement : /var/log/proftpd/proftpd.log

ProFTPd est le démon FTP par défaut dans les environnements cPanel. Ce journal enregistre tous les événements de session FTP : tentatives d’authentification, traversée de répertoires, téléchargements de fichiers, téléchargements entrants et déconnexions.

Trouver toutes les tentatives de connexion FTP échouées :

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

Identifier les téléchargements de fichiers volumineux (mise en scène potentielle de logiciels malveillants) :

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

Journal Pure-FTPd

Emplacement : /var/log/pureftpd.log

Les journaux Pure-FTPd sont écrits dans syslog par défaut dans certaines configurations, ce qui signifie que les entrées peuvent apparaître dans /var/log/messages plutôt que dans un fichier dédié. Vérifiez la destination de journalisation active :

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

Journaux PHP et au niveau applicatif

Journal d’erreurs PHP

Les erreurs PHP dans les environnements cPanel peuvent être journalisées à plusieurs emplacements selon le gestionnaire PHP utilisé :

Le chemin du journal du pool PHP-FPM inclut le numéro de version PHP. Pour PHP 8.2 géré par EasyApache 4 :

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

La journalisation des erreurs PHP par compte peut être activée en ajoutant ce qui suit au php.ini ou .htaccess du compte :

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

Journaux de service et de sécurité spécifiques à cPanel

Journal du gestionnaire de services cPanel

Emplacement : /usr/local/cpanel/logs/safeapacherestart_log

Enregistre chaque événement de redémarrage Apache déclenché par le gestionnaire de services de cPanel, y compris la raison du redémarrage et s’il a réussi. Utile pour corréler les temps d’arrêt Apache avec les modifications de configuration.

Journal de sauvegarde cPanel

Emplacement : /usr/local/cpanel/logs/cpbackup/

Chaque exécution de sauvegarde génère un fichier journal par compte dans ce répertoire. Lorsqu’une sauvegarde échoue silencieusement, ce répertoire contient l’erreur spécifique — qu’il s’agisse d’un problème d’espace disque, d’un échec de vidage de base de données ou d’un problème de permissions.

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

Journal AutoSSL cPanel

Emplacement : /var/cpanel/logs/autossl/

AutoSSL est le système de provisionnement automatique de certificats Let’s Encrypt / Sectigo de cPanel. Lorsque le renouvellement d’un certificat SSL échoue, la raison détaillée — échec DCV, limitation de débit, incompatibilité de validation de domaine — est enregistrée ici. Ce journal est essentiel pour diagnostiquer les problèmes d’expiration de certificat HTTPS avant qu’ils ne causent des avertissements dans le navigateur.

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

Si vous gérez des certificats SSL sur plusieurs domaines ou avez besoin de certificats au-delà de ce que fournit AutoSSL, les Certificats SSL d’un fournisseur dédié offrent des options de validation étendue et de caractère générique que Let’s Encrypt ne propose pas.

Référence comparative des fichiers journaux

Techniques d’analyse des journaux en ligne de commande

Commandes essentielles pour l’analyse en temps réel et historique

Suivre un journal en temps réel (le flux de travail sysadmin le plus courant) :

tail -f /var/log/exim_mainlog

Suivre plusieurs journaux simultanément en utilisant multitail (installer via yum install multitail) :

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

Extraire et compter les valeurs uniques d’un champ spécifique :

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

Rechercher dans les archives de journaux compressés et pivotés :

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

Filtrer les entrées de journal dans une fenêtre temporelle spécifique :

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

Compter la distribution des codes de statut HTTP :

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

Rotation des journaux dans cPanel

cPanel utilise logrotate pour gérer la taille des fichiers journaux. La configuration de rotation pour les journaux gérés par cPanel se trouve dans /etc/logrotate.d/. Les journaux Apache sont pivotés par le mécanisme splitlogs propre à cPanel, qui divise également le journal d’accès global en fichiers par domaine.

Vérifier la configuration logrotate actuelle pour un service spécifique :

cat /etc/logrotate.d/syslog

Déclencher manuellement la rotation des journaux pour les tests :

logrotate -f /etc/logrotate.d/syslog

Piège critique : Si la rotation des journaux est mal configurée ou si l’espace disque est épuisé, les fichiers journaux peuvent croître jusqu’à remplir toute la partition, provoquant l’échec simultané de tous les services. Surveillez l’utilisation du disque sur la partition contenant /var/log et /usr/local/apache/logs comme pratique opérationnelle standard.

Gestion centralisée des journaux et alertes

Pour les environnements de production — en particulier sur un Hébergement VPS ou un Serveur Dédié — se fier à l’inspection manuelle des journaux est insuffisant à grande échelle. Mettez en œuvre l’une des approches suivantes :

Agrégation de journaux avec transfert rsyslog : Configurez /etc/rsyslog.conf pour transférer les journaux vers un serveur syslog centralisé ou une plateforme SIEM. Cela préserve les journaux même si le serveur lui-même est compromis.

ELK Stack (Elasticsearch, Logstash, Kibana) : Ingérez les journaux cPanel via des agents Filebeat, analysez-les avec des pipelines Logstash et visualisez les schémas dans Kibana. Cette approche permet la recherche en texte intégral sur des mois d’historique de journaux en quelques secondes.

Intégration Fail2ban : Fail2ban lit /var/log/secure et /var/log/exim_mainlog et crée automatiquement des règles iptables pour bloquer les IP attaquantes. Il fonctionne indépendamment de cPHulk et fournit une couche de défense supplémentaire.

GoAccess pour l’analyse des journaux Apache : GoAccess est un analyseur de journaux en temps réel basé sur le terminal qui produit des rapports HTML à partir des journaux d’accès Apache sans nécessiter un déploiement ELK complet :

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

Les administrateurs gérant plusieurs comptes cPanel ou des configurations de revendeur sur un VPS avec cPanel bénéficient considérablement d’une visibilité centralisée des journaux, car les journaux des comptes individuels sont autrement cloisonnés sous chaque répertoire personnel.

Corrélation des journaux d’infrastructure de messagerie

L’une des techniques de diagnostic les plus sous-estimées dans les environnements cPanel est le recoupement des journaux Exim avec les journaux Dovecot et le journal d’authentification système pour retracer le cycle de vie complet d’un incident de sécurité de messagerie.

Scénario : Un utilisateur signale que son compte envoie du spam qu’il n’a pas écrit.

Étape 1 — Identifier les ID de messages Exim associés au compte :

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

Étape 2 — Vérifier si l’envoi provient d’une application web (PHP mail()) ou d’un SMTP authentifié :

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

P=esmtpa indique une soumission SMTP authentifiée. P=local ou P=pipe indique un script local (probablement une application web compromise).

Étape 3 — Si P=esmtpa, trouver l’IP d’origine dans le journal d’authentification Dovecot ou Exim :

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

Étape 4 — Recouper cette IP avec /var/log/secure pour l’activité SSH et avec le journal d’accès cPanel pour les connexions au panneau de contrôle.

Cette technique de corrélation en quatre étapes répond définitivement à la question de savoir si la compromission était due à un vol d’identifiants, une application web vulnérable ou un compte SMTP forcé par force brute — et cette distinction détermine entièrement le chemin de remédiation.

Pour les organisations gérant leur propre infrastructure de messagerie, un environnement d’Hébergement Email correctement configuré avec une surveillance dédiée des journaux fournit l’isolation nécessaire pour prévenir les dommages à la réputation de messagerie entre comptes.

Considérations relatives aux journaux de domaine et DNS

Les échecs de résolution DNS se manifestent souvent comme des erreurs dans les journaux d’application plutôt que dans un journal DNS dédié. Named (BIND), que cPanel utilise pour le DNS, journalise dans /var/log/messages par défaut.

Vérifier les erreurs BIND :

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

Lorsque des problèmes de propagation DNS affectent des domaines nouvellement enregistrés ou transférés, la corrélation du journal BIND avec la configuration de domaine cPanel aide à isoler si le problème est une erreur de fichier de zone ou un délai de propagation au niveau du registraire. Si vous gérez l’enregistrement de domaine et le DNS via la même plateforme, l’Enregistrement de Domaine avec gestion DNS intégrée simplifie cette chaîne de diagnostic.

Matrice de décision pratique : quel journal vérifier en premier

Points techniques clés à retenir

• Vérifiez toujours les journaux par domaine en premier (/home/username/logs/) avant les journaux Apache globaux — ils contiennent les mêmes données avec beaucoup moins de bruit.
• Un /var/log/exim_paniclog non vide est un incident P1 — Exim a peut-être complètement cessé de traiter la file d’attente des courriers.
• Le journal cPHulk à /usr/local/cpanel/logs/cphulkd.log est le premier arrêt correct pour tout scénario de verrouillage, pas /var/log/secure.
• Activez le journal des requêtes lentes MySQL (long_query_time = 1) sur tout serveur de base de données en production — les informations de performance qu’il fournit valent la surcharge minimale.
• Recoupez le champ P= d’Exim avec les journaux d’authentification Dovecot pour déterminer définitivement si un incident de spam provient d’un vol d’identifiants ou d’une application web compromise.
• Une mauvaise configuration de la rotation des journaux est un mode de défaillance silencieux — une partition /var/log pleine fera planter tous les services simultanément sans avertissement.
• zgrep fonctionne sur les archives .gz pivotées — l’analyse historique des journaux ne nécessite pas de décompresser manuellement les fichiers.
• Le transfert centralisé des journaux via rsyslog est la posture de sécurité minimale viable pour tout serveur gérant des données sensibles — les journaux locaux peuvent être supprimés par un attaquant qui obtient un accès root.

Foire aux questions

Où se trouvent les journaux d’erreurs cPanel ?

Le journal d’erreurs principal de l’application cPanel se trouve à /usr/local/cpanel/logs/error_log. Les erreurs du serveur web Apache se trouvent à /usr/local/apache/logs/error_log, et les erreurs PHP par compte se trouvent dans /home/username/logs/domain.com-error_log. Chaque service maintient son propre fichier journal à un chemin distinct.

Comment tracer un e-mail spécifique dans les journaux Exim ?

Chaque message traité par Exim reçoit un ID de message unique visible dans /var/log/exim_mainlog. Exécutez grep "MESSAGE_ID" /var/log/exim_mainlog pour récupérer chaque entrée de journal associée à ce message, de l’acceptation jusqu’à la distribution finale ou le rejet.

Pourquoi mon journal de panique Exim n’est-il pas vide et que dois-je faire ?

Un /var/log/exim_paniclog non vide indique qu’Exim a rencontré une erreur fatale — généralement un échec d’analyse de configuration, un problème de bibliothèque TLS ou une impossibilité de se lier au port 25. Lisez les entrées du journal de panique, puis vérifiez la syntaxe de configuration d’Exim avec exim -bV et vérifiez que le port 25 n’est pas bloqué par un autre processus en utilisant ss -tlnp | grep :25.

Comment trouver quel script PHP envoie du spam via Apache ?

Filtrez le journal principal Exim pour les messages envoyés par l’utilisateur Apache : grep "U=nobody" /var/log/exim_mainlog. Ensuite, recoupez les horodatages avec les entrées du journal d’accès Apache pour identifier l’URL qui a déclenché la fonction mail. L’en-tête X-PHP-Originating-Script (si activé dans php.ini) identifiera également le fichier de script exact.

Quelle est la façon la plus rapide de vérifier si un serveur est sous une attaque SSH par force brute ?

Exécutez grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10 pour voir les principales adresses IP attaquantes par nombre de tentatives. Vérifiez ensuite si cPHulk les a déjà bloquées en consultant /usr/local/cpanel/logs/cphulkd.log ou en interrogeant directement la base de données cPHulk.