Fièrement canadien 
Quand votre serveur commence à ralentir de façon inattendue, que les sites web deviennent lents, ou que vous remarquez des délais de livraison des courriels affectant plusieurs comptes, une file d'attente Exim surchargée est l'une des premières choses à vérifier. C'est un problème qui apparaît régulièrement sur les environnements d'hébergement partagé et VPS, et il se trace presque toujours vers un site web compromis ou un script mal configuré qui envoie des courriels en masse à votre insu.
Ce qu'il faut comprendre dès le départ, c'est que vider la file seul n'est pas une correction. Si vous supprimez des milliers de messages en file sans identifier et arrêter la source, la file se remplira à nouveau en quelques heures. Ce guide explique comment vérifier la file, diagnostiquer la source, la vider de façon sécurisée, sécuriser le compte affecté, et empêcher que le problème ne revienne.
Résumé de la correction rapide
- Vérifier la taille actuelle de la file avec
exim -bpc - Inspecter les messages en file pour identifier le compte ou script expéditeur
- Consulter les journaux Exim pour tracer l'origine des courriels sortants
- Supprimer les messages spam de la file
- Localiser et supprimer ou désactiver le script compromis
- Sécuriser le compte cPanel affecté et vérifier les listes noires
Qu'est-ce que la file d'attente Exim et pourquoi se bloque-t-elle?
Exim est l'agent de transfert de courrier que les serveurs cPanel utilisent pour gérer tous les courriels sortants. Lorsqu'un message est envoyé, que ce soit depuis un formulaire de contact de site web, un script PHP, ou un client de messagerie d'utilisateur, il passe par Exim et se trouve brièvement dans la file d'attente pendant qu'Exim tente la livraison. En fonctionnement normal, cela se produit en quelques secondes et la file reste presque vide.
La file se bloque ou se surcharge dans quelques situations spécifiques. La plus courante est un site web piraté exécutant un script de spam qui déclenche des milliers de messages sortants par heure. La deuxième est un plugin, formulaire de contact, ou outil de newsletter légitime mais mal configuré qui a été déclenché pour envoyer à un volume que le serveur ne peut pas traiter à temps. La troisième est un problème de rétrodiffusion où votre serveur a précédemment envoyé du spam et reçoit maintenant un flot de messages de rebond en réponse.
Dans tous ces cas, Exim continue d'essayer de traiter la file, créant de nouveaux processus de livraison aussi vite qu'il peut. Quand la file est suffisamment grande, cela cause une consommation significative de CPU et de mémoire par Exim, ce qui affecte tout le reste sur le serveur. Les pages web ralentissent, les bases de données deviennent lentes, et dans les cas sévères le serveur devient complètement inaccessible.
Étape 1 : Vérifier la taille actuelle de la file
La première chose à faire est d'obtenir une image claire du nombre de messages en file. Connectez-vous à votre serveur en SSH et exécutez :
exim -bpc
Cela retourne un seul nombre représentant le total des messages actuellement en file. Un serveur en bonne santé devrait avoir une file à un ou deux chiffres. Si vous voyez des centaines, la file est en retard et quelque chose ne va pas. Des milliers signifient qu'une situation sérieuse de spam ou de compromission est en cours.
Pour voir les messages réels et leurs détails :
exim -bp
Cela liste chaque message en file avec son identifiant, son âge, sa taille, son expéditeur et son destinataire. Analysez la sortie pour trouver des patterns. Si vous voyez la même adresse d'expéditeur répétée sur des centaines d'entrées, ou le même domaine apparaissant constamment dans la liste des destinataires, c'est votre point de départ pour l'investigation.
Vous pouvez aussi consulter la file visuellement depuis WHM en accédant à Courriel, puis Gestionnaire de file d'attente. Cela vous donne une interface filtrée sans avoir besoin d'utiliser la ligne de commande, bien que pour les files importantes les outils en ligne de commande soient plus rapides.
Étape 2 : Identifier la source du problème
Avant de supprimer quoi que ce soit, vous devez savoir d'où vient le courriel. Le journal principal Exim est la source d'information la plus fiable.
grep "cwd=" /var/log/exim_mainlog | awk '{print $6}' | sort | uniq -c | sort -rn | head -20
Cette commande extrait le répertoire de travail des entrées du journal Exim, ce qui vous indique quel répertoire sur le serveur le script expéditeur exécutait. Les résultats sont triés par fréquence, donc le compte ou script générant le plus de courriels apparaît en premier. Une ligne comme /home/nomdutilisateur/public_html/wp-content/plugins/contact-form pointe directement vers le script responsable.
Vous pouvez aussi rechercher dans le journal principal une fenêtre temporelle spécifique pour voir quand le spam a commencé :
grep "$(date '+%Y-%m-%d')" /var/log/exim_mainlog | grep "<<" | awk '{print $5}' | sort | uniq -c | sort -rn | head -20
Cela montre les adresses d'envoi les plus actives depuis le journal d'aujourd'hui. Si une seule adresse est responsable de milliers d'entrées, ce compte doit être investigué immédiatement.
Dans WHM, vous pouvez aussi utiliser l'outil Suivi de livraison sous Courriel pour rechercher des messages par expéditeur, destinataire, ou plage horaire, ce qui donne une vue plus claire si vous trouvez la sortie en ligne de commande difficile à analyser.
Étape 3 : Supprimer les messages spam de la file
Une fois la source identifiée, vous pouvez supprimer sélectivement ces messages de la file. Si tout le spam provient d'une seule adresse d'expéditeur, vous pouvez supprimer uniquement ces messages :
exiqgrep -f expé[email protected] -i | xargs exim -Mrm
Remplacez expé[email protected] par l'adresse d'expéditeur réelle que vous avez identifiée à l'Étape 2. L'outil exiqgrep filtre la file et retourne uniquement les identifiants de messages correspondant à vos critères, qui sont ensuite passés à exim -Mrm pour suppression.
Si la file est entièrement du spam sans messages légitimes mélangés, vous pouvez tout supprimer d'un coup :
exim -bp | awk '/^ *[0-9]+[mhd]/{print $3}' | xargs exim -Mrm
Utilisez ceci avec prudence. Tout courriel légitime en attente de livraison, comme des messages de réinitialisation de mot de passe ou des courriels transactionnels de vos applications, sera également supprimé. S'il est possible que des courriels légitimes se trouvent dans la file, utilisez l'approche filtrée ci-dessus plutôt que de tout effacer.
Après avoir vidé la file, vérifiez à nouveau le compte avec exim -bpc. Si le nombre recommence immédiatement à augmenter, le script générant le spam fonctionne toujours et doit être traité avant autre chose.
Étape 4 : Localiser et arrêter le script compromis
Vider la file vous donne du temps, mais le problème sous-jacent est toujours présent. Vous devez trouver le script responsable et soit le supprimer, soit le désactiver.
Sur la base de ce que vous avez trouvé dans les journaux Exim à l'Étape 2, naviguez vers le répertoire identifié et recherchez les fichiers récemment modifiés. Les scripts de spam PHP sont souvent injectés sous forme de fichiers inconnus avec des noms d'apparence aléatoire, ou insérés dans des fichiers d'apparence légitime sous forme de blocs de code obscurcis. Exécutez ce qui suit pour trouver les fichiers PHP modifiés dans les dernières 24 heures :
find /home/nomdutilisateur/public_html -name "*.php" -mtime -1 -ls
Remplacez nomdutilisateur par le nom réel du compte cPanel. Les fichiers modifiés récemment que vous ne reconnaissez pas méritent inspection. Les points d'injection courants incluent les répertoires de plugins WordPress, le dossier uploads, les fichiers de thème, et la racine du répertoire public_html.
Regardez à l'intérieur des fichiers suspects pour des signes de code obscurci. Les scripts de spam PHP utilisent fréquemment l'encodage base64, les fonctions eval(), ou des chaînes compressées pour dissimuler ce qu'ils font. Les fichiers de plugins légitimes ne contiennent généralement pas ces patterns.
Si vous trouvez le script, supprimez-le. S'il s'agit de code injecté dans un fichier légitime, supprimez le bloc injecté et laissez le reste du fichier intact. Après la suppression, exécutez à nouveau exim -bpc et observez si la file recommence à grossir. Si ce n'est pas le cas, vous avez trouvé et arrêté la source.
Sur les sites WordPress spécifiquement, les points d'injection de spam les plus courants sont les plugins nuls ou obsolètes, en particulier les plugins de formulaire de contact, SEO, ou gestionnaire de fichiers, les thèmes nuls ou téléchargés depuis des sources non officielles, le répertoire wp-content/uploads qui est accessible en écriture par défaut et un endroit courant pour déposer des scripts, et le fichier wp-config.php ou le fichier .htaccess si l'attaquant avait un accès en écriture.
Étape 5 : Sécuriser le compte affecté
Trouver et supprimer le script de spam n'est pas suffisant. Si un script a été injecté, cela signifie que l'attaquant avait un accès en écriture au système de fichiers. Vous devez comprendre comment il a obtenu cet accès et fermer ce point d'entrée, sinon un nouveau script apparaîtra.
Commencez par changer le mot de passe cPanel et le mot de passe FTP pour le compte affecté. Si le site utilise WordPress, changez également le mot de passe administrateur WordPress et examinez la liste des utilisateurs administrateurs pour tout compte que vous ne reconnaissez pas.
Effectuez une analyse de logiciels malveillants sur le compte. Depuis WHM, vous pouvez utiliser le Scanner de virus sous Centre de sécurité. Pour les sites WordPress spécifiquement, un plugin comme Wordfence ou le scanner Malcare vous donnera une inspection fichier par fichier approfondie que le scanner au niveau serveur peut manquer.
Mettez tout à jour. Les versions obsolètes de WordPress, des plugins et des thèmes sont le vecteur d'attaque le plus courant pour les comptes d'hébergement partagé. Exécutez toutes les mises à jour disponibles immédiatement après avoir supprimé les fichiers malveillants. Si un plugin qui a été compromis n'est plus maintenu et n'a pas de mise à jour disponible, désactivez-le et supprimez-le entièrement.
Examinez les permissions de fichiers. Les répertoires accessibles en écriture par le serveur web qui n'ont pas besoin de l'être devraient être verrouillés. Le répertoire wp-content/uploads a besoin d'un accès en écriture pour les téléversements de médias, mais la plupart des répertoires de plugins et de thèmes n'en ont pas besoin. Définir les répertoires à 755 et les fichiers à 644 est une base raisonnable.
Étape 6 : Vérifier les listes noires IP
Si votre serveur envoyait du spam en volume, il y a de bonnes chances que l'IP de votre serveur soit inscrite sur une ou plusieurs listes noires de courriels. C'est un problème secondaire sérieux car il affecte chaque compte sur le serveur, pas seulement le compromis. Même après avoir arrêté le spam, les courriels de tous les comptes peuvent être rejetés par Gmail, Outlook et d'autres fournisseurs jusqu'à ce que l'IP soit retirée de la liste.
Vérifiez votre IP sur MXToolbox Blacklist Check en recherchant l'adresse IP de votre serveur. Cela vérifie l'IP contre plus de 100 fournisseurs de listes noires et vous montre lesquels vous ont inscrit.
Chaque fournisseur a son propre processus de retrait. Spamhaus a un formulaire de recherche et de retrait en libre-service à spamhaus.org. Les Smart Network Data Services de Microsoft à sendersupport.olc.protection.outlook.com gèrent le retrait pour Outlook et Hotmail. La recherche de Barracuda à barracudacentral.org/rbl/removal-request gère leur liste. Dans tous les cas, vous devez avoir arrêté le spam avant de demander le retrait, car ces fournisseurs vérifient que le problème est résolu avant de procéder.
Le retrait prend généralement entre quelques heures et quelques jours. Pendant que vous attendez, il vaut la peine de configurer ou réviser le DNS inverse de votre serveur (enregistrement PTR) et de s'assurer que vos enregistrements SPF et DKIM sont correctement configurés, car ces signaux aident à rétablir la réputation de votre IP auprès des fournisseurs de messagerie.
Gérer cela via WHMCS
Si vous êtes un revendeur ou si votre hébergement est géré via notre portail client, vous pouvez ouvrir un ticket de support directement depuis votre espace client WHMCS et demander une investigation de la file. Incluez le nom d'hôte ou l'adresse IP de votre serveur et le domaine que vous soupçonnez être la source. Notre équipe a un accès direct aux journaux Exim et aux outils WHM et peut tracer la source et vider la file sans que vous ayez besoin d'un accès SSH.
Si vous êtes un client existant qui exploite un ancien VPS ou serveur dédié autogéré et que vous avez accès à WHM, le Gestionnaire de file d’attente sous la section Courriel fournit une interface visuelle pour consulter et supprimer les messages en file. L’analyse des journaux et la recherche de scripts exigent un accès SSH. Les nouveaux engagements d’infrastructure sont définis comme des services gérés avec des responsabilités écrites.
Causes courantes en résumé
Les installations WordPress compromises sont responsables de la majorité des cas que nous traitons. Les plugins obsolètes, en particulier ceux dans les catégories formulaire de contact, gestion de fichiers et SEO, sont exploités régulièrement et donnent aux attaquants un chemin pour téléverser des scripts PHP. Les plugins et thèmes nuls téléchargés depuis des sources non officielles contiennent fréquemment des portes dérobées qui sont activées à distance. Les mots de passe cPanel ou FTP faibles peuvent être forcés par attaque brute, donnant à un attaquant un accès direct au système de fichiers. Les boucles de courriels, où un script est configuré pour transférer vers une adresse qui rebondit vers le même script, peuvent également remplir rapidement une file sans qu'aucune attaque externe soit impliquée.
Quand contacter le support?
Si vous avez vidé la file et qu'elle continue de se remplir, mais que vous ne pouvez pas localiser le script responsable dans le système de fichiers, une analyse plus approfondie des journaux au niveau du serveur est nécessaire. De même, si votre IP a été mise sur liste noire par plusieurs fournisseurs et que vous n'êtes pas sûr de la façon d'aborder le processus de retrait, ou si vous faites face à un problème à l'échelle du serveur affectant plusieurs comptes cPanel à la fois, ces situations bénéficient d'un accès direct au serveur que la plupart des clients d'hébergement partagé n'ont pas.
Ouvrez un ticket de support depuis votre espace client avec votre nom de domaine, le nom d'hôte du serveur, et une note sur ce que vous avez déjà essayé. Plus vous pouvez fournir de contexte, plus l'investigation est rapide.
Gotekky
Besoin d’aide pour choisir la prochaine étape?
Décrivez ce que vous observez et le résultat recherché. Nous identifierons si un service géré, un projet défini ou une évaluation technique payante est la bonne prochaine étape.