Journal Réagir en cas d'intrusion

Posté par  (site web personnel) .
Étiquettes : aucune
0
5
fév.
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-(...)

  • # Par principe porte plainte

    Posté par  . Évalué à 8.

    Il y a 9 chances sur 10 que ta plainte finissent oubliée dans une armoire mais fait tout de même la démarche
    -ça te protège si quelqu'un à été victime d'attaque orchestrée depuis ta machine et se retourne contre toi.
    -Si il y a beacoup d'attaque de la même source peut être que la police ouvrira une enquette ( mais pour ça encore faut il qu'il y ai une plainte )
    -De toute façon ça fait une entrée dans les stats de la police.

    Quant au préjudice subit: Précise que ça t'as pourris ton week end à réparer ta machine.Ca fait au moins un préjudice moral mais de toute façon ne compte pas trop être indemnisé. Dans le doute demande une somme sur-réaliste au tribunal ( si procès ) qui comprendra alors le message ( Le tribunal ne peut pas te donner plus que ce que tu as demander. Si tu n'es pas capable d'évaluer ton préjudice demande une somme énorme et le tribunal le feras à ta place )

    • [^] # Re: Par principe porte plainte

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

      Oui, la raison me donne la même réponse que toi :) En particulier pour le 1er point que tu évoque. Ce qui me rebutait c'était les démarches (se déplacer au srpj...). Mais la personne que je viens de contacter au commisariat m'a indiqué qu'il suffisait d'aller au commisariat/gendarmerie du domicile. Charge à eux de faire suivre aux services concernés.

      Pour le préjudice, j'avais même pas imaginé demander une indemnisation. Mais dans ce cas, je peux compter le temps d'analyse + de ré-install au tarif ingénieur majoré du stress :) J'ai quand même passé un sale dimanche !

  • # Intrusion

    Posté par  . Évalué à 6.

    Il y a un certain temps un pirate avait réussi à rentrer dans mon ordinateur en se connectant tout bêtement en ssh. J'ai remarqué la chose quand lorsque je me suis connecté le shell m'a affirmé que je m'étais connecté depuis une adresse canadienne la fois précédente ... Première chose, j'ai coupé le réseau, puis j'ai commencé à regarder les logs. Et là surprise je vois qu'il s'est connecté directement sur la bonne IP avec mon nom d'utilisateur (non trivial) et mon mot de passe (qui ressemble à une sortie de random), et ce du premier coup. En regardant les historiques du shell, j'ai vu qu'il a essayé 1) de passer en root, mais sans succès 2) de se connecter sur des serveurs présents dans known_hosts, mais pas avec mon login, avec celui d'une autre personne ! Après ces échecs il a abandonné. J'ai aussi eu une connexion depuis la Russie. N'ayant que moyennement confiance dans mon ordinateur, j'ai réinstallé ma distribution avec un formatage bien propre, j'ai changé tous mes mots de passe, j'ai écrit aux administrateurs des réseaux d'où les attaques sont provenues et j'ai mis un pare-feu sur mon port ssh en limitant l'accès à certaines adresses connues. Cependant je ne m'explique toujours pas par quel miracle il a réussi à obtenir mes coordonnées exactes. Je n'ai jamais donné mon mot de passe à personne ni même écrit où que ce soit. La seule hypothèse imaginable serait de m'être connecté depuis un ordinateur lui-même vérolé.

    • [^] # Re: Intrusion

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

      Franchement impressionnant qu'un gugus se connecte en ssh presque du premier coup sur ta bécane avec le bon user et le bon pass.
      ça fait peur.

      Pour ma part j'utilise Denyhosts, un script Python qui bannie automatiquement les IP après X essais rejetés par SSH. C'est un script bien clean et très portable car il ne fait qu'analyser auth_log et rajouter des entrées dans hosts.deny.

      Je pense que la combinaison : changement de port+denyhosts permet d'éviter presque toutes les attaques bruteforce par SSH.

    • [^] # Re: Intrusion

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

      A priori, dans mon cas il n'a pas obtenu d'accès utilisateur. Mais tu soulève deux points :
      * je n'ai plus confiance dans ma machine (je n'ai peut-être pas tout vu) et elle va donc aussi se faire formater/re-installer
      * on touche aux limites de sudo. Si un attaquant a obtenu ton mot de passe, il n'a pas qu'un accès utilisateur, il peux obtenir un certain nombre de droits root ! J'en arrive à me dire que pour un serveur sudo n'est pas une bonne solution.

      Sinon, tu peux aussi limiter la connection ssh uniquement par clef, que tu transporte sur ta clef usb. Dans ce cas un keylogger ne devrait pas être en mesure d'obtenir ton authentification.

      • [^] # Re: Intrusion

        Posté par  . Évalué à 3.

        Ce n'est pas un lancer de troll sur sudo, mais :

        >> Si un attaquant a obtenu ton mot de passe, il n'a pas qu'un accès utilisateur

        En quoi le mot de passe administrateur est plus difficile à obtenir que le le mot de passe root ?

        Un autre avantage de sudo niveau sécurité je trouve, c'est l'abscence de mot de passe root (disont c'est la politique par défaut sur Ubuntu). Donc en cas d'attaque sur le serveur, il faut trouver l'utilisateur qui va avoir ces permissions, en plus de son mot de passe, alors qu'avec un vrai compte root, on sait directement qui attaquer.

        Après, la seul faiblesse de la solution sudo se trouve si l'on authorise tout les comptes à faire tout et n'importe quoi avec les droits d'administrateur.
        Mais si il n'y a qu'un compte avec ces droits, je pense que sudo est même peut-être plus sûr que le compte root « normal ».

        • [^] # Re: Intrusion

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

          Un vrai serveur, il interdit les connexion distante pour l'utilisateur root, donc de toute facon tu ne t'attaqueras pas à root en premier...

          >En quoi le mot de passe administrateur est plus difficile à obtenir que le le mot de passe
          >root ?
          Simplement parce que si un attaquant a ton mot de passe utilisateur, c'est qu'il la récupérer en sniffant une connexion non sécurisée, .... Donc, une fois connecté sur la machine, il lui faudrat quand meme trouver le mot de passe root ou exploité une faille locale. Avec sudo, un petit sudo -s et le voila admin de la machine.

        • [^] # Re: Intrusion

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

          Disons alors que dans mon cas, je me demande si sudo est si sécurisant sur un serveur.
          C'est un serveur perso et il n'y a qu'un seul compte. Donc ce compte est équivalent à root.
          Si le mot de passe est compromis c'est un accès root offert sur la machine.

          Si j'avais un compte root à part, il aurait moins de chances d'être récupéré à partir d'un keylogger sur une machine windows ou un MiM sur une connection ssl... puisque par principe on ne se connecte pas en root de l'exterieur.

          Cela dit, je reste un fervent partisant de sudo sur le desktop. Je ne pourrais plus m'en passer.

          • [^] # Re: Intrusion -> sudo sucks (un peu).

            Posté par  . Évalué à 10.

            Honnêtement, le sudo, on va dire pour être gentil que c'est un moindre mal. Je suis actuellement sous Ubuntu, et on en fait grand usage, sinon je l'utilise également sur les serveurs de production du travail. Personnellement, je trouve ça dégueulasse quand même.

            Les avantages de sudo sont :

            - Le traçage des commandes dans le log.
            - La possibilité de révocation éventuelle (sans objet sur une machine personnelle).
            - La non-divulgation du mot de passe root (nécessaire également en cas de révocation).
            - La non-ouverture d'une console, qui en général reste ouverte après usage, ou que l'on confond avec une console utilisateur.
            - Pouvoir exécuter des scripts shell en root ou autre (extrêmement sensible, pas souhaitable à mon avis).

            Pour le reste, c'est un trou de sécurité béant. 9 fois sur 10, le mot de passe est le même que celui de la session utilisateur, mais surtout, le compte utilisateur peut exécuter n'importe quelle commande, et non pas une liste prédéfinie comme le permet /etc/sudoers.

            ce qui revient effectivement à percer root, et permet de court-circuiter l'interdiction de connexion depuis l'extérieur.

            Derrière ce cas de figure se cache, à mon humble avis, le véritable problème : les mauvaises configurations et gestions des droits UNIX initiaux. Dès que l'on se retrouve à devoir faire quelque chose qui sort de l'ordinaire, allez hop ! Un petit coup de sudo. Il n'est pas normal, par exemple, de prendre l'habitude de passer super-utilisateur pour lire un log, fût-il de sécurité. Si c'est quelque chose à faire plus d'une fois, alors il faut prendre le temps de passer le log en read-only pour un groupe donné, et de s'inclure dans ce groupe.

            Unix, en principe, fait du VFS le point d'articulation de toute entité du système, ce qui devrait permettre de tout gérer de manière uniforme. Malheureusement, la plupart des ressources récentes tendent à s'en éloigner. Ça a commencé avec les IPC SysV, et ça se multiplie avec la tendance à vouloir faire du multiplateforme (qui en général, se traduit par une implémentation sous Windows, et des adaptations du produit sur le reste). Je pense qu'il faut commencer par combattre cela pour conserver un pouvoir d'administration, puis s'occuper de mettre en place un système efficace.

            Dans le même esprit, est-ce que l'installation de logiciels via apt-get ou assimilé doit être également une opération super-utilisateur ? Les dépots et les archives étant signés, on sait, en principe, à l'avance ce qui doit être installé. On pourrait alors se contenter de commuter vers un groupe ou un utilisateur installer avec des droits de dépot sur le disque (et rien d'autre), mais pas forcément vers root.

            Si on prend le cas d'une distribution personnelle dans lequel les mises à jour sont au minimum hebdomadaires, on passe son temps à saisir son mot de passe pour obtenir les droits d'admin. Il suffit à n'importe quel script de se mettre en écoute sur le serveur X pour briser la sécurité. Je suis sûr qu'en y allant au culot et en ouvrant une boite de dialogue impromptue, même les utilisateurs les plus avertis se feraient avoir, à force de switcher à tout bout de champ.

            D'une manière générale, en ramenant toutes les opérations privilégiées à des autorisations UNIX et en plaçant une utilisateur dans tous les groupes, ne recrée-t-on pas un compte omnipotent (comme avec sudo) sans la restriction par mot de passe ? Pas tout-à-fait, car on n'autorise à chaque fois que ce qui a été explicitement prévu. Même les effets de bords que cela risque d'engendrer seront potentiellement moins dangereux que l'acquisition même temporaires des super-privilèges.

            Je pense que l'avenir sur les machines personnelles est de :

            - Ramener à une gestion UNIX des droits toutes les opérations qui ne sont pas irréversibles, telles qu'installer un .deb/.rpm signé, ou relancer un serveur web par exemple (typiquement, avec un apache graceful).

            - Faire un usage plus répandu de suid. On a stigmatisé ce procédé à juste titre pendant un temps parce qu'il pouvait introduire une vulnérabilité si l'exécutable contenait une faille. Le problème est exactement le même avec sudo. On peut aussi envisager mettre tous les exécutables à SUID sur une partition dédiée, spécifiée dans le $PATH, et mettre les autres à nosuid. Enfin, on pourrait auditer l'exécution de ces fichiers, à la manière du /var/log/secure. Je pense que des chown/chgrp/chmod sur les fichiers concernés seraient plus propres qu'une entrée texte supplémentaire dans /etc/sudoers.

            - Identifier les tâches privilégiées effectuées régulièrement. Par exemple, changer la résolution de son écran est une tâche qui peut avoir besoin d'être privilégiée, mais qui n'est pas fréquente. Si l'on prend le cas d'un utilisateur débutant, vaut-il mieux mettre en place un sudo exprès pour l'occasion, ou définir un groupe et un setuid, pour permettre à l'utilisateur de faire cette tâche comme on utilise passwd ? La réponse n'est pas évidente.

            Enfin, ce n'est que mon avis ... :-)

            • [^] # Re: Intrusion -> sudo sucks (un peu).

              Posté par  . Évalué à 3.

              Merci pour ces réponses qui donnent à réfléchir.
              Je me serts beaucoup de ssh et pourtant, c'est vrai que je ne m'étais jamais trop préocupé de la configuration de celui-ci.
              Quand à l'interdiction de se connecter à SSH avec le compte root, c'est vrai que je l'avais complètement oublié. Je l'ai relu entre le post de mon commentaire et la réponse qui suivi.

              Quand à la gestion des droits, je suis d'accord avec le fait qu'on passe sans doute trop de temps dessus et la création de compte spécialisé d'est peut-être pas assez utilisé au profit de sudo.

              L'avantage de sudo que tu sites d'ailleurs est en cas d'utilisation multi-utilisateur d'avoir chacun un compte "administrateur" révocable. C'est à dire que si quelqu'un perd un mot de passe ou le donne commence à faire le con, on peu le retirer sans pour cela devoir réaffecter un nouveau mot de passe à tout le monde.
              Au vu de ta réponse, je pense que l'on peut avoir les avantages des deux. En effet sudo permet de prendre les attributs de root, mais pas forcément, et c'est nettement moins utilisé dans ce cas.
              Pourquoi ne pas créé comme dit par exemple des comptes "installation..." en sudo mais ne pointant pas vers root ?
              L'avantage, c'est je pense que ça demande un mot de passe et je considère la saisie du mot de passe comme un garde-fou : une commande va agir sur le système, même si elle est sûr à priori ? demande de mot de passe.
              Sur mon pc, je sais que à part quelques exceptions, si je ne saisie pas de mot de passe, alors toutes les modifications effectuées se font sous mon home, alors que si il y a demande de mot de passe, ça veut dire attention, ceci atteint le système.

              Pour en revenir au multi-utilisateurs et à la gestion des permissions et groupe, je trouve quelque problème à la gestion des droits sous Linux.
              En effet, j'installe souvent Linux sur des pcs devant être utilisé par plusieurs utilisateurs. La structure est souvent la même :
              /home/user1
              /home/user2
              /home/user3
              /home/partage

              Ce dernier est un vrai calvaire. En effet, je n'ai pas trouvé sous linux la possibilité de gérer les droits par dossier. Je m'explique :
              généralement, ce que je fait c'est mettre le dossier /home/partage avec la permission drwxrwsr-x avec un groupe partage.
              Mais le problème est que par défaut, umask est réglé avec 022 et non 002.
              En changeant le 022 par 002, plus de problème avec ce dossier partage, mais après, des bugs arrivent. Par exemple sur ubuntu, à la création d'un nouveau compte, au lancement de gdm, il crée un fichier .dmrc qui se retrouve avec rw-rw-r-- au lieu du rw-r--r-- prévu
              et là, il rale disant que les permissions ne sont pas bonne.
              Ceci-dis, ceci est peut-être un problème de gdm que je devrais signaler.
              Et vous, comment gérez-vous vos dossier partagés ?
              Sinon, j'ai entendu parlé des ACL mais je n'ai jamais poussé en avant parce que j'attends que ce soit plus standardisé pour ne pas avoir de mauvaise surprise avec des programmes qui marche mal avec.
              Après, je pense que beaucoup de chose qui sont peut-être améliorable reste ainsi pour un compatibilté avec Unix. Ai-je faux ?
              Si c'est bien le cas, ne serait-il pas le temps de prendre un peu sa propre voie ?

    • [^] # Re: Intrusion

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

      Il a peut-etre effacé une partie de ces traces !

      • [^] # Re: Intrusion

        Posté par  . Évalué à 3.

        pour ce que cela vaut tu peux également mettre cela dans un cron pour t'avertir des connexions réussies (mais c'est sûr que c'est mieux de traiter le pb à la source) :

        cat /var/log/secure.1 /var/log/secure | grep Accepted | awk -F' ' '{print $1" "$2" "$9}' | uniq -u | mail ton_email s "Loggin Report"

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Intrusion

      Posté par  . Évalué à 3.

      Pas forcément impréssionant. Tu aurais du vérifier ton ~/.ssh/authorized_keys.

  • # Petite suggestion

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

    Il m'est arrivé le même genre de mésaventure qu'à toi (une faille dans awstat qui a conduit au même résultat) sauf que le bot n'a pas pu se connecter au serveur IRC parce qu'iptables était configuré pour rejeter et enregistrer dans les logs tous les paquets à destination de ports autres que les ports "normaux" (genre 25, 80 ...). Tu devrais donc mettre en place ce genre de config si tu ne l'as pas déjà fait.

    Vois aussi http://linuxfr.org/~alis/18871.html

    • [^] # Re: Petite suggestion

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

      Effectivement, je me suis dis ca.
      Mais c'est plus gratifiant/amusant d'installer un truc qui fait des jolis graphiques, du coup on repousse l'install d'IDS ou de règles aux petits oignons jusqu'a ... ce qu'il soit trop tard :(

      Lors de la re-install, ce sera la première chose que je ferais.

  • # et pourtant ca fait un mois que cette faille est connue

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

    L'avis du CERTA sur cette faille:

    http://www.certa.ssi.gouv.fr/site/CERTA-2007-AVI-001/CERTA-2(...)

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

    Posté par  . É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  (Mastodon) . É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  . É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(...)

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

          Posté par  (Mastodon) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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...

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

          Posté par  . É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  (site web personnel) . É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...

  • # Comment se rendre compte d'une intrusion

    Posté par  . Évalué à 1.

    Salut,

    Après la lecture de ton journal, la question que je me pose c'est : comment se rendre compte qu'il y a eu une intrusion ?


    Disont que j'ai un PC qui a quelques ports ouverts (je me connecte de temps en temps) de l'exterieur, et j'aimerai bien pouvoir vérifier ce qui s'y passe.

    • [^] # Re: Comment se rendre compte d'une intrusion

      Posté par  . Évalué à 1.

      Tu lis les logs. Et encore, le vilain qui entre sur ta machine, si c'est pas un noob, virera ses propres traces. Enfin je suppose.
      Et comme y'a trop de logs, tu pries pour qu'un outil synthétisant tout ça te donne la bonne info : logwatch par exemple

  • # Mes idées

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

    J'ai deux projets de securité.

    Un ssh bloqué par default depuis internet et pour ouvrir le port il faut savoir qu'il faut lancer http://server/quelquepart/ouvreport22.cgi ( protégé par .htaccess )

    C'est contraignant, mais je pense bloquer tout connexion vers l'exterieur initialisé par le serveur sauf exceptions ( ntp, sources apt debian, ... )

    • [^] # Re: Mes idées

      Posté par  . Évalué à 2.

      deux projets ?
      'tain je sais plus compter

      pratique qd tu ouvres un tunnel tous les matins pour éviter le proxy du boulot qui veut tout filtrer...

  • # Outil de test

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

    j'ai lu il y a quelque temps qu'il existait des script permettant de tester la vulnérabilité d'un serveur internet, une compile des attaques possibles

    Par contre impossible de mettre la main sur cet outil,
    Si quelqu'un avait un tel lien, je 'en remercierait beaucoup

    ++ Beleys

  • # Règles de base

    Posté par  . Évalué à 0.

    J'espère ne pas redire ce que tout le monde a déjà certainement dis, mais bon je me lance :

    --> Faire tourner ton serveur SSH sur un port non-standard, c'est à dire différent de 22

    --> Interdire les connexions à distance sur le compte root (Donc mettre PermitRoologin à NO ou Forced-command-only)

    --> Interdire l'authentification par mot de passe, donc s'authentifier uniquement avec des clés.

    --> Avoir un système à jour, ainsi que le service SSH

    Avec ces quelques règles de base, tu n'as plus besoin d'installer je ne sais quel outil supplémentaire et tu évites un grand nombre d'attaque.

    Après, il faut aussi faire un petit script iptables pour sécuriser un peu le bouzin...

Suivre le flux des commentaires

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