Voici le récit d’une intrusion informatique qui s’est déroulée … chez moi.

Préambule

Mon serveur est sous Linux Debian à jour. Le noyau est home made (3.1.0-rc3)

Mon firewall était un OpenBSD. « Était » parce qu’il est HS et je l’ai remplacé avant le jour de l’an par mon point d’accès wifi. Ce dernier fait donc passerelle Wan. Je l’ai configuré pour qu’entrent les ports habituels (http, https, ssh, … ) Avec mon OpenBSD je contrôlais quelles ip entraient en ssh chez moi. Évidemment ce n’est plus le cas avec le point d’accès.

Ma base de comptes utilisateurs est en ldap, sur une autre machine. Dans cette base ldap existent quelques comptes ‘applicatifs’ dont un : ‘upload’

Récit

Je découvre dans les logs (j’ai toujours un shell qui a un œil sur les logs) que l’utilisateur ‘upload’ fait des choses :

pam_unix(cron:session): session opened for user upload by (uid=0)
pam_unix(cron:session): session opened for user www-data by (uid=0)
pam_unix(cron:session): session closed for user upload

La commande ‘w’ m’indique que l’utilisateur upload est connecté, et que la commande qu’il est en train de lancer est ‘sh‘. Cet utilisateur n’est pas censé être loggé, et encore moins lancer un shell.

Un ‘ps -aufx’ m’indique des processus à lui : ./ntpd, ./init, sh et pop3-mail

Le chemin en ‘./’ des binaires m’informe qu’il sont lancés depuis le répertoire où ils demeurent, ce qui n’est pas normal pour ces processus (ntpd et init existent bien sur ma machine mais leur nom quand je fais ‘ps‘ est ntpd et init). Quant à pop3-mail, il n’a rien à faire ici.

Je suis donc en présence d’un petit piratin qui a installé et lancé des choses chez moi. Et ça ne me plaît pas. Je soupçonne qu’un rootkit ait été installé. ‘lsmod‘ ne m’indique rien de fâcheux (ce qui ne prouve rien, étant donné qu’un rootkit modifie justement lsmod pour qu’il n’indique rien de fâcheux)

Je récupère les pid des process et ‘ls -al /proc/<pid>/exe‘ me donne le chemin absolu des exécutables : /tmp/.bash/[…] Intrusion confirmée.

Un saut dans ce répertoire :

512 ./
0 ../
24K CHANGES
4,0K config.h
20K COPYING
4,0K FAQ
512 .h/
12K hdparm
5,0K help/
733K .h.tgz
0 lang/
0 log/
4,0K Makefile
4,0K makefile.out
8,0K makesalt
0 menuconf/
0 motd/
436K ntpd
4,0K psybncchk
4,0K psybnc.conf
4,0K psybnc.conf.old
577K psybnc-linux-ro.tgz
4,0K psybnc.md5sum
4,0K psybnc.pid
36K README
4,0K README.ro
4,0K salt.h
16K SCRIPTING
0 scripts/
1,5K src/
4,0K targets.mak
4,0K TODO
512 tools/
512 webmail/

psybnc est un robot client irc …

Et je trouve dans /tmp:

4,0K libno_ex.so.1.0
8,0K suid
8,0K udev

Ces deux derniers ne tournent pas. A posteriori, là, je soupçonne ces binaires de servir à exploiter une faille du noyau. Google me confirme : http://securityvulns.com/Vdocument698.html

Je tue les process en question, je bouge le répertoire /tmp/.bash et les binaires de /tmp, je supprime le compte upload et je lance une recompilation du noyau.

Dans les logs, je vois :

pam_unix(cron:account): could not identify user (from getpwnam(upload))

Une crontab de upload est toujours lancée par cron. ‘lsof‘ ne m’indique pourtant aucun fichier ouvert appartenant à upload.

Je lance chkrootkit et rkhunter, qui ne m’indiquent rien de probant (à part les faux positifs habituels). Je fais presque entièrement confiance à ces outils, et couplé au fait que je mette à jour mon serveur régulièrement et que mon noyau soit fait maison, ça me fait dire qu’un rootkit a bien peu de chances d’avoir été installé.

Indice supplémentaire : s’il y en a avait eu un, je n’aurais jamais vu les process que j’ai découvert.

Un reboot plus tard (ne JAMAIS faire de reboot : vous risquez de perdre des preuves et d’aggraver les choses, mais en l’occurrence, sur un serveur perso…) et upload ne lance plus de cron. Je récupère tout de même sa crontab (dans /var/spool/cron/crontabs/)

Moralités

Les mauvaises idées :

• Laisser trainer de comptes applicatifs à mot de passe faible, et possédant un shell
• Ne pas faire de copier d’écran, ne pas lancer ‘script’ (qui enregistre tout ce que vous tapez) afin de garder plus de preuves.
• Monter /tmp sans le bit ‘no-executable’ (ce qui était le cas chez moi)

Les bonnes idées :

• Toujours avoir un œil sur les logs.
• Avoir un firewall qui filtre les accès ssh
• Avoir des serveurs à jour tant au niveau appli que noyau.
• Avoir des sauvegardes (pour vérifier les faux positifs de rkhunter)
• Avoir rkhunter et chkrootkit sous la main
• Connaître ps, lsmod, lsof, ‘ls -al /proc/<pid>/‘

Si certain veulent jouer, voilà tout le matériel que j’ai récupéré :
intrusion1.tgz

L’ip d’où s’est connecté le script 222.186.29.69 (Chine)
L’ip qui était connectée à mon serveur 176.9.68.53 (Allemagne)