• # => -1 <=

    Posté par  . Évalué à -6.

    Allo, Houston ? We've got a problem !

    • [^] # Re: => -1 <=

      Posté par  . Évalué à -3.

      Austin Powers 1, 2 et 3 ;o)

      Me trompe-je ?

  • # Re: Cheval de Troie découvert dans la libpcap et tcpdump

    Posté par  . Évalué à 10.

    Comme quoi il faut toujours bien vérifier l'intégrité des sources. Cependant une question m'assaille. Qui a mis ce pu$!#n de troyen dans le source? Pas les développeurs je présume. La question est sans doute naïve, mais comment ont-ils fait pour introduire ça?

    • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

      Posté par  . Évalué à 5.

      Les mirroirs ne font pas de md5sum ?

      • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

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

        Malheureusement non, ça prendrait trop de ressources sur les serveurs (calcul et où temps).

        Par contre, un truc qui serait interressant sur les serveurs officiels (pas les mirroirs) serait un faire tourner un «aide» ou un «tripwire» sur les fichiers mis à disposition. Cela permettrait d'avoir un niveau de confiance supérieur.

        De plus l'utilisation des attributs étendus des systèmes de fichiers ext2/ext3 permettrait aussi d'éviter ce genre de problème.

        Mais ces solutions sont coûteuses dans le sens où il faut faire de l'administration active et non passive comme c'est le cas maintenant.

        • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

          Posté par  . Évalué à 6.

          D'un autre côté, peu importe que les mirroirs ne fassent pas de md5sum tant que celui ci est lisible sur un PNG du site central et vérifié à chaque téléchargement.
          Mais qui fait ça à chaque fois ?
          J'ai presque peur pour ma debian.

          • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

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

            J'ai presque peur pour ma debian.


            je dirais plus simplement, «j'ai presque peur» tout court...

            • [^] # Cheval de Troie et virus pour TOUS les logiciels, surtout non libres

              Posté par  . Évalué à 10.

              Tout le monde peut avoir peur puisque ajouter un cheval de troie ou un virus est très facile, y compris dans les logiciels propriétaires dont le source n'est pas disponible (la plupart des virus modifient n'importe quel .exe ou .dll pour s'y insérer). Insérer un cheval de troie dans un binaire ne nécessite même pas de comprendre ou de décompiler ce binaire.

              Les distributions Linux ont avantage de ce point de vue: la plupart des mainteneurs officiels (et certains utilisateurs) opèrent des "diff" (affichage des lignes ajoutées ou modifiées) à chaque fois qu'une nouvelle verion du code source est publiée. C'est comme cela qu'ils peuvent se rendre compte assez facilement que du code louche a été ajouté à un logiciel libre.

              Cela explique pourquoi la grande majorité des troyens distribués sous forme de source n'ont jamais affecté les sources et binaires officiellement distribués par les grandes distribs Linux.

              Les utilisateurs de distrib qui se contentent d'installer des paquets et des mises-à-jour officiellement signés par leur distrib (10000 softs sont signés par Debian) courent nettement moins de risques que les utilisateurs de Windows qui installent toutes sortes de soft téléchargés sur des sites webs divers (sans compter les Cd-roms de sharewares ou les warez)

          • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

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

            pourquoi sur un png ? si la personne est capable de modifier un fichier avec le chiffre en clair tu ne la crois pas capable de modifier l'image ?

        • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

          Posté par  . Évalué à 7.

          Par contre, un truc qui serait interressant sur les serveurs officiels (pas les mirroirs) serait un faire tourner un «aide» ou un «tripwire» sur les fichiers mis à disposition. Cela permettrait d'avoir un niveau de confiance supérieur.

          De mémoire, c'est comme ca que la ASF avait découvert que quelqu'un avait glissé un trojan dans les sources d'Apache. Ils ont pu arreter la synchro des mirroirs, remettre les sources d'origine puis re-activer la synchro. L'incident était bouclé en moins de 24 heures.

      • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

        Posté par  . Évalué à 3.

        Le md5 ne sert pas à ça. Il est destiné uniquement à vérifier que la version downloadée est identique à l'original.

        De toutes façons, si un pirate peut modifier les fichiers distribués, il changera aussi le fichier md5 associé.

        La seule solution est de signer le fichier md5 avec GPG, et de vérifier la signature et le md5 quand on télécharge un fichier.

        Mais qui le fait ?

    • [^] # intégrité des sources : pourquoi faire ?

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

      Juste une précision. La plupart des personnes croient que l'intégrité des sources constitue une sécurité : c'est faux, l'intégrité des sources n'apporte AUCUNE sécurité.

      L'intégrité repose sur une fonction de hachage. Il n'y a aucun secret dans la fonction (MD5 en général) et donc aucune sécurité. La seule et unique propriété apportée par ces fonctions, c'est de permettre de détecter un changement.

      Or, suppose que le serveur ait été piraté et que le méchant pirate ait remplacé l'archive .tgz des sources. On peut penser que le type n'est pas trop con et qu'il aura fait un :
      $ md5sum mon_archive_trojanée_à_moi.tgz > MD5SUM
      et roule ma poule, personne n'y voit rien.

      Dans ce cas, on peut détecter l'erreur en comparant les MD5 distribués sur différents serveurs ... mais même ça ne constitue aucunement une assurance que l'archive récupérée est saine. Il se pourrait que le serveur principal soit corrompu, puis tous les mirroirs, et dans ce cas, personne ne voit plus rien.

      Bref, le haché (md5 ou autre) permet simplement de vérifier que le téléchargement s'est bien passé.

      La seule solution est d'utiliser une signature cryptographique. C'est le seul moyen de garantir que tout est sain.

      • [^] # Re: intégrité des sources : pourquoi faire ?

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

        vi faut signer les sources avec gpg !
        d'ailleurs il faut aussi signer, et mieux, crypter vos mails avec gpg... ca vous évitera de vous faire usurper... et espionner ;)

      • [^] # Re: intégrité des sources : pourquoi faire ?

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

        > La seule solution est d'utiliser une signature cryptographique. C'est le seul moyen de garantir que tout est sain.
        Ceci dit les packages de type rpm ou deb intègrent la notion de signature cryptographique. C'est vrai que pour les tarballs c'est plus chiant à vérifier car faut se trimballer un fichier "à part" avec un sceau, un checksum, enfin bref un bidule qui te permet de vérifier que ça vient bien de la bonne personne. Moi je trouverais personnellement ça sympa d'avoir une option "--sign" dans tar. Mais bon rajouter ce type d'extension sur un programme antique comme tar, c'est pas une mince affaire. Mais je reste convaincu que ça serait bien.

      • [^] # Re: intégrité des sources : pourquoi faire ?

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

        toutafe.
        cela dit pour les precedentes failles de ce type les pirates n'avaient pas update le md5 je crois...

        (m'enfin c'est vrai que le md5 napporte rien cote securite. depuis la faille de irssi les tarballs sont signes avec la cle gpg de son auteur, reste a esperer que le maximum de developpeurs fassent ca...)

      • [^] # Re: intégrité des sources : pourquoi faire ?

        Posté par  . Évalué à 1.

        Le md5sum du site d'origine est seul à faire foi évidemment...
        Quand à la signature cryptographique -oui, c'est plus sain - je crois que les distributions modernes font ça non ?

        • [^] # distributions

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

          > Le md5sum du site d'origine est seul à faire foi évidemment...
          sauf si le serveur principal est corrompu : aucun md5sum n'est fiable ;-)

          > je crois que les distributions modernes font ça
          Les rpms sont signés (depuis longtemps) mais pas les .deb
          Pour les .deb, la politique sera probablement de signer un fichier contenant les md5sums des packages. Mais il n'y a rien pour le moment.

          • [^] # Re: distributions

            Posté par  . Évalué à 2.

            Quand on construit un paquet, on doit déjà signer le .diff.gz et .dsc.
            Simplement, apt pourrais demander la vérification de la clé GPG,
            mais il faudrait un serveur de clés publiques sûr qui contiennent les clés de tous les développeurs debian.
            Ce n'est pas parce que les paquets sont signés que les moyens de vérifier la signature sont mis en place pour autant...
            Et c'est valable pour les rpms: comment vérifier la clé ?

            • [^] # Re: distributions

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

              dans la mdk, le package gnupg integre les clefs des developpeurs, donc c'est deja près.

            • [^] # Re: distributions

              Posté par  . Évalué à 2.

              Et c'est valable pour les rpms: comment vérifier la clé ?

              pour les distros, sur les CDs, il y a un fichier RPM-GPG-KEY (qu'on retrouve d'ailleurs après l'installation à des endroits divers selon les distros).
              ensuite on fait un gpg --import du fichier en question en tant que root, et le tour est joué (sur certaines distros, cette dernière étape est faite par l'installeur)

              pour le cas d'un RPM qui vient d'une source x ou y c autre chose...
              mais PLF, Freshrpms, et deux trois autres sites du meme genre fournissent leur clés.

            • [^] # Re: distributions

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

              apt-get install debian-keyring

  • # vous trouvez pas ca bizarre ?

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

    vous trouvez pas ca bizarre vous, que ce genre de trojan fleurissent depuis l'annee derniere (ils existaient avant mais il yen a eu beaucoup plus depuis un an je trouve) ? je trouve ca plutot louche moi... je nirais pas jusqu'a dire que ca serait des maneuvres d'un quelquonque concurrent, mais c'est qd meme bizarre...

    • [^] # Re: vous trouvez pas ca bizarre ?

      Posté par  . Évalué à 1.

      Il faut aussi prendre en compte le fait que le logiciel libre devient de plus en plus populaire. De ce fait il attire tant les bonnes âmes que les mauvaises. Et un "black hat hacker" peut aussi s'y intéresser. Ce genre de personnes m'insupportent d'ailleurs au plus haut point. Je crois que la meilleure façon de se prévenir de telles choses reste la communication à outrance afin de limiter tant que possible la diffusion des failles et autre joyeusetés déjà détectées.
      Bon, de là qu'il y ait un concurrent qui soit là dessous, il y a encore un gros pas. Et il ne faut pas le franchir. Que dirait-on si MS affirmait que c'est le logiciel libre qui crée des failles sous windows ... ? Peu crédible, n'est-ce pas? Ils se débrouillent déjà très bien à créer leurs problèmes tout seul. ;-)

      • [^] # Re: vous trouvez pas ca bizarre ?

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

        vi, je ne dis pas que c'est un concurrent. mais ca pourrait tres bien etre un illumine de la cause du proprietaire :)
        tous ces trojans nous decredibilisent (cf les differents articles passes sur linuxfr comme quoi l'open source c pas si secure que ca, linux c'est plein de virus, etc... qui comme par hasard arrivent comme des mouches dans le meme temps...) ...

        l'autre point, c'est que ces failles se ressemblent. je ne serais pas etonne d'apprendre que c'est la meme personne ou le meme groupe de personnes derriere la plupart...

        • [^] # Re: vous trouvez pas ca bizarre ?

          Posté par  . Évalué à 1.

          De ce point de vue ce n'est pas impossible. Il y a des extrémistes de tous les côtés malheureusement.
          D'un autre côté, il ne faut pas dramatiser. Si on compte (de façon objective) le nombre de troyens et autres qui sont créés chaque année, je ne pense pas que le logiciel libre soit mal placé. (quelqu'un a des liens sérieux?) Et puis surtout dès que la faille est découverte, on a rapidement un correctif. Bon enfin, mis à part quelques cafouillages dans le passé il me semble. (cf. Apache pour je ne sais plus qu'elle faille)

          • [^] # Re: vous trouvez pas ca bizarre ?

            Posté par  . Évalué à 1.

            Avec le logiciel libre, les chevaux de troie, on les repère, et on les enlève, et ce ne sont pas les développeurs qui les mettent.

            Avec le logiciel proprio, les développeurs peuvent mettre des chevaux de troie, et personne ne le sait sinon (ou du moins pas en regardant le code qui n'est pas disponible). et meme en le sachant, il est quasi impossible de l'enlever.

            • [^] # Re: vous trouvez pas ca bizarre ?

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

              Cette vision est un petit peu manicheenne non ? Developpeurs LL = gentils, Developpeurs Proprietaires = mechants.

              De mon point de vue, la difference entre Developpeurs LL et Developpeurs Proprietaires se situe au niveau du contrat de travail : pour les premiers, le contrat se resume (le plus souvent) a une confiance mutuelle, pour les seconds, il s'agit de monaie, sonnante et trebuchante.

              Si un Developpeur Proprietaire introduit un cheval de troie, c'est qu'il est paye pour, c'est a dire que c'est un choix strategique que sa hierarchie a fait (a moins qu'il souhaite veroller le produit sur lequel il bosse, mais la je pense qu'il risque gros le type, genre faute professionnelle). Donc, si c'est un choix strategique, je vois mal comment il est possible de l'enlever (vu que les sources sont cachees, et tout et tout).

              • [^] # Re: vous trouvez pas ca bizarre ?

                Posté par  . Évalué à 1.

                je n'ai pas dit que les développeurs de LL étaient gentils et ceux du proprio méchants. Les développeurs de LL ne mettent pas de chevaux de troie parce que ça se repère tout de suite, voilà tout.

                • [^] # Re: vous trouvez pas ca bizarre ?

                  Posté par  . Évalué à 1.

                  Faudra m'expliquer comment tu fais pour repérer immédiatement du code suspect dans une application comme KDE qui doit faire quelques centaines de milliers de lignes de code.

                  • [^] # Re: vous trouvez pas ca bizarre ?

                    Posté par  . Évalué à 2.

                    Allons, fait des efforts.

                    Il ne fallait pas comprendre Pierre-Henri dans le sens « je lance KDE et paf je lis le source et je vois un cheval » mais dans le sens « quelqu'un, un jour remarque un phénomène suspect : son logiciel est libre, il peut gratter et trouver l'évidence, la preuve accablante de l'existance d'un cheval de troyes ; son logiciel est propriétaire, il peut avancer à l'aveuglette et finalement faire des hypothèses ... »

                    Mieux : son logiciel est libre, il peut contacter ses auteurs, alerter des gens (linuxfr et équivalents), parmi lesquels il se trouvera bien une personne pour dévoiler le pot aux roses ; son logiciel est propriétaire, contacter ses auteurs ne sert à rien et alerter des gens est sans aucun impact...

                • [^] # Re: vous trouvez pas ca bizarre ?

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

                  Mouais, je me rapelle de trucs qui ont été découvert largement moins vite que dans le cas présent. Et qui pourtant étaient "simple" à voir puisque il suffisait de faire des checksum ou de voir que ca ouvrait un socket tcp/ip au configure.

                  Si le gentil développeur planque une backdoor un peu évoluée (mieux planquée que "je fais une requete web à chaque compile") dans un programme type gnome ou meme mozilla (dans une partie peu sujette à changements et peu interressante), je ne suis pas sur que ca se repere si vite, mais alors pas sur du tout

                  Le "vous avez le source alors vous pouvez avoir confiance" est vrai en théorie mais moi (comme à peu pres tout le monde) je n'ai pas le temps (et pas forcément la compétence) de faire un audit sérieux sur tout ce que j'installe (OS compris). Du coup le fait d'avoir les sources ne me rajoute _aucune_ sécurité.
                  En pratique les gens font confiance à la personne qui leur délivre les sources ou le binaire pour connaitre le code source. Souvent c'est leur distrib, des fois le site officiel.

                  Mais pour tous ces gens qui ne font pas un audit _sérieux_ de tout ce qu'ils installent avoir les sources ne leur rajoute _aucune_ sécurité. Ils ont à faire confiance (de la meme facon que celui qui télécharge un binaire sans source)

                  • [^] # Re: vous trouvez pas ca bizarre ?

                    Posté par  . Évalué à 1.

                    « Mais pour tous ces gens qui ne font pas un audit _sérieux_ de tout ce qu'ils installent avoir les sources ne leur rajoute _aucune_ sécurité. Ils ont à faire confiance (de la meme facon que celui qui télécharge un binaire sans source) »

                    Dans les deux cas, il y'a la confiance :
                    - dans le premier, il s'agit de confiance en l'auteur des sources qui pourraient etre démasqué finalement assez rapidement, par hasard ; il s'agit aussi de voir que d'autres personnes que soit (des organismes d'audit par exemple) pourrait vérifier les sources
                    - dans le premier, il s'agit de confiance en l'auteur des sources contre qui il ne pourra rien etre prouvé sinon un "problème" (bug ou fonctionnalité) ; il s'agit aussi de voir que de toute façon, personne ne peut lire les sources. Pas nous, qui ne le faisont pas, mais personne d'autre : on est tous confiné à ne pas faire d'audit sérieux.

                    Dans les deux cas, il est possible de se faire tromper. Mais dans un des deux cas, on ne peut avoir aucune garantie...

                    Alors que dans l'autre, _si on veut_ on peut.

                  • [^] # Re: vous trouvez pas ca bizarre ?

                    Posté par  . Évalué à 1.

                    si on veut, on peut : c'est la liberté en informatique...

    • [^] # Re: vous trouvez pas ca bizarre ?

      Posté par  . Évalué à 2.

      Disons plutôt que c'est la mode, c'est tendance chez les naxors...
      Un peu comme les LoveLetter, ILoveYou, annakournikova et autres vers en 2000...

    • [^] # Re: vous trouvez pas ca bizarre ?

      Posté par  . Évalué à 0.

      ce genre de trojan fleurissent depuis l'annee derniere
      Il semble donc que beaucoup de serveurs FTP UNIX (comme SUNSITE qui était sous Solaris) soit mal administrés.

      je nirais pas jusqu'a dire que ca serait des maneuvres d'un quelquonque concurrent, mais c'est qd meme bizarre...
      Tu fait allusion à Microsoft (au passage je crois que c'est surtout Sun qui perd de l'argent à cause de Linux)
      Tu raconte vraiment des conneries plus grosses que toi.

      • [^] # Re: vous trouvez pas ca bizarre ?

        Posté par  . Évalué à -3.

        Pas si crétin que ca !
        N'oublions pas que Microsoft (enfin! steve ballmer) avait parler d'un combat avec le logiciel libre autre que sur celui avec lequel ils usaient auparavant.
        Il ne parlait pas aussi d'un combat sur la crédibilité ?
        cela pourrait expliquer cela.... on s'attaque sur un autre terrain !

        • [^] # Re: vous trouvez pas ca bizarre ?

          Posté par  . Évalué à 1.

          Voui, MS a recruté des hackers pour décridibiliser le logiciel libre. Bon, à part ça, ça va bien chez vous ?

          • [^] # Re: vous trouvez pas ca bizarre ?

            Posté par  . Évalué à 0.

            j'ai jamais dit ca !
            Steve Ballmer avait bien dit qu'il fallait "s'attaquer" aux logiciel libres sur un autre terrain...
            Pourquoi ne pas s'interroger ?
            Et puis après tout, MS a utilisé bien pire dans le passé !
            Plus rien ne m'étonne maintenant !

      • [^] # Re: vous trouvez pas ca bizarre ?

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

        relis moi.
        je dis justement que je n'irais pas jusqu'a dire ca.

    • [^] # Les trojans sont des l'intérêt de microsoft

      Posté par  . Évalué à -1.

      C'est que c'est pas fous
      tout les unix profite des ligiciels libre, mais Microsoft n'a pas aucun avantage à ce que Linux gagne encore plus en crédibilité.

      Pourquoi ne pas penser que Microsft engagerait pas des gens pour hacker les logiciels libres et leur faire du tors.

      Bon en espérant que ce commentaire n'entraine pas un poursuite de Microsoft.

      • [^] # Re: Les trojans sont des l'intérêt de microsoft

        Posté par  . Évalué à 1.

        Surtout que ces hackers seraient dans ce cas beaucoup mieux employés à améliorer les produits microsoft :-)

      • [^] # Re: Les trojans sont des l'intérêt de microsoft

        Posté par  . Évalué à 3.

        Pourquoi ne pas penser que Microsft engagerait pas des gens pour hacker les logiciels libres et leur faire du tors.
        Bon en espérant que ce commentaire n'entraine pas un poursuite de Microsoft.
        Franchement, vous trouvez pas ça un peu gamin de dire des conn@#! sur Microsoft ? Ou alors c'est du second degrés ?
        tout les unix profite des ligiciels libre, mais Microsoft n'a pas aucun avantage à ce que Linux gagne encore plus en crédibilité.
        A mon avis Linux, dérange plus SUN Microsystem que MS.

        Un serveur SUN bipro SPARC à 450 Mhz E250 coûte 80000 Frs, même si les E/S sont plus rapides que c'est un serveur pro... compare ça avec le prix d'un serveur NT/BSD/Linux.
        A ton avis pourquoi le patron de SUN s'est déguisé en pingouin devant les analystes ? Ils lui mettent la pression ...

      • [^] # Re: Les trojans sont des l'intérêt de microsoft

        Posté par  . Évalué à 9.

        Perso en te lisant je me dis qu'il vaudrait mieux que MS te paie une visite chez un psy qu'intenter des poursuites.

        Tu sais, n'oublie pas que tu es un supporter du libre, si demain tu traverse la route et qu'un type en voiture manque de te shooter, c'est que c'est probablement un tueur a gage paye par MS pour eliminer les supporters du libre.

        D'ailleurs le yahourt perime qui etait dans ton frigo hier, c'est nous aussi, on l'a plante la pour que tu choppes une diahree d'enfer et que tu puisses plus coder de logiciels libres pendant 3-4 jours.

        • [^] # Re: Les trojans sont des l'intérêt de microsoft

          Posté par  . Évalué à 0.

          Non, je suis pas fou,
          je lance juste une idée comme ça

          c'est sûr qui a des petits malin qui font des conneries juste pour s'amuser

          • [^] # Re: Les trojans sont des l'intérêt de microsoft

            Posté par  . Évalué à 0.

            > non, je suis pas fou
            Ben tu dois être un grand utilisateur de certaines drogues illicites plus fortes que le shit, alors. Et ton fournisseur est sacrément bon, n'hésite pas à lui dire que son produit permet même d'aller poster des conneries sur un site web.

      • [^] # Les trolls aussi.

        Posté par  . Évalué à 1.

        Pourquoi ne pas penser aussi que Microsoft engagerait pas des gens pour troller sur Linuxfr et faire passer les Linuxiens pour des paranoïaques ?

        C'est bon, je connais la sortie. ====>[]

  • # Re: Cheval de Troie découvert dans la libpcap et tcpdump

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

    Mouais, les signatures GPG et MD5 vont etre les solutions données mais ....

    Faut pas oublier que si il y a eu probleme c'est que les machines sont trouées à la base. si au lieu de modifierl'archive le malin modifie un fichier peu usité dans le CVS (à la main, donc sans que ca se voit en regardant la date de derniere modif) l'archive sera belle et signée comme il faut. On aura l'air malin avec nos signatures GPG (à moins que vous ne vouliez signer chaque ajout CVS ?)

    Bref, à la base le probleme n'est pas tant les signatures (ca ne ferait que déplacer l'emplacement ou les méchant interviendront) mais bien des machines trouées

    • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

      Posté par  . Évalué à 4.

      Et là, le passé a démontré qu'aucun système aussi poussé sur la sécurité qu'il soit n'est rien si l'administrateur ne suit pas...
      Je rappelle que certains serveurs ftp sous OpenBSD (!) ont permis la diffusion de ce genre d'exploits (irssi, par exemple)...
      Alors que ce soit sous GNU/Linux, OpenBSD ou Solaris, peu importe...

    • [^] # Re: Cheval de Troie découvert dans la libpcap et tcpdump

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

      Ce n'est normalement pas la meme machine qui fait server FTP et CVS. :-)

      Cepedant si le serveur CVS n'imposse pas ssh, une ecoute attentive doit permettre d'obtenir l'access. :-(

      Finalement, ca me rassure pas beaucoup

  • # Question très bête...

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

    Dans le cas de tcpdump comme dans celui d'OpenSSH, le cheval de Troie va chercher un script sur une machine sur le réseau, et se connecte sur cette machine pour ouvrir un shell. Cette machine appartient à une société finlandaise. De deux choses l'une, soit c'est un membre de cette entreprise qui a fait mumuse, soit (plus probable) ils se sont fait h4x0r. Il serait peut-être temps d'intenter des actions en justice, pour que (par exemple) les logs de cette machine soient passés au peigne fin. Ceci n'empêchant pas de demander poliment, bien entendu.
    Pour aller plus loin, quand on découvre ce genre de choses, ne vaudrait-il pas mieux directement intervenir à ce niveau AVANT de divulguer la faille ?

    • [^] # Re: Question très bête...

      Posté par  . Évalué à 1.

      Le fait est qu'à l'heure qu'il est, la machine en question ne doit plus avoir bcp de logs visibles... :/

      • [^] # Re: Question très bête...

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

        En y mettant les moyens, on doit pouvoir les retrouver sur le disque dur même si d'autres logs ont été récrits dessus.

        • [^] # Re: Question très bête...

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

          Un bon truc pour se prévenir de ce genre de problèmes critiques (effacement des logs par un rootkit) est d'envoyer (par mail par exemple) à intervalles réguliers un petit diff des derniers changements sur certains fichiers de log. Tu envoies ça sur une machine qui n'a rien à voir avec la machine protégée. Par exemple un compte hotmail, ta boîte perso relevée par ton ordi personnel, bref, un truc complètement différent. Ainsi, le mec pourra te pourrir ta machine de production, pour effacer toutes traces de log, faudra qu'il aille hacker hotmail, ton ordi qui est sur l'ADSL, etc... Si t'es parano tu peux crypter les diff avec gpg. Ce type de méthode est un peu lourdingue (faut pas oublier de relever la boîte mail avant qu'elle explose), mais c'est pas mal pour garder une trace indélébile.

          • [^] # Re: Question très bête...

            Posté par  . Évalué à 2.

            A mon avis, ca c'est pas tres utile.

            Il faut definir "intervalle reguliers".
            Si on prend toutes les 15 minutes par exemple,
            ca laisse (au mieux) 15 minutes au cracker pour nettoyer les logs...
            et le diff ne contiendra rien. Sinon il peut commencer par supprimer ta moulinette .... et la réactiver après son passage... ou la remplacer par une moulinette de son cru qui envoie des difff "epurés" a la volée de toutes traces de son passage.


            LA METHODE : syslog supporte de facon native l'envoi de log a une machine reseau (man syslog). utiliser cette methode pour envoyer le log sur une machine sur laquelle AUCUN port autre que syslog n'est ouvert (pour eviter de se la faire haxoriser aussi), voir mettre un firewall entre les deux ...

            • [^] # Re: Question très bête...

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

              > Il faut definir "intervalle reguliers".
              5 min c'est déjà franchement fin. Entre le moment où le mec commence à s'intéresser à ta machine, et le moment où il a eu le temps d'effacer les logs, 5 min c'est court. C'est court évidemment si le mec fait tout à la main. C'est long s'il utilise un script qui fait tout automatiquement. Mais s'il utilise un script, il y a peu de chances que celui-ci détecte que ton script fait-maison existe. Le type s'en apercevra s'il fait une analyse *manuelle* du bidule. Qui dit manuel dit opération couteuse en temps. Enfin c'est mon avis.

              > sur une machine sur laquelle AUCUN port autre que syslog n'est ouvert
              En fait pour revenir à mon idée de départ, le point important était de dupliquer des infos sur une machine qui n'a *rien à voir* avec le réseau en train d'être cracké. Si le type est rentré sur la machine A grâce à une faille de sécurité, il se peut qu'il rentre sur la machine B sans problème si la machine est administrée par la même personne. Aucun admin n'est infaillible. Par contre en dupliquant les logs sur une machine complètement externe, le type doit tout se retaper depuis le départ, dans un contexte à priori différent.

          • [^] # Re: Question très bête...

            Posté par  . Évalué à 2.

            Ou de rediriger les logs vers une imprimante matricielle...

    • [^] # Re: Question très bête...

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

      Est-ce que cela peut aider :
      http://www.nongnu.org/myam/(...)

      Sinon, il n'existe pas des filesystems qui ne supporte pas l'effacement juste le append et la création ? (on pourait imaginer un passwd différent de root pour changer sa configuration, ce qui ne doit pas arriver tous les jours)

      "La première sécurité est la liberté"

      • [^] # Re: Question très bête...

        Posté par  . Évalué à 1.

        Sinon, il n'existe pas des filesystems qui ne supporte pas l'effacement juste le append et la création ?

        Si, en Ext2/Ext3 tu peux mettre des attributs spéciaux avec "chattr", regarde le man. En gros, tu peux le rendre "immutable" (non modifiable ni effaçable), ou "append only". chattr permet d'autres réglages.

        Le pb c'est qu'une fois root, on peut avec chattr remettre le fichier en fonctionnement normal. Donc un serveur craqué est un serveur craqué. A moins d'imaginer un FS qui permet les fichiers vraiment totalement ineffaçables, y compris par root. Mais comment on fait après pour les virer quand ils grossissent trop ?

  • # Thanks to Gentoo

    Posté par  . Évalué à 2.

    En parlant de système de packages, c'est gràce à portage que le trojan a été découvert. En effet celui-ci vérifie systématiquement les checksums des fichiers téléchargés dans sa base. <troll>Gentoo 1 Debian 0 </troll> ;)

    Thanks to Antioffline.com for hosting us, and Gentoo's Portage system for catching the trojaned files via checksums.

    • [^] # Re: Thanks to Gentoo

      Posté par  . Évalué à 2.

      J'aime bien cette page intitulée Maintenance facile et sécurisée d'un système Debian GNU/Linux avec apt ou [...] comment configurer debian pour:
      • Avoir en permanence la liste complète et sécurisée(signée) de tous les packages officiels disponibles (stable, testing et unstable)
      • Mettre à jour automatiquement les packages de stable, y compris les mises à jour signées de security
      • Installer certains packages de testing et s'assurer qu'ils seront mis à jour par la suite (sans toucher aux packages de stable)
      • Installer certains packages de unstable et être informé de la disponiblité de mises à jour de ces packages

      La dite page est là http://free2.org/d/(...)

      Et la news ici http://linuxfr.org/2002/08/23/9368.html(...)

Suivre le flux des commentaires

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