Identifier le compte cPanel responsable d’une surcharge

Le journal quotidien des processus de WHM aide à repérer les comptes à examiner. Pour attribuer une surcharge, il faut ensuite relier ce classement à une heure, un processus et une activité concrète : une forte consommation ne prouve ni abus ni piratage.

1. Sélectionner un compte avec des preuves datées

Avec les droits d’administration WHM, ouvrez Daily Process Log et choisissez la journée concernée. Utilisez le classement comme point de départ ; une moyenne quotidienne peut masquer une pointe courte.

Pendant l’incident, relevez les processus du compte, en remplaçant clienta par son utilisateur réel :

Gardez le PID, son parent, son ancienneté et la commande. Les arguments peuvent contenir des informations privées : expurgez-les avant tout partage. Plusieurs workers PHP du même utilisateur justifient une enquête sur ce compte ; un démon partagé exécuté comme nobody ne permet pas la même conclusion.

Pour l’I/O, rapprochez les PID d’un relevé iotop, si disponible. Un compte peut solliciter fortement le stockage tout en consommant peu de CPU.

2. Relier le compte à son application

Dans les versions récentes de WHM, ouvrez Show Database Processes. Relevez l’utilisateur SQL, la base et le texte de la requête au moment du problème, puis vérifiez leur propriétaire dans la gestion des bases du compte.

Ne confondez pas utilisateur système et utilisateur SQL. Un processus MariaDB commun sert plusieurs clients, et une connexion inactive n’est pas à elle seule une requête coûteuse.

Comparez ensuite le créneau avec les journaux HTTP du domaine et les tâches cron :

• Une campagne réelle doit correspondre à des pages et parcours attendus.
• Des appels répétés vers une route coûteuse peuvent signaler un robot ; son User-Agent reste une déclaration non fiable.
• Des exécutions cron qui se chevauchent orientent vers un problème de durée ou de planification.
• Un fichier ou une tâche inconnue appelle une vérification de sécurité, sans conclure depuis le seul nom du processus.

3. Corriger sans pénaliser les autres clients

Choisissez une intervention limitée au mécanisme démontré. Décalez un export, empêchez son chevauchement, corrigez une requête ou limitez un endpoint après avoir vérifié ses usages légitimes. Conservez une possibilité de retour arrière.

Si une compromission est suspectée, préservez les journaux et les fichiers utiles avant nettoyage. Isolez le compte selon votre procédure d’incident et coordonnez la rotation des accès avec son propriétaire.

Après correction, répétez les observations sur une période comparable. Votre conclusion doit relier compte, activité, ressource et effet de la correction. Une simple capture montrant un utilisateur en tête du classement ne suffit pas pour lui attribuer toutes les lenteurs du serveur.

Sources : cPanel — Daily Process Log, cPanel — database processes.