Obtenir l’accès est la moitié du travail ; l’autre moitié consiste à ne pas le perdre. C’est pourquoi presque tout logiciel malveillant automatisé s’assure d’abord d’être relancé : après un redémarrage, après la suppression du fichier, après un changement de mot de passe. D’où l’histoire familière — « on a nettoyé, et deux jours plus tard c’était revenu ».

Les endroits où cela s’organise ne sont pas si nombreux, et tous se vérifient en quelques minutes. Voici la tournée complète, dans l’ordre.

1. Les clés SSH

Le retour le plus simple : une ligne dans authorized_keys survit à un changement de mot de passe, à une mise à jour du système et à un redémarrage.

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;

Chaque ligne est l’accès permanent de quelqu’un. Si vous ne pouvez pas dire de qui, considérez-le comme étranger. Notez aussi le commentaire en fin de ligne : c’est du texte libre, et une correspondance avec votre propre nom ne prouve rien.

2. Les tâches cron de tous les utilisateurs

Il n’y a pas que votre propre crontab à vérifier :

for u in $(cut -f1 -d: /etc/passwd); do echo "== $u"; sudo crontab -u "$u" -l 2>/dev/null; done
sudo ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
sudo cat /etc/crontab

Ce qu’il faut repérer : des lignes @reboot, de longues commandes encodées, des appels à curl ou wget redirigés vers un interpréteur, tout ce qui est lancé depuis /tmp, /dev/shm ou /var/tmp. Rien de régulier ne s’exécute depuis ces répertoires.

3. Minuteries et services systemd

L’équivalent moderne de cron — et nettement moins souvent vérifié :

systemctl list-timers --all
systemctl list-units --type=service --state=running
sudo ls -la /etc/systemd/system/ /run/systemd/system/

Séparément, les services utilisateur, qui tournent sans droits root et n’apparaissent pas dans la liste générale :

systemctl --user list-units --type=service
sudo ls -la /home/*/.config/systemd/user/

Un détail de plus : si la persistance est activée pour un utilisateur (loginctl enable-linger), ses services tournent sans session active. Cela se vérifie avec loginctl list-users.

4. Les fichiers de démarrage du shell

Du code ajouté à la fin d’un fichier de démarrage du shell s’exécute à chaque connexion :

sudo tail -5 /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile
sudo ls -la /etc/profile.d/

Regardez précisément la fin du fichier — c’est là qu’on ajoute pour ne pas attirer l’œil lors d’un survol.

5. ld.so.preload

Un fichier qui force le système à charger une bibliothèque donnée dans chaque processus lancé. En temps normal, il n’est jamais créé :

ls -l /etc/ld.so.preload

Sa présence est pratiquement un signe non équivoque de compromission profonde, et une telle bibliothèque masque d’ordinaire aussi bien les fichiers que les processus et les connexions réseau. Rien de ce que vous verrez ensuite sur cette machine ne mérite confiance.

6. Les crochets du gestionnaire de paquets

Une méthode rarement envisagée : apt peut exécuter des commandes avant et après chaque opération sur les paquets.

sudo ls -la /etc/apt/apt.conf.d/
sudo grep -r 'DPkg::Pre-Invoke\|DPkg::Post-Invoke\|APT::Update' /etc/apt/apt.conf.d/

Un tel crochet se déclenche à chaque installation de mises à jour — donc régulièrement et en root.

7. Le message du jour sous Ubuntu

Le répertoire /etc/update-motd.d/ contient des scripts exécutables qui tournent à chaque connexion SSH et composent le texte d’accueil. L’endroit est commode précisément parce qu’il a l’air de faire partie du système :

sudo ls -la /etc/update-motd.d/

8. Les tâches différées at

sudo atq
sudo ls -la /var/spool/cron/atjobs/ 2>/dev/null

Un mécanisme ancien et rarement utilisé — donc le moins vérifié de tous.

Que faire si vous trouvez quelque chose

Le premier réflexe est de supprimer la trouvaille immédiatement. C’est une erreur : l’information sur la façon dont elle est arrivée disparaît avec elle, et sans réponse à cette question tout se répétera.

  1. Conserver une copie du fichier ou de la tâche et son heure de modification.
  2. À partir de cette heure, regarder dans les journaux du serveur web et dans auth.log ce qui se passait à la même minute. C’est là que se trouve d’ordinaire le point d’entrée.
  3. Vérifier les huit endroits de la liste, et non seulement celui où quelque chose est apparu. Une porte dérobée n’est presque jamais laissée en un seul exemplaire.
  4. Seulement ensuite nettoyer et fermer la vulnérabilité elle-même.

Savoir à quoi ressemble la normalité

La principale difficulté de cette vérification n’est pas dans les commandes mais dans le fait qu’une ligne inconnue dans une liste de tâches ne paraît pas suspecte si vous ne vous rappelez pas de quoi la liste avait l’air auparavant. Sur un serveur configuré par quelqu’un d’autre, ou configuré il y a un an, distinguer le vôtre de l’étranger est presque impossible.

D’où la conclusion pratique : prendre aujourd’hui un instantané de l’état des lieux a du sens, tant que le serveur va bien. La liste des tâches cron, des minuteries, des clés et des services d’une machine saine est la référence à laquelle on comparera plus tard. Collectée et conservée avec un historique, elle transforme la recherche d’une porte dérobée d’un exercice de plusieurs heures en une comparaison de deux listes. À quoi cela ressemble, les pages de démonstration ci-dessous le montrent.