Ma première infiltration réseau

L’incident

Il est tard, et je reçois deux mails d’OVH m’indiquant que Hetzner et CSIRI-MU se plaigne de scan d’IP de la part d’un de mes VPS.

Première hypothèse : l’email est un scam et ne provient pas d’OVH. Je vérifie la source du mail, ça a bien l’air de provenir de chez eux. Je regarde attentivement le contenu : pas de lien bizarre associé à un quelconque scam. Je mets l’hypothèse de côté et vérifie si le serveur incriminé m’appartient. C’est bien le cas. Premiers frissons. Je regarde ce serveur et m’aperçois que le port 443 d'admin0.linarphy.net (le serveur ayant effectué les opérations malveillantes) ne répond pas.

C’est confirmé, on a pénétré dans mon système. C’est bizarre, mais juste ce fait me met mal à l’aise, comme si on avait pénétré dans mon intimité. Beaucoup plus grave, admin0 est un composant essentiel de mon infrastructure. Par chance, admin1 réplique toutes les données, et ce backup n’est pas compromis. Heureusement, car ces serveurs hébergent mon DNS, mon LDAP et tout plein de trucs essentiels au fonctionnement des autres serveurs. J’en conclus directement que l’attaque n’est pas ciblée et a probablement été automatique, ou au moins semi-automatique. De toute façon, le pirate aurait mieux fait de rester discret et non de scanner des IP si cela avait été le cas. Me voici (un peu) rassuré.

La solution est simple : reset le serveur, mettre admin1 en tant que main dns et de créer une réplique sur admin0. admin1 et admin0 héberge FreeIPA. Je remarque tout de même que le port 443 d’admin1 ne répond pas non plus. Tant qu’à faire, autant essayer de comprendre ce qu’il s’est passé. Une chose est sûre : je ne vais pas beaucoup dormir cette nuit (si je dors).

La connexion à mon compte LDAP via clef privé géré par nsss fonctionne, mais je n’y suis plus sudoer. La configuration LDAP a donc changé. Je peux me connecter avec le mot de passe root qui ne semble pas avoir été modifié (quelle erreur). Je regarde les logs d’Apache (après tout, il ne répond pas), et je vois un restart à minuit. Bizarre. En tout cas, Apache dit qu’il écoute aux ports 443 et 80 en ce moment. J’en conclus que ma configuration Apache a été modifiée. Ça pue. Je peux initier un ticket Kerberos avec mon mdp admin : il n’a pas été modifié.

Je redémarre tout avec systemctl restart ipa et tout redevient comme avant. Si ça se trouve, la panne n’est pas liée à l’incident. Je me rends compte que ma méconnaissance des rouages interne de FreeIPA ne me permet pas de tracer correctement un coupable.

Je cherche dans le syslog, je cherche dans les bash_history, sans rien trouver, à part un restart du service httpd à minuit pile, des heures avant l’incident.

Paranoïa ?

Plus j’y regarde, plus les “preuves de hack” me paraissent faibles. La non-réponse du port 443 ? Largement possible qu’il soit dû à une erreur du côté de FreeIPA. Après tout, ce logiciel est très complexe et une malfonction peut arriver.

Je ne suis plus sudoer ? En fait, avais-je fait le setup qui me permet d’être sudoer dans les serveurs d’administration ? Après quelques recherches, non.

Qu’est-ce qui a été modifié ? Rien.

Pourtant, OVH m’a transmis des plaintes de scans d’IPs. Que s’est-il passé ? Je n’en sais rien.

J’envoie un mail de réponse à OVH en expliquant mes recherches, et le fait qu’aucune brèche n’est visible, en leur demandant s’ils avaient d’autres explications.

Je change toutes les clefs ssh, je change tous les mots de passes, et je m’arrête là.

Conclusion

Plusieurs mois après cet incident, j’en tire deux leçons :