La question surgit rarement de nulle part. Le serveur est devenu plus lent, l’hébergeur a écrit au sujet du trafic sortant, ou bien la messagerie contient une alerte de connexion que vous n’avez pas effectuée. Ensuite commence le plus désagréable : on ne sait pas quoi examiner ni dans quel ordre, et le premier réflexe — tout effacer et réinstaller — est presque toujours prématuré.

Voici un ordre de vérification qui prend une vingtaine de minutes et donne, dans la plupart des cas, une réponse nette. Il va du moins coûteux au plus coûteux : d’abord ce qui se voit immédiatement, ensuite ce qui exige une comparaison.

Étape un : qui s’est connecté

Commencez par les connexions. Si quelqu’un est entré, c’est presque certainement par SSH, et une trace subsiste.

last -20
lastb | head -20
who

last affiche les dernières connexions réussies, lastb les échecs, who qui est connecté à l’instant. Ce qui compte n’est pas le nombre mais la forme. Des milliers de tentatives échouées provenant d’adresses qui ne reviennent jamais, c’est le bruit de fond ordinaire ; il frappe toute adresse publique sans interruption et ne signifie rien.

Ce qui est inquiétant est autre chose :

  • une connexion réussie depuis une adresse où aucun des vôtres ne se trouve ;
  • une connexion sous un nom d’utilisateur que vous n’avez jamais créé ;
  • des échecs sous un nom qui existe réellement sur cette machine — cela signifie que quelqu’un connaît la liste de vos utilisateurs et ne se contente pas d’un dictionnaire ;
  • une session ouverte en ce moment que vous n’avez pas ouverte.

Vérifiez aussi si des clés étrangères sont apparues. Le fichier ~/.ssh/authorized_keys est le moyen le plus courant de s’installer durablement : le mot de passe peut être changé autant de fois qu’on veut, la clé reste.

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

Chaque ligne y représente l’accès de quelqu’un. Si vous ne pouvez pas dire de qui, considérez qu’il est étranger.

Étape deux : ce qui a changé dans le système

Une intrusion laisse presque toujours des traces sur le disque : un binaire remplacé, une ligne ajoutée à une configuration, un fichier nouveau dans le répertoire du serveur web. Vérifier cela à l’œil est sans espoir — il faut une référence.

Sous Debian et Ubuntu, la référence existe déjà : chaque paquet connaît les sommes de contrôle de ses propres fichiers.

sudo apt install debsums
sudo debsums -c

La commande liste les fichiers qui diffèrent de ce qu’a installé la distribution. Une partie des résultats sera légitime — les fichiers de configuration sous /etc existent précisément pour être modifiés. En revanche, un exécutable modifié dans /usr/bin, /usr/sbin ou /bin sur un serveur que vous n’avez jamais touché à la main, c’est déjà un sujet.

La deuxième source, ce sont les fichiers récents là où il ne devrait pas y en avoir. Un web shell se trouve d’ordinaire dans le répertoire des téléversements et ressemble à un .php anodin :

find /var/www -type f -name '*.php' -mtime -14 -ls

Quatorze jours ne sont qu’un point de départ ; mettez la période pendant laquelle vous êtes certain de n’avoir rien publié.

Étape trois : ce qui sort

Un serveur compromis est rarement pris pour lui-même. On s’en sert : pour envoyer du spam, pour miner, pour atteindre d’autres réseaux, pour héberger les fichiers d’autrui. Tout cela crée des connexions sortantes qui n’existaient pas auparavant.

ss -tulpn
ss -tp state established

La première commande montre ce qui écoute, la seconde ce qui est établi en ce moment. Il faut lire la colonne du processus. Ce qui pose question : un processus inconnu qui écoute sur 0.0.0.0 ; des connexions sortantes vers des ports élevés à des adresses avec lesquelles votre application n’a rien à faire ; et surtout un processus lancé depuis /tmp ou /dev/shm — rien de légitime ne s’exécute depuis ces répertoires.

Regardez au passage la charge. Un mineur se trahit par un processeur occupé en permanence alors que le site ne connaît aucune popularité.

Si les signes sont là

Le premier réflexe est de nettoyer vite : supprimer la clé étrangère, tuer le processus, effacer le fichier. Ne le faites pas — vous détruiriez précisément ce qui permettrait ensuite de comprendre par où il est entré. Et si cela reste incompris, il reviendra, peut-être dès demain.

Un ordre qui préserve à la fois les données et le tableau :

  1. Prendre un instantané du disque chez l’hébergeur, si c’est possible. C’est la seule étape qui ne peut pas être refaite plus tard.
  2. Couper la machine du réseau ou tout fermer sauf votre propre IP — mais ne pas l’éteindre. En l’éteignant, vous perdez la liste des processus et les connexions ouvertes, soit la moitié des indices.
  3. Sauvegarder les journaux à l’extérieur : /var/log/auth.log, les journaux du serveur web, la sortie des trois commandes ci-dessus.
  4. Seulement maintenant, chercher comment l’accès a été obtenu.

Une réinstallation complète est la bonne conclusion si l’accès a été obtenu avec les droits root. Aucun nettoyage ne garantit qu’il ne reste rien. Mais réinstaller sans avoir compris la cause n’a pas de sens : vous remettriez la même faille sur un système neuf.

Pour que la question ne surgisse pas à l’improviste

Tout ce qui précède est une vérification manuelle ponctuelle, et elle répond à la question « que se passe-t-il en ce moment ». L’ennui est qu’on la pose d’ordinaire tard : quand l’hébergeur a déjà écrit ou que le site est tombé.

Chacune de ces vérifications existe sous forme d’outil autonome capable de surveiller en continu : les connexions échouées — fail2ban, les modifications de fichiers — AIDE, l’intégrité des paquets — debsums, les ports ouverts — un instantané régulier de ss. Les installer séparément n’est pas difficile ; ce qui l’est, c’est de prendre l’habitude de lire chaque jour six sorties différentes — raison pour laquelle, en pratique, on ne les lit pas.

C’est exactement le sens d’un tableau de bord unifié : les mêmes données, mais sur une seule page et avec un historique, pour que « ce n’était pas comme cela hier » se voie sans qu’il faille aller le chercher. Ci-dessous, les pages de démonstration qui montrent à quoi cela ressemble une fois assemblé.