Patrice Ferlet
Patrice Ferlet
Créateur de ce blog.
Publié le déc. 2, 2008 Temps de lecture: 5 min

Me suivre sur Mastodon

Attaque ssh scan sur mon serveur

Depuis un moment, je trouvais que mon serveur (qui hébèrge ce blog et aussi Parole de chansons) était un peu chargé. Tant il es vrai que je fais pas mal de tests dessus (serveur openoffice par exemple, et si je dis ça ce n’est pas innocent…) je pensais que mes amusements avaient dut surcharger un peu les processus. La raison était bien pire que je ne le pensais.

Après 10 jours de moulinage, je me dis qu’il serait temps de regarder de plus près ce qu’il se passe (oui ces temps-ci je n’ai pas eut le temps). **uptime** m’annonce une chage énorme, et je commence à me poser des questions… un tour dans **top** me montre un paquet de processus http mais tout à coup je vois des processus “ssh-scan” qui tournent à plein régime !!! Qu’est-ce que c’est que ce truc ???

ps -ax | grep ssh-scan
[...]
 9122 pts/3    S+     0:02 ./ssh-scan 100
 9123 pts/3    S+     0:02 ./ssh-scan 100
 9134 pts/3    R+     0:02 ./ssh-scan 100
 9140 pts/3    S+     0:02 ./ssh-scan 100
 9141 pts/3    S+     0:02 ./ssh-scan 100
 9142 pts/3    S+     0:02 ./ssh-scan 100
 9149 pts/3    S+     0:02 ./ssh-scan 100
 9158 pts/3    R+     0:02 ./ssh-scan 100
 9159 pts/3    S+     0:02 ./ssh-scan 100
 9237 pts/3    S+     0:01 ./ssh-scan 100
 9250 pts/3    S+     0:01 ./ssh-scan 100
 9260 pts/3    S+     0:01 ./ssh-scan 100
[...]

Ceci est un échantillons des 700 processus ssh-scan qui tournent !

Rapidement, je vérifie les connexion à mon serveur:

netstat -taupe
[...]
tcp        0     68 sd-12345:37251              hippo.nsx.de:ssh            ESTABLISHED office     108974907  -                   
tcp        0      0 sd-12345:58189              static.152.217.46.78.cl:ssh ESTABLISHED office     108974861  -                   
tcp        0      0 sd-12345:44397              dedi1077.your-server.de:ssh ESTABLISHED office     108974720  -                   
tcp        0      0 sd-12345:54967              static.216.218.46.78.cl:ssh ESTABLISHED office     108974882  -                   
tcp        0    296 sd-12345:32830              dedi1073.your-server.de:ssh ESTABLISHED office     108975021  -  
[...]
tcp        0      0 *:52830                     *:*                         LISTEN      office     47578624   22889/httpd -DSSL
[...]

Et là, je ne vous montre qu’un échantillons, un comptage me montre près de 1200 connexions SSH par mon utilisateur “office”.

Je comprend rapidement que mon utilisateur “office” a été piraté. Ok, je l’avoue, mon mot de passe était franchement simple, et j’avais dans l’idée de sucrer cet utilisateur après mes tests… j’ai pas été malin de laisser ça sur un serveur de production… soit dit en passant, j’avais limité les droits de “office”, il ne pouvait pas faire grand chose. D’ailleurs en y réfléchissant un peu ssh-scan n’a pas fait grand chose…

J’ai donc changé le mot de passe office, mais cela ne suffira pas, il m’a fallut refaire une clef ssh avec ssh-keygen. Déjà je vois les connexion dans netstat -taupe disparaitre, reste à virer les processus ssh-scan:

killall ssh-scan
#attendre 2 secondes
killall -9 ssh-scan

Reste donc ce truc bizarre… httpd -DSSL, bon netstat m’a filé le pid ==> 22889, donc:

kill 22889

Maintenant j’aimerai comprendre, d’abord où se trouve ce fameux ssh-scan…

find / -name "ssh-scan" 
/tmp/NoTeam/ssh-scan

Ok… je vois…

[office@sd-12345 ~]$ ll /tmp/NoTeam
total 14492
-rw-r--r-- 1 office office        0 avr  7  2008 194.354.pscan.22
-rw-r--r-- 1 office office        0 fév 19  2008 209.16.pscan.22
-rw-r--r-- 1 office office        0 fév 27  2008 210.59.pscan.22
-rw-r--r-- 1 office office        0 mar 20  2008 211.25.pscan.22
-rw-rw-r-- 1 office office        0 nov 30 23:05 212.5.pscan.22
-rw-r--r-- 1 office office        0 mar 21  2008 217.1189.pscan.22
-rw-r--r-- 1 office office   119176 aoû 29 08:12 58.147.pscan.22
-rw-r--r-- 1 office office        0 mar 31  2008 60.298.pscan.22
-rw-r--r-- 1 office office     8289 avr  7  2008 61.9.pscan.22
-rw-r--r-- 1 office office        0 mar 24  2008 87.93.pscan.22
-rw-rw-r-- 1 office office        0 nov 30 23:36 88.191.pscan.22
-rwxr-xr-x 1 office office     1040 nov  4 03:51 a
-rwxr-xr-x 1 office office       89 avr 18  2005 go.sh
-rw-rw-r-- 1 office office   166652 déc  1 11:19 mfu.txt
-rwxr-xr-x 1 office office  2497024 fév 11  2008 pass_file
-rw-r--r-- 1 office office 10673815 jan 31  2007 pass_file2
-rwxr-xr-x 1 office office    16071 oct 11  2005 ps
-rwxr-xr-x 1 office office   453996 fév 11  2008 ss
-rwxr-xr-x 1 office office   842736 nov 24  2004 ssh-scan
-rw-r--r-- 1 office office       58 déc  1 20:33 vuln.txt

Je vois, il fais des logs et utilisais httpd pour les lire de l’exterieur.

Ce que je me demandais, c’est si un crontab existait pour office:

[root@sd-12345 tmp]# su - office
[office@sd-12345 ~]$ crontab -l
* * * * * /home/office/.pickbnc/y2kupdate >/dev/null 2>&1

[office@sd-12345 ~]$ ll /home/office/.pickbnc/y2kupdate
ls: /home/office/.pickbnc/y2kupdate: Aucun fichier ou répertoire de ce type

Ha donc il devait générer le script de lancement car il n’existe plus… Bref, l’idée est évidamment de supprimer ce cron (crontab -e et vous supprimez la ligne).

Bon je continue, je regarde si il n’y a pas d’autres processus lancé par office:

[root@sd-12345 ~]# ps aux | grep office
office    6688  0.0  0.0   2492   916 ?        Ss   Nov30   0:00 ./SCREEN
office    6689  0.0  0.1   4524  1424 pts/3    Ss+  Nov30   0:00 /bin/bash

Allez hop, kill:

kill 6688 6689
    • Ce n’est pas terminé !!!**\\

Certains autres utilisateurs avait des crontabs… genre mon utilisateur “builder” ouvrait une connexion SSH de temps en temps. Bref, cherchez quel utilisateur pose des problèmes, changez son mot de passe (prévenez le quand même hein) et supprimez les processus qu’il a lancé sans le savoir.

Bon, le nettoyage parait pas mal, mais je me demande juste une chose: “c’est quoi cette attaque ? et qu’est-ce qu’elle fait ?” Si vous avez des liens, n’hésitez pas à m’en parler.

Petite note au passage, je pense qu’un reboot du serveur serait de bon aloi… dommage parce que là j’en suis à 204 jours de production sans interruption.

comments powered by Disqus