Attaque ssh scan sur mon serveur

02/12/2008

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.

Ça peut vous intéresser aussi


Règles de base iptables

J’ai dut changé de serveur il y a 2 ...


OpenOffice en mode serveur

Il est parfois compliqué de créer des documents dignes de ...


Tunnel SSH local et renverse

J’ai déjà traité ce sujet il y a quelques ...


Pourquoi Linux est plus sécurisant

On en parle souvent ?

Merci de m'aider à financer mes services

Si vous avez apprécié cet article, je vous serai reconnaissant de m'aider à me payer une petite bière :)

Si vous voulez en savoir plus sur l'utilisation de flattr sur mon blog, lisez cette page: Ayez pitié de moi

Commentaires

Ajouter un commentaire

sereinity - 02/12/2008

Aille, ça fait mal tout ça sur un serveur de production. Il m’est déjà arrivé d’avoir des attaques ssh, je ne connaissait pas celle-ci, mais une fois que j’ai vu la tentative, je suis très vite passé à fail2ban (un service qui bloque l’ip de l’attaquant dès que celui-ci à échouer sa connexion à un autre service (comme ssh) un certain nombre de fois).

Très pratique, je l’ai réglé à 5 tentative chez moi. Ça évite les attaques de brut force pour trouver un mot de passe (l’ip est blacklisté pour une période seulement).

De plus si j’étais toi, je regarderais tout les fichiers qui appartienne à office et qui sont pas à leur place : (find / -user office).

Bonne chance

Metal3d - 03/12/2008

Ha oui bien joué pour le find, effectivement y’a un paquet de bouzins qui sont pas à leur place du tout…

Je vais regarder fail2ban, je te remercie

Xate - 03/12/2008

En fait, sur un serveur compromis, je pense que le seul moyen d’être sûr d’avoir viré toute trace de l’attaquant, c’est une ré-install from scratch…

Metal3d - 03/12/2008

J’y pense sérieusement, je voulais justement monter un peu en options et prendre un dédié un peu plus solide (bien que ce Dedibox v1 soit franchement bien adapté).

Je vais revoir ça pour janvier ou février.

cybolo - 11/12/2008

Merci d’avoir écrit un poste sur ce problème. J’avais le même et en faisant des recherches je suis tombé sur ton site. J’ai suivi grosso modo la même procédure que toi et c’est bon. Mais je suis aussi d’avis qu’un vérification poussée ou réinstall va s’imposer.. Merci!!

Metal3d - 15/12/2008

Une réinstall est vraiment nécessaire que dans le cas où tu doutes du fonctionnement après nettoyage. Pour ma part je suis revenu à une charge identique à celle que j’avais avant l’attaque.

Je n’avais pas une grosse infra sur mon serveur, 3 services en cours et deux utilisateurs non sécurisés (que j’ai finalement sécurisé :) ). Il est vrai que pour d’autres serveurs il faudra certainement reprendre l’installation.

Dans tous les cas, je vais changer de dédibox dans quelques semaines, la réinstallation sera donc obligatoire ;)

Ajouter un commentaire

(*) Votre e-mail ne sera ni revendu, ni rendu public, ni utilisé pour vous proposer des mails commerciaux. Il n'est utilisé que pour vous contacter en cas de souci avec le contenu du commentaire, ou pour vous prévenir d'un nouveau commentaire si vous avez coché la case prévue à cet effet.