En bref : vous reconnaissez les processus suspects sur les serveurs Linux à quelques caractéristiques : fichier programme supprimé ou situé dans /tmp, /dev/shm ou un répertoire web, nom imitant un processus système, utilisateur inhabituel, connexions réseau persistantes ou charge élevée sans raison. Vérifiez avec des commandes en lecture seule si le fichier programme appartient à un paquet installé, et sauvegardez les découvertes avant d'arrêter quoi que ce soit.
Ce que « suspect » signifie pour un processus
Sur un serveur web tournent des centaines de processus. La plupart appartiennent au système d'exploitation, au serveur web, à la base de données ou à PHP. Un attaquant qui a pu exécuter du code via une faille comme PHP2Shell cherche à ne pas se faire remarquer parmi eux. Il choisit des noms discrets et dépose des programmes là où l'utilisateur du serveur web peut écrire.
Pour la vérification, il est utile de connaître l'état normal. Qui sait quels services doivent tourner sur un serveur, sous quels utilisateurs et avec quelle charge, reconnaît les écarts bien plus vite. Sans cette connaissance, il vaut la peine de comparer avec la liste des processus d'un serveur équivalent et non suspect.
Une caractéristique isolée n'est pas encore une preuve. C'est la combinaison qui est décisive. Un processus portant le nom d'un thread du noyau, qui tourne sous www-data, a été lancé depuis /dev/shm et maintient une connexion vers l'étranger, est un cas clair. La façon de vérifier le cas particulier d'un shell sous le serveur web est décrite dans Signal d'alerte : le serveur web lance un shell.
Premier aperçu en cinq commandes
Toutes les commandes ne font que lire. Exécutez-les en tant que root pour voir tous les processus, et enregistrez les sorties dans un fichier hors du répertoire web.
# 1. Tous les processus avec utilisateur, PID parent, heure de démarrage, CPU et ligne de commande
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Processus dont le fichier programme a été supprimé
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Processus qui tournent depuis des répertoires temporaires ou web
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Processus avec connexions réseau
ss -tunap
# 5. Aperçu des processus des utilisateurs du serveur web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Les noms d'utilisateurs diffèrent selon la distribution et le panneau ; Plesk et d'autres panneaux exécutent souvent PHP sous l'utilisateur du client concerné. Adaptez la liste à votre environnement.
Lisez les sorties en regardant l'heure de démarrage. Les processus qui tournent depuis le dernier redémarrage du serveur appartiennent le plus souvent au système. Les processus lancés en pleine nuit ou dans les jours après le 17 octobre et qui ne correspondent à aucun service méritent l'attention. Comparez aussi le nombre de processus PHP avec ce que permet la configuration de votre pool ; nettement plus de processus sous un utilisateur du serveur web sont un indice.
Processus suspects sous Linux : caractéristiques typiques
| Caractéristique | Pourquoi elle se remarque | Explication bénigne possible ? |
|---|---|---|
| Fichier programme « (deleted) » | les attaquants suppriment des fichiers après le démarrage | oui, après des mises à jour de paquets jusqu'au redémarrage |
Lieu de démarrage /tmp, /dev/shm, répertoire de téléversement |
n'importe qui ou le serveur web peut y écrire | rarement |
Nom entre crochets comme [kworker] |
imite des threads du noyau | non, si un fichier programme se trouve derrière |
| Charge CPU durablement élevée sans motif | typique des mineurs de cryptomonnaie | oui, pour des tâches par lots ou une indexation |
| Processus parent 1 et utilisateur du serveur web | détaché du serveur web, continue de tourner seul | rarement |
| Connexion vers une destination inconnue | contrôle à distance ou fuite de données | oui, pour des mises à jour et des API |
Les vrais threads du noyau n'ont pas de fichier programme ; ls -l /proc/PID/exe ne renvoie pour eux aucun chemin. Si un processus portant un nom de noyau pointe vers un fichier, il est camouflé. En cas de charge élevée sans raison apparente, l'article Mineurs de cryptomonnaie sur le serveur web aide.
Contre-vérification : le fichier programme appartient-il à un paquet ?
Presque tous les programmes légitimes d'un serveur proviennent de la gestion des paquets. Un fichier programme qui n'appartient à aucun paquet n'est pas automatiquement malveillant, mais mérite un examen attentif.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu : à quel paquet appartient le fichier ?
rpm -qf "$EXE" # famille RHEL
sha256sum /proc/$PID/exe # somme de contrôle, fonctionne aussi avec un fichier supprimé
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # variables d'environnement
Si le fichier programme est supprimé, sha256sum /proc/$PID/exe le lit malgré tout depuis le processus en cours. Cette somme de contrôle doit figurer dans la documentation. Une copie du fichier ne devrait être faite que par quelqu'un qui sait la conserver en toute sécurité.
Limites de la vérification sur le système en cours
Toutes les commandes ci-dessus se fient au système que vous êtes en train de vérifier. Pour une intrusion ordinaire via le site web avec les droits de l'utilisateur du serveur web, c'est défendable. Si un attaquant a obtenu les droits root, il peut cacher des processus et falsifier les sorties. Le serveur ne montre alors que ce que l'attaquant autorise.
Des contradictions en sont les indices : une charge sans processus visible, des connexions que le pare-feu voit mais que ss ne montre pas, ou des programmes système modifiés. Dans de tels cas, la vérification doit porter sur une image sécurisée. Sur les systèmes en cours, on y ajoute souvent une sauvegarde de la mémoire vive, car certains logiciels malveillants n'existent que là et laissent à peine de traces sur le disque. Cette sauvegarde doit avoir lieu avant un redémarrage et exige des outils adaptés et de l'expérience. Pourquoi vous devriez la faire avant une réinstallation, Sauvegarder les preuves avant de réinstaller l'explique.
N'arrêtez pas les processus suspects comme première étape. Souvent une tâche cron ou un service les redémarre, et avec le processus disparaissent de la mémoire la ligne de commande, les connexions et le fichier programme supprimé.
Vérifier les démarrages automatiques et étapes suivantes
Un processus malveillant qui disparaîtrait après un redémarrage serait sans valeur pour les attaquants. C'est pourquoi toute découverte de processus pose la question de ce qui le lance. Outre les tâches cron, ce sont surtout les services systemd qui entrent en ligne de compte, qu'un attaquant disposant des droits root peut créer. Sont remarquables les services aux noms génériques dont le fichier programme se trouve dans un répertoire inhabituel, et les fichiers d'unité créés après le 17 octobre.
# Services en cours et fichiers d'unité modifiés récemment
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Une bibliothèque est-elle injectée dans chaque processus ? Le fichier n'existe normalement pas.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Une entrée dans /etc/ld.so.preload est rare sur des serveurs web normaux et un indice fort d'une manipulation avec les droits root. La façon de vérifier complètement les tâches planifiées est décrite dans Repérer les tâches cron cachées comme porte dérobée.
Les étapes suivantes se déroulent ensuite dans cet ordre :
- Sauvegarder les sorties et les sommes de contrôle avec l'heure.
- Chercher la persistance : tâches cron, services et minuteries systemd, clés SSH.
- Établir l'origine : journaux à partir du 20 octobre, nouveaux fichiers dans le répertoire web.
- Isoler le serveur et planifier le nettoyage ou la reconstruction.
Un aperçu de tous les signes typiques après PHP2Shell est donné par Suis-je déjà compromis ?.
Comment PHP SOS aide-t-il concrètement ?
- Évaluer les processus : nous examinons la liste des processus, les fichiers programmes et les connexions et situons chaque découverte.
- Sauvegarder de manière recevable en justice : avec l'expertise forensique informatique, nous sauvegardons la mémoire vive et les supports de données avant que quoi que ce soit ne soit modifié.
- Trouver la persistance : nous recherchons les mécanismes qui redémarrent les processus malveillants.
- Clôturer : nous nettoyons ou reconstruisons et documentons l'incident jusqu'à sa clôture.
Questions fréquentes
Comment reconnaître un processus suspect sous Linux ?
Les caractéristiques typiques sont un fichier programme supprimé, un lieu de démarrage dans /tmp ou /dev/shm, un nom qui imite un processus système, un utilisateur inhabituel et des connexions réseau persistantes. Des caractéristiques isolées sont des indices, plusieurs ensemble un sérieux soupçon.
Que signifie « (deleted) » pour /proc/PID/exe ?
Le fichier programme du processus a été supprimé après son démarrage. Cela arrive légitimement après des mises à jour de paquets, jusqu'au redémarrage du service. Pour des processus issus de dossiers temporaires ou sous l'utilisateur du serveur web, c'est un comportement de camouflage typique.
Puis-je me fier à la sortie de ps ?
Dans une intrusion ordinaire, le plus souvent oui. Mais si un attaquant a obtenu les droits root, il peut manipuler les outils et les sorties. Un contrôle de l'extérieur, par exemple sur une image sécurisée, est alors plus fiable.
Dois-je arrêter un processus suspect avec kill ?
Pas en premier. Sauvegardez d'abord la ligne de commande, le fichier programme, les connexions et l'heure de démarrage. Un processus arrêté ne révèle plus rien, et souvent une tâche cron ou un service le redémarre de toute façon.