Forum Linux.debian/ubuntu Comportement suspect

Posté par  (site web personnel) .
Étiquettes :
1
19
fév.
2009
Bonjour tout le monde,

J'ai un petit serveur sous debian 4.0.
Je constate depuis ce matin un comportement suspect. Voila les symptomes:

Tout d'abord, j'ai essayé de relancer apache ce matin qui semblait s'être planté. J'ai alors obtenu le message:
(98)Address already in use: make_sock: could not bind to address [::]:80

Etrange, le port 80 semble occuper par quelque chose d'autre ...

Voila ce que donne un netstat -ltunp:
tcp6 0 0 :::80 :::* LISTEN 22622/httpd -DSSL

Ce qui correspond à :
ps aux | grep 22622
www-data 22622 0.0 0.5 4820 2920 ? S Feb12 0:02 /usr/local/apache/bin/httpd -DSSL

Tiens, tiens ... un apache dans /usr/local/ ça me parait bizarre, et effectivement si j'essaye d'aller dans ce répertoire voila ce que j'obtiens:
cd /usr/local/apache
-su: cd: /usr/local/apache: Aucun fichier ou répertoire de ce type

En faisant un autre netstat, voila ce que je vois de bizarre:
Connexions Internet actives (sans serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 51 192.168.0.7:36542 85.235.67.50:https ESTABLISHED
tcp 0 52 192.168.0.7:51270 85.235.67.50:https ESTABLISHED

Et un petit whois sur cette adresse:
inetnum: 85.235.67.0 - 85.235.67.255
netname: EGMTAMM-NET
descr: EGM Trafik Arastirma Merkezi Md.
descr: Ankara / TURKIYE
country: TR
admin-c: MNET2-RIPE
tech-c: MNET2-RIPE
status: ASSIGNED PA
mnt-by: AS13263-MNT
source: RIPE # Filtered

role: RIPE NCC Meteksan Net Operations
address: Meteksan Net Iletisim Hiz. A.S.
address: 5. Cadde, No: 6/A
address: 06800 Bilkent
address: Ankara / TURKEY
phone: +90 312 297 9000
fax-no: +90 312 297 9155
e-mail: noc@meteksan.net.tr
admin-c: AKY670-RIPE
tech-c: KOK7-RIPE
nic-hdl: MNET2-RIPE

Tout ça me parait hautement suspect.

Est-ce que vous savez ce que je pourrais faire pour virer ces process et m'assurer de la sécurité du système ? (ne me dites pas réinstaller sinon je pleure ;))

D'avance merci

  • # si tu ne veux vraiment pas réinstaller

    Posté par  . Évalué à 4.

    un chkrootkit pour trouver les backdoors (depuis un liveCD récent évidemment :D)

    * Un changement de tous les mots de passes sur la machine
    * Un changement de toutes les clefs (ssh et autre)

    si c'est une débian propre (sans truc compilé à la main)
    faire un clone à coté (à partir d'une net install) (tu choppes la liste des packages)

    et faire des sha1sum sur les fichiers du /usr (à partir du liveCD)

    ensuite tu prends tous les fichiers de conf de /etc et tu fais des diffs (toujours à partir du liveCD ) avec ceux du clone :P

    Enfin tu check les .bashrc .profile .bash_profile .tcshrc... de tous les utilisateurs
    (sans oublier les .xsessions) ni tous les .*rc des home

    C'est long et fastidieux.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Le Marquis est mon maître

    Posté par  . Évalué à 5.

    Une seule vraie solution : réinstaller... Hahaha (rire du grand méchant).

    Plus sérieusement, si ta machine a été compromise, c'est la seule vraie solution pour t'assurer qu'elle est à nouveau propre. Si tu as une image (genre mondorescue) dont tu es sure, tu peux aussi t'en servir...

    Sinon, si tu ne veux réellement pas réinstaller, tu peux commencer par :
    - couper ta machine d'Internet, la redémarrer sur un live CD pour rechercher les rootkit (du style https://fedoraproject.org/wiki/SecuritySpin ou http://www.s-t-d.org/index.html )
    - la mettre à jour !!!

    Mais rien ne te garantiera que :
    1) tous les composants non désirés ont été supprimés.
    2) ta faille ne soit pas du à une configuration trop permissive plutôt qu'à une faille logicielle.

    Bon courage !

  • # Pistes

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Moi j'essaierais un find / -name "*httpd*"
    je regarderais tout ce qui tourne sous www-data avec ps auxf|grep www-data
    et j'irai voir ce qu'il y a dans /proc/22622/

    Je pencherai pour un CMS buggué ou écrit avec les pieds qui a un problème de cross-site-scripting; il a pu télécharger et lancer, sous www-data, un exécutable. As-tu désactivé les URL pour fopen dans php.ini?

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: Pistes

      Posté par  (site web personnel) . Évalué à 2.

      Arriver à lancer un serveur sur le port 80 en étant juste www-data c'est fortiche.

    • [^] # Re: Pistes

      Posté par  (site web personnel) . Évalué à 1.

      Le find ne ramène rien d'intéressant ...

      Pour le /proc, j'ai tué le process il s'était relancé en 2 process distinct, je les ai à nouveau tué tous les 2 et ce coup ci je ne les vois plus....

      J'ai également coupé la redirection de port entre l'extérieur et ma machine sur le port 80.

  • # Simple curiosité

    Posté par  (site web personnel) . Évalué à 3.

    Tu as essayé de te connecter sur le port 80 de ta machine ? Avec un navigateur ou en telnet ?

    • [^] # Re: Simple curiosité

      Posté par  (site web personnel) . Évalué à 1.

      Avec un navigateur, ça n'affichait rien du tout ....

      Par contre, je n'ai pas essayé le telnet et maintenant les process ne se relance plus ...

      Je vais voir ce qu'il se passe ...

  • # Sécurité

    Posté par  (site web personnel) . Évalué à 2.

    Action: débrancher le réseau et prendre le temps d'analyser ce qui se passe sur la machine. Au pire, si elle est distante, faire une image disque.

    Dans tous les cas, installer un nouveau serveur, tu ne sais pas ce qui peut rester, par où il est rentré, s'il a encore la main ...

  • # you've been hacked

    Posté par  . Évalué à 4.

    comme tu as pu t'en rendre compte, il ne s'agit pas d'un vrai serveur apache.

    le vrai nom du processus est masqué ce qui fait que tu ne peux pas le voir avec la commande "ps", ça ne veut pas forcément dire que la commande "ps" est compromise, en effet il y a des astuces pour tronquer le nom du process tel qu'il apparait avec "ps", je ne saurais pas te décrire l'astuce mais j'ai déjà rencontré le cas

    pour voir le vrai nom du process, tu peux utiliser la commande "lsof | grep LISTEN".

    Jette également un coup d'oeil à la cron de "www-data"...

    Et oui, tout ceci n'est pas innocent, je me suis déjà fait avoir, un "utilisateur technicien" m'avait installé une saloperie en php et a ouvert une faille (avec remote inclusion etc...), et un petit malin avait installé un robot, mais ce robot n'écoutait pas le port 80...

    Etant donné qu'il s'agissait d'un serveur "dans la nature" que je n'administrais plus, je n'avait pas pu prévenir l'utilisateur des failles qu'il pouvait ouvrir...mais quand une banque s'est plainte de phishing, on m'a vite contacté pour comprendre ce qu'il se passait :)

    ce robot masquait son nom avec "ps" exactement comme toi. mais comme le "pirate" n'était pas passé root, il n'a pu installer son truc que dans /tmp...

    Ce qui est inquiétant dans ton cas, c'est que pour écouter le port 80 il faut être root....donc un coup de chkrootkit me semble quand même important.

    essaye de nous en dire plus sur ton cas

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.