dimanche 20 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Journal : Réagir en cas d'intrusion

Posté par jjl (page perso, ) le 05 février 2007
Le ciel vient de me tomber sur la tête. J'ai à mon tour été victime d'une intrusion sur mon serveur perso. Ça n'arrive donc pas qu'aux autres :)

En quelques mots, l'attaquant est passé par une faille de cacti pour télécharger un bot irc en perl. Celui-ci se connecte sur un serveur irc et se met en attente de commandes de son maître. En regardant un peu le code, il est capable de :
* participer à des ddos (http, tcp, udp)
* trouver de nouvelles victimes via google (et à priori les infecter)
* executer n'importe quelle commande shell
* ...
Arg, j'ai donc pendant 40h été potentiellement la source de grosses méchancetés. Quand je l'ai découvert, j'ai capturé le trafic réseau et sauvegardé tous les logs. Ainsi j'ai facilement trouvé comment il était entré. Mais impossible d'avoir une idée de ce qu'il a fait pendant ces fameuses 40h :(
D'ou ma première interrogation : comment avoir ce genre d'info ? Peut-on les obtenir post-mortem ou bien faut-il absolument avoir un IDS au préalable pour savoir ce qu'il a fait ?


Voila pour la réaction technique. Maintenant se pose la question de porter plainte. J'ai bien trouvé sur le net la procédure à suivre (visiblement bcp plus facile pour un parisien d'ailleurs), ainsi que les informations nécessaires :
* les logs de la machine
* son adresse physique
* le préjudice subit
C'est ce dernier point qui m'intrigue. Dans la mesure ou mon préjudice semble quasi nul (pas de perte de donnée, visiblement pas de vol d'informations, juste bcp de stress et de perte de temps) est-ce que cette démarche est bien utile ? L'un d'entre vous y a t il déjà été confronté et comment est-ce que ça se passe ?

Pour finir, quelques pointeurs si vous voulez en savoir plus :
Réagir techniquement (pensez à vous préparer) : http://www.hsc.fr/ressources/breves/hackresponse.html.fr
Réagir juridiquement : http://www.xmcopartners.com/article-befti.html
Une analyse plus détaillée sur mon blog : http://kubuntu.free.fr/blog/index.php/2007/02/05/185-reagir-(...)

> Lire le journal (39 commentaires, moyenne: 3,4).  

Vous avez demandé le commentaire #801002.

c'est arrivé près de chez vous...

Posté par DocteurCosmos (page perso, ) le 05/02/2007 à 10:14. (lien). Évalué à 2.

Une fois un script-kiddie est entré sur ma machine en ssh.
J'avais tout simplement oublié que j'avais créé un compte mysql/mysql pour des tests avec un mysql compilé par mes soins...

Quand je m'en suis rendu compte j'ai arrêté le service sshd.

L'intrusion n'a duré que 30/40 minutes.

J'ai conservé les logs. Mais a priori il n'a rien tenté (ce qui me fait penser à un script...).

  • [^]Re: c'est arrivé près de chez vous...

    Posté par Yth (Jabber id, ) le 05/02/2007 à 10:35. (lien). Évalué à 5.

    Idem, j'avais laissé un www/www.
    Manque de bol pour le script kiddie, la machine était un 486, certes robuste, mais il s'est retrouvé presque immédiatement à genoux, impossible de se connecter autrement qu'en console, ses scripts pompaient trop de ressources.

    Même réaction : débrancher le câble réseau, farfouiller un peu : deux comptes avaient été créés, avec des noms venant de l'est, apparemment pas mal d'outils trafiqués pour que ses opérations soient invisibles, et des trucs planqués dans /dev, un répertoire avec des tentatives de compilations de trucs divers (dont un bot IRC).

    Il n'a eu le temps de ne rien faire d'important, j'en ai été quitte pour une bonne réinstallation par prudence, et depuis il n'y a plus de compte débile dessus et je fais mes tests ailleurs...


    Yth, de l'intérêt des vieilles brouettes ? ;)

    • [^]Re: c'est arrivé près de chez vous...

      Posté par Panda (page perso, ) le 05/02/2007 à 12:03. (lien). Évalué à 8.

      J'ai fait un petit [howto] sur la sécurisation d'SSH, il n'est pas parfait mais aucunes attaques réussies sur mon serveur perso.

      http://travisnux.byethost9.com/index.php?2007/01/24/6--howto(...)

      --
      http://travisnux.byethost9.com

      • [^]Re: c'est arrivé près de chez vous...

        Posté par Yth (Jabber id, ) le 05/02/2007 à 12:55. (lien). Évalué à 6.

        Changer le port d'écoute est la méthode la plus efficace pour réduire les tentatives d'accès, donc les possibilités de passer.
        Je m'amusais à regarder à quel point la machine se faisait attaquer, c'était plusieurs heures par jours avec quelques tentatives chaque secondes, sur le port 22 bien sûr.
        Dès que j'ai changé de port, ben plus rien, les bots débiles l'ont dans l'os. Il ne reste plus que les gens un peu motivés, qui sont par nature les plus dangereux, et les plus rares.

        Il est pas mal ton howto, j'ai pas d'idées intelligentes à rajouter à ce que tu as mis dedans.

        Sauf pour le chroot, je me demande si tu ne peux pas très simplement remplacer le shell par un script de ton cru qui ferait un chroot lui-même.
        Ca doit marcher, mais il y a peut-être un piège, genre si on demande explicitement à ssh d'exécuter /bin/tcsh, il doit ignorer le shell par défaut, non ?
        Après ça devient complexe, de remplacer tout les shells par des trucs bidons, et de planquer les shells avec d'autres noms... Ca sent la mauvaise solution qui apporte plus d'emmerdes que de sécurité...


        Yth.

        [^]Re: c'est arrivé près de chez GNOU ..

        Posté par tuiu pol (Jabber id, ) le 05/02/2007 à 13:16. (lien). Évalué à 3.

        Merci ça me fait penser que je dois vérifier un truc sur ma machine, mais, bon, elle tourne que quand j'en ai besoin : j'ai déporté tout ce qui nécessitait du 24/24 sur des serveurs hébergés ailleurs.

        [^]Re: c'est arrivé près de chez vous...

        Posté par Dsls (page perso, ) le 05/02/2007 à 13:43. (lien). Évalué à 1.

        Pour ma part, je suis passé en mode pubkey only, avec mes clefs sur ma clef usb personnelle.
        Du coup, non seulement les kiddies ont très très peu de chances de tomber par hasard sur un bon mot de passe, mais en plus ils sont très facilement désactivables via denyhosts...

      [^]Re: c'est arrivé près de chez vous...

      Posté par gnumdk (page perso, ) le 05/02/2007 à 12:14. (lien). Évalué à 4.

      Toujours pensez à ajouter l'option "AllowUsers" après l'installation d'un serveur ssh, ca évite ce genre de problemes...

      Un petit:
      PermitRootLogin no
      PubkeyAuthentication yes
      PasswordAuthentication no

      Et normalement on est déjà beaucoup plus tranquille...

      --
      Agogo

      • [^]Re: c'est arrivé près de chez vous...

        Posté par michauko (Jabber id, page perso, ) le 05/02/2007 à 14:12. (lien). Évalué à 1.

        - PermitRootLogin no => on est d'accord

        Par contre, j'ai ajouté :
        - AllowUsers (ou Deny, suivant ce qu'on préfère)
        - fail2ban => bloque les IP qui merde x fois en y temps
        - logwatch pour remonter un aperçu de ts les logs, notamment les gens qui bourrinnent trop

        Espérons que je détecte un salopard à l'avance...

        • [^]Re: c'est arrivé près de chez vous...

          Posté par gnumdk (page perso, ) le 05/02/2007 à 14:25. (lien). Évalué à 2.

          pass in on $Internet proto tcp from any to any port ssh flags S/SA keep state (
          max-src-conn-rate 2/10, overload <ssh-bruteforce> flush global)

          Moi j'ai ca dans la conf de mon pare feu (faisable avec iptables aussi), merci d'ailleur à la moule qui m'avait donné cette astuce ici même :)

          Actuellement, j'ai tout ce beau monde de banni:
          # pfctl -t ssh-bruteforce -T show
          24.155.108.45
          61.132.254.157
          80.219.220.222
          83.13.64.178
          83.15.224.166
          140.164.63.70
          200.38.71.65
          200.63.254.205
          200.66.96.99
          200.75.2.92
          200.123.130.185
          200.159.78.20
          201.236.85.110
          202.130.106.89
          203.92.57.121
          203.127.35.164
          203.199.149.35
          210.118.170.130
          213.41.120.35
          213.60.2.68
          213.137.3.241
          216.41.76.13
          216.227.208.96
          217.71.245.98
          217.159.152.34
          218.38.29.123
          220.95.216.71
          #

          Bon, je me pars quand meme du principe que j'ai tres peu de chance de vouloir un jour acceder à ma machine depuis l'ip d'un mec qui m'a attaqué. Si un jour je me fais avoir, ca sera tant pis pour moi et je remettrai ssh-bruteforce en table non persistante...

          --
          Agogo

          • [^]Re: c'est arrivé près de chez vous...

            Posté par Gniarf () le 05/02/2007 à 17:37. (lien). Évalué à 3.

            à ce prix-là, autant filtrer aussi directement en amont de nombreux pays improbables avec des listes comme http://blackholes.us/zones/countries/ , pour le ssh comme pour le mail

            --
            Windows has no users. It has hostages.

            [^]Re: c'est arrivé près de chez vous...

            Posté par gaston () le 05/02/2007 à 17:37. (lien). Évalué à 2.

            La source de cette astuce est probablement http://wiki.gcu.info/doku.php?id=bsd:pf_et_bruteforce ...

            • [+] [^]Re: c'est arrivé près de chez vous...

              Posté par michauko (Jabber id, page perso, ) le 05/02/2007 à 20:35. (lien). Évalué à -1.

              au risque de me répéter, installez le pkg fail2ban
              Ca scanne tout un tas de logs et vérifie : si un user est trop insistant (et se plante de passwd web, ssh, sql etc) le vire 30 minutes

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0604s (dont 0.0056 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.