Forum général.général Impossible de supprimer sshd !

• # livecd

  Posté par nicolinux le 01 juillet 2008 à 00:21. Évalué à 2.

  

  tu peut peut être utiliser un livecd tout simple
  
  mais bon je suis loin d'être un pro alors c'est juste une idée :-)

  • [^] # Re: livecd

    Posté par sebzonelibre le 01 juillet 2008 à 00:31. Évalué à 1.

    

    bonsoir et merci de ta réponse mais comme un problème n'arrive jamais seul, mon lecteur cd est mort depuis quelques jours donc la solution n'est pas bonne pour le moment.
    
    de plus je ne sais pas si cette solution marcherai vraiment dans ce genre de cas
    mais hélas c'est pas vérifiable....
    
    merci quand meme

    • [^] # Re: livecd

      Posté par Gniarf le 01 juillet 2008 à 00:44. Évalué à 5.

      

      ben en fait il n'y a surement pas que ton sshd qui a été modifié.
      
      à moins de pouvoir justifier par A+B que ton système est vraiment propre (par exemple avec Tripwire) tu es bon pour une réinstallation.

      • [^] # Re: livecd

        Posté par sebzonelibre le 01 juillet 2008 à 01:19. Évalué à 1.

        

        en fait je pense que si, il c'est connecté et a utilisé un exploit pour prendre la main
        de plus j'ai toutes les commandes dans le bash_history puis comme je m'en suis rendu compte rapidement j'ai coupé le serveur....
        
        mais dans le doute....

• # lsattr & chattr

  Posté par ben (site web personnel) le 01 juillet 2008 à 00:53. Évalué à 8.

  

  Que dis la commande : lsattr /usr/sbin/sshd si tu vois : -----i------------ /usr/sbin/sshd Ça veut dire que ce fichier a été mis en "immutable". Pour enlever cette option : su Password: # chattr +a /usr/sbin/sshd et pour vérifier : lsattr /usr/sbin/sshd ------------------ /usr/sbin/sshd Le "i" devrait ne plus être là. Plus d'info ici : http://www.lea-linux.org/cached/index/Attributs_%C3%A9tendus(...)

  • [^] # Re: lsattr & chattr

    Posté par sebzonelibre le 01 juillet 2008 à 01:02. Évalué à 2.

    

    alors
    
    lsattr /usr/sbin/sshd
    su--ia------- /usr/sbin/sshd
    puis
    chattr +a /usr/sbin/sshd
    et re
    lsattr /usr/sbin/sshd
    
    donne toujours
    su--ia------- /usr/sbin/sshd !!!!
    
    en revanche (et encore merci pour l'idée)
    chattr -a /usr/sbin/sshd puis chattr -i /usr/sbin/sshd
    j'ai bien su----------- /usr/sbin/sshd
    
    et hop ! bingo
    rm -r /usr/sbin/sshd ça marche !!!!
    
    un grand grand merci

• # Mauvaise méthode

  Posté par Kerro le 01 juillet 2008 à 02:28. Évalué à 10.

  

  Ca n'engage que moi, mais une machine qui a été piratée, c'est une machine a réinstaller, point. Pas de bricolage. Chez nous, ça nous prends 50 minutes de réinstaller de A à Z un serveur (manuellement).
  
  Tu viens de passer combien de temps à essayer de virer ssh ? :-)

  • [^] # Re: Mauvaise méthode

    Posté par Obsidian le 01 juillet 2008 à 02:35. Évalué à 0.

    

    Dans ce cas précis, oui, mais il faut savoir faire les deux, à mon avis. Connaître chattr, spécialement en cas de menace (qu'elle soit délibérée ou non), c'est quand même d'utilité publique.
    
    On ne gère pas un Unix comme un Windows. Ce n'est pas un système jetable.

    • [^] # Re: Mauvaise méthode

      Posté par gaaaaaAab le 01 juillet 2008 à 03:08. Évalué à 10.

      

      On ne gère pas un Unix comme un Windows. Ce n'est pas un système jetable.
      
      Pour le coup, c'est pas une histoire de "marque". Quelque soit l'os, un système compromis est un système plus que jetable, il est à jeter !

      • [^] # Re: Mauvaise méthode

        Posté par Obsidian le 01 juillet 2008 à 03:18. Évalué à 3.

        

        C'est bien ce que je dis au début de mon post.
        
        Par contre, d'une manière générale, la « réinstall » n'est pas une solution. D'abord, parce que ça maintient l'utilisateur dans l'ignorance, qui reste donc vulnérable au moindre pépin, ensuite par qu'après le temps de la réinstallation, vient celui de la reconfiguration.
        
        Compromis pour compromis, je trouve que c'est un très bon exercice que d'essayer de nettoyer son système en conditions réelles, même si c'est avant de tout casser. Sebzonelibre a réussi à détecter l'attaque et à en identifier toutes les conséquences, et je l'en félicite.

        • [^] # Re: Mauvaise méthode

          Posté par gaaaaaAab le 01 juillet 2008 à 03:32. Évalué à 2.

          

          ah oui, désolé, je suis passé un peu vite sur le début de ton post. plus qu'un oeil d'ouvert à cette heure là '-)

          • [^] # Re: Mauvaise méthode

            Posté par Obsidian le 01 juillet 2008 à 03:57. Évalué à 2.

            

            Pas grave, moi aussi, je devrais être couché !
            
            Bananuit à tous.

      • [^] # Re: Mauvaise méthode

        Posté par ragoutoutou le 01 juillet 2008 à 18:18. Évalué à 3.

        

        Pour le coup, c'est pas une histoire de "marque". Quelque soit l'os, un système compromis est un système plus que jetable, il est à jeter !
        
        +100
        
        Une machine compromise risque toujours d'avoir été modifiée à un point où il est impossible de récupérer la sauce, ou encore au point où l'admin croit avoir débarrassé la machine des modifs alors qu'il reste un beau rootkit implanté dans la machine après nettoyage des leurres.
        
        Une machine compromise est une machine dont tout l'OS est à réinstaller car à moins d'être un vrai expert en la matière, il est impossible de garantir que le nettoyage est bien fait à fond.

    • [^] # Re: Mauvaise méthode

      Posté par Emmanuel Blindauer (site web personnel) le 01 juillet 2008 à 03:10. Évalué à 4.

      

      A la place du pirate, j'aurai opéré en 2 étapes: d'abord modifier certains binaires (pour faire X ou Y raisons, autre serveur ssh, modules kernel cachés, modification du FS, remise en place auto de la seconde etape), puis effacer les traces et ensuite, celle qui est visible.
      
      Comme ca, et tu en aurait été victime, tu aurait effacé qu'une seule partie, et la première partie mise en place serait resté active.
      
      A moins d'être très très fort, le plus simple est tout de même de restaurer un backup ou de faire une réinstall ...

      • [^] # Re: Mauvaise méthode

        Posté par Obsidian le 01 juillet 2008 à 03:24. Évalué à 2.

        

        Ça me rappelle la fois où un pirate s'est mis à scanner mon port 22, aussi. À cette époque, j'avais sous WindowMaker une dockapp très réactive qui reproduisait l'activité de ma carte réseau. La p'tite LED verte qui se mettait à clignoter frénétiquement n'était pas discrète :-) Un petit coup de tcpdump pour lever les doutes, ensuite ...
        
        Pas eu besoin de gueuler beaucoup. Un p'tit ssh en retour vers sa machine a fait tout de suite comprendre au gars que je l'avais repéré et que je savais ce qu'il faisait.
        
        Maintenant, il y a une Freebox en routeur devant, c'est moins drôle :-)

• # chkrootkit

  Posté par jimee (site web personnel) le 01 juillet 2008 à 10:56. Évalué à 3.

  

  Si tu ne veux pas réinstaller, je te conseille de faire quelques tests plus poussés. Si un pirate s'est approprié ta machine, il a probablement posé une porte dérobée... Certaines sont presque invisibles, et passent allègrement au travers des mailles de ps ou ls... Je te recommande l'excellent chkrootkit.

  • [^] # Re: chkrootkit

    Posté par sebzonelibre le 01 juillet 2008 à 11:20. Évalué à 1.

    

    chrootkit ne trouve rien je pense que c'est bon signe....
    donc je vais quand meme garder les logs sous les yeux quelques temps

    • [^] # Re: chkrootkit

      Posté par Nils Ratusznik (site web personnel, Mastodon) le 01 juillet 2008 à 12:17. Évalué à 3.

      

      Que ce soit chkrootkit ou un autre outil, j'espère que tu l'as exécuté depuis un live-cd pour garantir son efficacité. Ce système n'étant plus vraiment le tiens (façon de parler), on n'est plus sûr de rien.

Suivre le flux des commentaires

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