Journal Intrusion sur les serveurs Fedora/Red Hat

Posté par (page perso) .
Tags : aucun
5
23
août
2008
Le 14 août les administrateurs des serveurs de Fedora ont envoyé un message indiquant qu'ils avaient détecté un problème sérieux et qu'ils étaient en cours d'investigation à ce sujet : http://lwn.net/Articles/294188/

Dans l'intervalle ils conseillaient de ne pas télécharger le moindre paquet : "as a precaution, we recommend you not download or update any additional packages on your Fedora systems".

Evidemment une telle annonce fait immédiatement penser à un grave problème de sécurité et les utilisateurs de Fedora se sont senti inquiets. L'attente a donc commencé pour avoir des détails sur ce problème.

Le 16 août nouveau mail de Fedora indiquant que les administrateurs étaient toujours au travail et demandant aux utilisateurs de prendre leur mal en patience : http://lwn.net/Articles/294324/

"The Fedora Infrastructure team continues to work on the issues we discovered earlier this week (...) Please be patient as we continue to work the problem".

A partir de là les spéculations les plus folles ont commencé à courir. Si cela prenait autant de temps c'est qu'il s'agissait vraisemblablement d'un souci très grave et le pire était à envisager. L'exaspération a commencé à monter chez certains utilisateurs qui voulaient avoir plus d'informations pour évaluer la vulnérabilité de leurs systèmes. Le fait de savoir qu'une grosse merde à du arriver et de ne pas avoir le moindre détail à ce sujet est particulièrement frustrant.

Le 19 août encore un mail des admins de Fedora : http://lwn.net/Articles/294547/

Toujours pas le moindre détail et le "conseil" de ne pas télécharger de paquets est toujours valable.
Le mail demande à la communauté des utilisateurs d'attendre que tout soit revenu à la normale : "Please give the infrastructure team the time they need to do this demanding work (...) We know the community is awaiting more detail on the past week's activities and their causes. We're preparing a timeline and details and will make them available in the near future. We appreciate the community's patience, and will continue to post updates to the fedora-announce-list as soon as possible".

Les commentaires continuent de fuser au sujet de la probable compromission des serveurs. Si les admins mettent autant de temps c'est que la faille doit être importante. Est-ce spécifique à Fedora ou est-ce que les autres distributions sont touchées ? Des paquets trojanés ont-ils été distribués par un pirate ? Peut-être est-ce juste un problème matériel sur les serveurs et pas une brèche de sécurité ? Ou alors une invasion d'extra-terrestres ?

Enfin le 22 août un mail sur la liste de diffusion Fedora-annonce donne les détails et met fin à cette interminable attente : http://lwn.net/Articles/295134/

Une intrusion a bien eu lieu sur les serveurs de Fedora et aussi sur ceux de Red Hat !
Le pirate a pu signer des paquets et Red Hat a sorti un bulletin d'alerte de niveau "Critical" : http://rhn.redhat.com/errata/RHSA-2008-0855.html

Dans cette alerte on lit la phrase suivante qui fait froid dans le dos : "In connection with the incident, the intruder was able to sign a small number of OpenSSH packages".

Il semble toutefois que ces paquets ont seulement pu être signés mais n'ont pas été distribués aux utilisateurs du canal de distribution officiel Red Hat.
En ce qui concerne Fedora l'un des serveurs compromis contenait la clé de signature des paquets de la distributions mais les investigations n'ont pas pu mettre en évidence de compromission de cette clé de signature : "we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key".

Par mesure de sécurité la clé a été changée et les paquets ont été vérifiés sans que le moindre cheval de Troie ne soit détecté. Les utilisateurs peuvent maintenant reprendre leurs mises à jour et leurs téléchargements : "At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages".

Bien entendu CentOS, qui est basé sur Red Hat, a investigué de son coté : http://lwn.net/Articles/295221/
D'après les administrateurs il n'y a pas eu de problème : "We can now assure everyone that no compromise has taken place anywhere within the CentOS infrastructure".

Donc au bilan qu'avons nous ?

1) Une intrusion sur les serveurs de Fedora et Red Hat. C'est horriblement inquiétant et il faut absolument savoir comment cela a pu se produire. Pour l'instant aucune info n'est disponible à ce sujet. Est-ce une erreur humaine ou une faille technique ? Si c'est un bug est-il générique à Linux ou spécifique aux serveurs compromis ?

2) Le pirate a réussi a signer le paquet OpenSSH de Red Hat mais, à priori, il n'a rien pu faire de plus. Ni compromettre le paquet, ni le distribuer. A noter que cette absence de distribution ne vaut que pour le canal officiel Red Hat et pas pour des dépôts tiers. Il faudra là aussi attendre pour avoir plus de détails.

3) La rétention de l'information a été parfaite de la part de Fedora/Red Hat. Aucune info n'a fuité avant l'annonce officielle et les admins de la distribution ont pu enquêter sans qu'il y ait une folie médiatique autour d'eux. La contrepartie étant le bouillonnement des spéculations pendant plus d'une semaine et l'incertitude des utilisateurs sur la sécurité de leurs systèmes.

Au final je pense que cette chaude alerte pourrait être bénéfique dans la mesure ou elle incitera sans doute les distributions Linux à renforcer leurs mesures de sécurité. La facilité d'installation des logiciels sous Linux, du fait de l'existence des dépôts centralisés, à une contrepartie : Les serveurs hébergeant ces dépôts doivent être des forteresses !
  • # Diversité, diversité :)

    Posté par (page perso) . Évalué à 4.

    Merci Patrick pour cette excellente news, comme il se doit.

    À nouveau, on voit que la diversité des distributions et des canaux permet d'assurer une sécurité généraliste, qui évite les failles à la Microsoft ou 90% du parc mondial est concerné d'un coup ...

    N'ayant aucune RedHat/Fedora dans mon parc, me voilà rassuré.

    Par contre je pense à une chose : la sécurité de ces dépôts reste, elle, bel et bien centralisée.

    Ne serait-il pas une bonne idée de confier une verification tierce de signatures à un tiers indépendant des distribution, genre X s'occupe de vérifier que chaque changement de signature d'un package de la distribution Y est bien issu du processus industriel de validation, et pas d'un changement sauvage sur les serveurs. X peut alors publier une liste (signée par X) des signatures des packages ayant suivi proprement ce processus industriel (sur Debian, le processus prenant du temps (unstable > testing typiquement) cela peut se vérifier assez facilement, je ne sais pas comment on pourrait faire sur les autres distribs.)
    • [^] # Re: Diversité, diversité :)

      Posté par . Évalué à 0.

      > N'ayant aucune RedHat/Fedora dans mon parc, me voilà rassuré.

      Mouaif. Vu le faible niveau d'information donné par Fedora/Red Hat, ont peut aussi penser que c'est un problème upstream (période d'embargo). Et dans ce cas tu es aussi en "danger".

      > Par contre je pense à une chose : la sécurité de ces dépôts reste, elle, bel et bien centralisée.

      La signature est (forcément) centralisée.

      > Ne serait-il pas une bonne idée de confier une verification tierce de signatures à un tiers indépendant des distribution,

      Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.

      > genre X s'occupe de vérifier que chaque changement de signature d'un package de la distribution.

      Il n'y a pas eu de changement de signature, il y a eu abus de l'infrastructure pour signer les paquets avec la signature de Fedora / Red Hat.
      • [^] # Re: Diversité, diversité :)

        Posté par (page perso) . Évalué à 3.

        > On peut penser à un problème d'upstream

        Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique

        Donc non, pas d'inquiétude côté upstream apparemment

        > Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.

        Peut-être, mais même si elle connaît seule les paquets, toute organisation est finalement monolithique.

        Pour cette idée de la vérification de signature, je signalais juste qu'il était possible de mettre en ligne une copie (donc sur des serveurs non gérés par la distribution) des signatures de packages, copie elle-même signée par un tiers (celui qui gère ces serveurs hors distribution), copie qui ne mettrait à jour sa signature locale d'un package que lorsque celui-ci a été observé par un humain (de la même organisation qui gère ces serveurs hors distribution) et que l'humain à constaté que cette mise à jour a été annoncée d'une manière ou d'une autre : soit sur les listes de sécurité de la distribution, soit via le processus habituel (genre le développeur qui renseigne proprement un changelog, le patch associé, le mail sur la liste devel etc.)

        D'ici à ce qu'un pirate puisse passer ce _processus_ qui fait finalement appels aux habitudes de la communauté, il faudra de véritables bourdes majeures, et cela peut donc rendre plus robuste l'infrastructure de distribution.

        Cela reprend le classique paradigme : pirater un système au hasard est très facile, pirater un système particulier infiniment plus difficile.

        Donc pirater un jour quelque chose dont il advient qu'il s'agit d'un serveur principal de distribution, c'est une chose, pirater ensuite l'infrastructure tierce qui co-valide les signatures, c'est une toute autre paire de manches.
        • [^] # Re: Diversité, diversité :)

          Posté par . Évalué à -1.


          Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique


          Sauf que tout cela se passe en privé sur des mailling list privés, et il est interdit à ceux qui sont sur ces listes de rendre publique les failles qui y sont discutées avant la date prévue (si ils veullent pouvoir rester sur la liste).

          Donc il pourrait très bien y avoir un probleme sur un logiciel upstream sans qu'on soit encore au courant.
          • [^] # Re: Diversité, diversité :)

            Posté par . Évalué à 2.

            > Sauf que tout cela se passe en privé sur des mailling list privés, et il est interdit à ceux qui sont sur ces listes de rendre publique les failles qui y sont discutées avant la date prévue

            "Interdit" est trop fort. C'est très très mal vu. Les personnes raisonnablent ne feront pas ça. Ceux qui s'y risquent seront probablement bânis de la mailing.
            Par contre Fedora est sous la responsabilité de Red Hat et Red Hat est une boite américaine. Donc Red Hat a des obligations légales (respecter DMCA entre autre).
            • [^] # Re: Diversité, diversité :)

              Posté par . Évalué à 4.

              Par contre Fedora est sous la responsabilité de Red Hat et Red Hat est une boite américaine. Donc Red Hat a des obligations légales (respecter DMCA entre autre).

              Le truc c'est surtout que Red Hat est côté en bourse, ils ont donc des obligations légales pour les façons de délivrer des informations.
  • # CERTA ...

    Posté par . Évalué à 4.

    Pour compléter ta news, je vous conseille de lire l'article du certa :

    http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-428/index.h(...)

    Je conseille à tout le monde de tester leurs systèmes avec le script fourni.
    • [^] # Re: CERTA ...

      Posté par (page perso) . Évalué à 0.

      Tiens c'est amusant, je n'avais pas remarqué que cet advisory corrige aussi le CVE-2007-4752. C'est un peu confusant : en lisant l'annonce du CERTA on se dit qu'il y a quelqu'un qui n'a rien compris mais en fait il y a un petit paragraphe là dessus dans le RHSA.

      Au final cette correction est peut-être plus utile aux utilisateurs que la release du paquet juste pour incrémenter le numéro de version.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: CERTA ...

        Posté par . Évalué à 3.

        Moui, le CVE-2007-4752 est un problème vraiment mineur (le root d'un serveur distant a déjà, comment dire, beaucoup de droits et d'autres méthodes sous la main pour consulter les sessions x11 en cours).

        Ça explique que Red Hat ne se soit pas trop pressé pour distribuer une mise à jour : le CVE-2007-4752 date d'octobre 2007. Ils ont visiblement attendu d'avoir une vraie raison d'upgrader le paquet pour distribuer ce fix.
  • # deux fois ...

    Posté par . Évalué à -6.

    C'est la deuxième fois qu'OpenSSH a un problème de sécurité (ok la premiere fois etait différente , c'était à cause de la génération de clé pas tellement aléatoire que ca ) Ca doit néanmoins être un indicateur du succès d'OpenSSH non ? Selon la formule de Torvalds plus y a de paires d'yeux , plus les bugs deviennent évident .

    Sinon c'est aussi la deuxième (je me trompe ? ) fois qu'il y a intrusion sur les serveurs d'un gros prestataire du libre (il y avait eu la fois avec Debian aussi ) . Mis à part le fait qu'il fut un temps ou Microsoft a clairement dit qu'il allait démontrer que Linux n'est pas invulnérable , a t-on d'autres (trolls) sur la nature , et l'intention de ces black hat ?
    • [^] # Re: deux fois ...

      Posté par . Évalué à 0.

      Je vois déjà les titres des news se propager sur le Net : Black Hat attack Red Hat , Black Hat contre Redhat ...

      :)

      ok c'est pas marrant ------>
    • [^] # Re: deux fois ...

      Posté par . Évalué à 9.

      Rien indique que c'est un problème avec openssh...
    • [^] # Re: deux fois ...

      Posté par . Évalué à 7.

      > C'est la deuxième fois qu'OpenSSH a un problème de sécurité
      La première fois, c'était le paquet Debian d'OpenSSH qui avait un problème, pas OpenSSH lui-même. Cette fois-ci, des paquets d'OpenSSH ont été signés, toujours pas de problème de sécurité dans OpenSSH.

      > Selon la formule de Torvalds plus y a de paires d'yeux , plus les bugs deviennent évident .
      C'est en fait une formule d'ESR (en:The_Cathedral_and_the_Bazaar).
    • [^] # Re: deux fois ...

      Posté par . Évalué à 10.

      Je vois que tu n'a riens compris. Dans les deux cas que tu cite, le problème n'est pas une faille d'openssh.

      Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.

      La raison est très simple : openssh est un logiciel stratégique pour la sécurité, parce qu'il gère l'accès distant et complet au système hôte, et parce qu'il est installé sur une grande majorité de serveurs Unix (je pense que c'est le daemon le plus souvent présent sur un serveur unix, plus encore qu'apache, dovecot ou sendmail). La faille du paquet openssl de Debian affectait, en fait, beaucoup d'autres logiciels (dont OpenVPN par exemple), mais on s'est inquiété en premier lieu de ses conséquences sur openssh précisément pour ces raisons. De même, cette position « privilégiée » d'openssh explique clairement pourquoi ce logiciel a été choisi par le pirate des serveurs Red Hat : même s'il avait la possibilité de générer un binaire trafiqué puis signer n'importe quel paquet inclus dans RHEL (ce qui est probable), openssh restait en toute logique la cible de premier choix.

      Les failles d'OpenSSH sont rarissimes quand on considère son exposition. Et quand elles arrivent, ce sont soit des problèmes de détail aux conséquences mineures (type vol possible d'un cookie xorg par root), soit failles très sophistiquées et complexes, mais jamais de grossières erreurs de programmation. Ce logiciel est développé par les gens d'OpenBSD, qui sont connus pour faire de leur mieux pour essayer d'éviter les problèmes de sécurité, même lorsque c'est aux dépends des fonctionnalités ou des performances. Et c'est certainement l'un des (sinon _le_) logiciels libres les plus audités : autant par les pirates (la découverte d'une faille dans ce logiciel leur assurerais une efficacité maximum), par les consultants en sécurité (une telle découverte leur garantirais une énorme promotion), par les équipes de sécurité des divers distributions et des autres unix (y compris Mac OS, AIX, Cisco, Juniper & co, qui incluent aussi ce logiciel), par les agences gouvernementales type NSA, il fait partis des programmes audités en boucle par coverty, ... C'est aussi un des premiers logiciels a avoir été mis sous la protection/surveillance de SELinux et d'AppArmor (et dans une moindre mesure, de systrace - et il est généralement compilé avec propolice/-fstack-protector), et un de ceux pour lesquels ces outils sont activés par défaut sur plusieurs distributions : un comportement "bizarre" (ie. dû à une faille encore non révélée en cours d'exploitation) dans ce logiciel se remarquerai très vite.

      À mon sens, l'utilisation de serveurs ssh alternatif est moins un gain de sécurité par la diversité qu'un risque dû au manque d'audit intensif de ces derniers (autrement dit, une tentative de sécurité par l'obscurité).

      Plus sérieusement, si vous vous inquiétez d'utiliser des logiciels dont le code est fagile et très régulièrement affecté par des problèmes de sécurité, regardez plutôt du coté de l'historique sécu de PHPMyAdmin ou Clamav (ps: et bravo aux distributions responsables qui ont choisi de ne _pas_ inclure cette passoire de phpmyadmin). Je crois qu'il ne se passe pas un mois sans que je soit obligé d'upgrader ces logiciels dans l'urgence sur certains serveurs...
      • [^] # Re: deux fois ...

        Posté par . Évalué à 1.

        > Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.

        Pour Red Hat/Fedora, pour l'instant on en sait rien. Paul Frields a promis de donner des explications, mais pour l'instant elles ne sont pas la. Il faut attendre.
  • # Re:

    Posté par . Évalué à 5.

    Tout ceci n'est évidemment pas positif. Fedora/Red Hat a pris le problème avec le gros sérieux que demande ce type de situation. Certes certains utilisateurs ont montré de la frustration, mais que je crois que la majorité (souvent silencieuse) comprend que les actions doivent être vigoureuses et la communication gérée avec doigté. Red Hat doit respecter DMCA et si c'est un problème upstream aussi respecté un embargo pour les autres.

    > A noter que cette absence de distribution ne vaut que pour le canal officiel Red Hat et pas pour des dépôts tiers.

    Des paquets ont été signé sur les systèmes Red Hat, mais Red Hat n'est pas sûr que ces paquets ne sont pas sorti de leurs systèmes.
    • [^] # Re: Re:

      Posté par . Évalué à 7.

      que vient faire le DMCA dans cette histoire ? (ceci est une question sérieuse)
      • [^] # Re: Re:

        Posté par . Évalué à 0.

        RedHat est une entreprise américaine et en conséquence elle doit respecté la loi américaine (en l'occurrence doit y avoir une partie sur la sécurité dans cette loi)
      • [^] # Re: Re:

        Posté par . Évalué à 2.

        J'ai oublié les détails.
        En gros DMCA couvre aussi les moyens de protection de donnée et on ne peut pas annoncer une faille sans quelques précautions. Si tu annonces une faille de sécurité et que tu mets en péril significatif des entreprises (ou leurs "oeuvres"), je crois que tu peux tomber sur DMCA.
        • [^] # Re: Re:

          Posté par (page perso) . Évalué à 3.

          En matière de sécurité, mieux vaut communiquer sur les problèmes que laisser les rumeurs le faire à ta place. Même si la loi américaine, notamment DMCA, ne permet à RedHat de préciser la portée du problème de sécurité, la moindre des choses aurait été de le dire.
          De ne pas laisser les utilisateurs dans la panade, l'incertitude, le doute.
          Au lieu de cela, ils parlent simplement d'éviter de mettre à jour des paquets via RHN...
          Et si jamais il y a des failles de sécurité dans d'autres logiciels, on doit attendre la fin de cette période de rétention d'informations ? Faire nous-même les mises à jour ? Non merci.
          À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.
          • [^] # Re: Re:

            Posté par (page perso) . Évalué à 1.

            Au lieu de cela, ils parlent simplement d'éviter de mettre à jour des paquets via RHN...
            Où a-t-il été dit d'éviter de mettre à jour des paquets via RHN ?

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: Re:

              Posté par (page perso) . Évalué à 5.

              Dans l'intervalle ils conseillaient de ne pas télécharger le moindre paquet : "as a precaution, we recommend you not download or update any additional packages on your Fedora systems".
              • [^] # Re: Re:

                Posté par (page perso) . Évalué à 2.

                À ma connaissance, aucun paquet Fedora n'est disponible via RHN. Dans l'intervalle, plusieurs paquets pour RHEL (libxml2, yum-rhn-plugin, postfix) ont été distribués via RHN et je ne vois aucune annonce qui conseille de ne pas télécharger ces paquets.

                pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Re:

            Posté par . Évalué à 6.

            > À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.

            Ne dit pas de connerie.
            Si Fedora/Red Hat n'avait pas dit qu'ils avaient un problème, on en aurait rien su.
            Actuellement on est dans le flou et la communication de Fedora/Red Hat ne le nie nullement et elle demande un peu de patience pour avoir toutes les informations.

            > À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.

            Et que c'est-il passé pour le dernier problème de Debian avec Openssh ?
            Debian a donné l'info dès que Debian à connu le problème ou Debian n'a diffusé l'information que lorsque Debian avait le correctif ? Ben que lorsque que Debian avait le correctif (Dieu merci).

            Red Hat/Fedora doit problème faire exactement ce que fait Debian : confirmer le problème, trouver une solution, voire appliquer un embargo si d'autres distributions ont aussi ce problème.
            Quand Red Hat (qui trouve beaucoup de failles de sécurité) applique un embargo afin que Debian et d'autres ait le temps de mettre à jour, Debian trouve ça très bien.

            > un peu plus transparentes sur leurs problèmes de sécurité.

            Red Hat est transparent. Mais parfois, l'information, pour d'excellentes raisons, n'est pas diffusée de suite.

            Les données "brutes" sur la sécurté de Red Hat :
            https://www.redhat.com/security/data/metrics/
            A titre d'exemple, un rapport sur la sécurité de RHEL 4 (en cherchant on en trouvera d'autres) :
            http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)

            Ce n'est absolument pas moins transparent que Debian (et ses patchs qui ne sont pas séparés...).
  • # Les differences

    Posté par . Évalué à 3.

    1°) On sait qu'il c'est passé quelque chose. Et je suis certain que nous
    sauront tout bientôt.
    Sur d'autres systèmes fermé, rien n'aurait transpiré, et une update parmi
    tant d'autre aurait été faite.

    2°) Tout ce travail fait pour remettre le service en état, communiquer
    etc...
    Ba c'est gratuit.
    Les de telechargement/update serveurs sont rapide, fiable ( a part rare
    cas :) , dont celui ci ).
    C'est gratuit !

    On pourra dire ce que l'on veut ensuite, Debian et la faille OpenSSH,
    Fedora ici, la dernière escalade de droit du noyau, etc, des failles
    peuvent survenir partout, fermé ou ouvert, tout les systèmes sont
    potentiellement vulnerable mais quand même, quand un problème
    survient dans le monde Linux ou BSD, il est résolu (relativement) vite,
    comme pour le monde proprio je pense, mais surtout pour ici c'est gratuit
    et de façon transparente.

    Et ça, c'est super !
    • [^] # Re: Les differences

      Posté par . Évalué à 2.

      Sur d'autres systèmes fermé, rien n'aurait transpiré, et une update parmi
      tant d'autre aurait été faite.


      Je crois pas qu'il y ait un rapport. Ça se passe au niveau de l'infrastructure, pas du code source des logiciels.
      • [^] # Re: Les differences

        Posté par . Évalué à 1.

        Je voulais dire : les logiciels potentiellement infecté aurait été remis à jour.

        Je n'etais effectivement pas clair :)
    • [^] # Re: Les differences

      Posté par . Évalué à 3.

      Qu'est ce que ça peut être désagréable ces commentaires sur 80 colonnes, qui prennent 30 lignes au lieu d'un prendre 15.

      Désolé pour la parenthèse, vous pouvez moinsser je comprendrais.
  • # Les clefs ne sont pas au coffre

    Posté par (page perso) . Évalué à 7.

    Une chose qui m'inquiète: les systèmes de clefs publiques/privées sont faits, justement, pour qu'un serveur piraté ne soit qu'un serveur inutile. C'est fait pour que le pirate ne puisse pas générer de nouvelles signatures ni de nouvelles validations, etc.

    Si dans ce cas le pirate à pu signer des paquets, c'est qu'un serveur accessible sur le réseau contient une clef secrète. Et ça, c'est le vrai problème. Qu'un serveur se fasse pirater de temps en temps, ça arrive (erreur humaine, exploit découvert il y a 10 minutes, intrusion physique, etc). Mais que la clef privée soit sur le réseau, argh, désolé mais pour moi ça ne passe pas. Une signature pour ce genre de chose se passe "hors bande", à partir d'une machine au mieux non reliée au réseau (transfert via disque-dur), au pire reliée avec uniquement des connexions de partage de fichiers (je lis le fichier à signer, je le signe, je place la nouvelle copie sur le serveur).
    • [^] # Re: Les clefs ne sont pas au coffre

      Posté par (page perso) . Évalué à 1.

      Vu le nombre de paquet, je pense que le problème viens de l'automatisation de certaine tache.

      Est-ce que la signature des paquets est une tache automatique ?
      • [^] # Re: Les clefs ne sont pas au coffre

        Posté par . Évalué à 0.

        Il me semble security et unstable chez debian sont signé par une clé passphrase-less, qui est en ligne...
        • [^] # Re: Les clefs ne sont pas au coffre

          Posté par . Évalué à 3.

          Il n'y a que les paquets Rawhide (de la branche de développement quasiment uniquement utilisé par les développeurs/testeurs) qui sont signés automatiquement.

          Le commentaire de la clé et clair :
          $ gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide
          pub 1024D/1CDDBCA9 2003-10-27 Fedora Project automated build signing key (2003) <rawhide@redhat.com>
        • [^] # Re: Les clefs ne sont pas au coffre

          Posté par . Évalué à 3.

          Les paquets Debian sont signés par la clef GPG de la personne ayant uploadé le package. Un package contient les clefs publiques de tous les DD et est mis à jour quand un nouveau Debian Developper est désigné.
          Il n'y a pas à ma connaissance de signature automatisée des paquets.
        • [^] # Re: Les clefs ne sont pas au coffre

          Posté par . Évalué à 3.

          Il me semble security et unstable chez debian sont signé par une clé passphrase-less, qui est en ligne...

          Malgré le moinssage, je persiste, les clés pour signer le release file d'unstable et de security sont sans passphrase, et sur une machine en ligne (les signatures sont automatiques).
  • # Encore une bonne raison...

    Posté par . Évalué à -3.

    pour ne pas vouloir inféoder les serveurs RedHat de sont entreprise à des systèmes de gestion comme RedHat Network...

    Déjà les mises à jour de sécurité compromises, c'est grave, mais imaginons que les serveurs de gestion RHN se fassent hacker, c'est la porte ouverte à combien d'entreprises pour le hacker s'il arrive à forcer la mise à jour sur les machines enregistrées...
    • [^] # Re: Encore une bonne raison...

      Posté par (page perso) . Évalué à 10.

      Et donc toi tu examines manuellement chaque patch avant de l'appliquer sur ta LFS ?

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Encore une bonne raison...

        Posté par . Évalué à 7.

        Figures-toi que dans une entreprise avec un large parc, on essaye de garder le contrôle des mises à jour. On teste, et sur les éléments critiques on fait des tests de non régression avant de prendre le risque de mettre la production par terre.


        Le truc amusant via RedHat Network et sa belle interface, c'est que tu peux pousser directement les mises à jour sur les serveurs que tu gères depuis cette interface qui se trouve sur un serveur web sur internet... un beau risque inutile.

        Dans le cas où les signatures et le serveur RHN sont compromis, l'attaquant peut pousser lui-même les mises à jour sur les machines enregistrées... c'est pas beau ça?

        Inféoder les serveurs de son lan à un serveur sur internet sur lequel on a pas de contrôle, c'est une mauvaise pratique de sécurité.
    • [^] # Re: Encore une bonne raison...

      Posté par . Évalué à 3.

      C'est assez comique, car RHN n'a fournit aucun mauvais paquets. Par contre des serveurs (de Red Hat) ont été compromis et surtout la signature de RHEL a été utilisée. Red Hat ne sait pas si ces mauvais paquets sont sortis de ses serveurs (via un canal différent de RHN).

      Bref, ceux qui n'utilisent que RHN n'ont pas de soucis à se faire...

      Je plussois massivement le commentaire de Krunch ci-dessus.
    • [^] # Re: Encore une bonne raison...

      Posté par (page perso) . Évalué à 3.

      J'espère qu'il y a quelques hackers pour utiliser RHN, surtout maintenant qu'il est quasi complètement en libre (remplacement de Oracle par PostgreSQL) en tant que SpaceWalk http://linuxfr.org/2008/06/21/24241.html

      Après, si tu parlais de crackers, oui cela serait gênant, encore faudrait-il utiliser le bon terme :-).
      Mais en entreprise, les mises à jour se doivent de suivre un processus de suivi des mises à jour : cela évite de casser les applications... ces process sont d'ailleurs souvent un peu trop lourds (planification, tests avec des équipes utilisateur pour la non-régression...) et empêchent les mises à jour de sécurité d'arriver jusqu'à la production (j'ai souvent constaté des serveurs non mis à jour depuis 2005, lors de leur mise en place... bon, ce n'était pas du GNU/Linux).

      Justement, utiliser le RHN c'est avoir l'espoir d'avoir une équipe dont les prérogatives seraient de gérer les mises à jour et (notamment) arbitrer concernant la sécurité : actuellement, j'ai souvent constaté que seules les mises à jour liées à un problème majeur de sécurité sont prises en compte (ne pas toucher à quelque chose qui marche reste la prérogative qui prend le dessus la plupart du temps...).
      • [^] # Re: Encore une bonne raison...

        Posté par . Évalué à 2.

        Plutôt que de tortiller vaniteusement sur les termes à utiliser... ce serait bien de débattre sur la plaque plutôt qu'à côté.

        Mon propos concernait le risque lié au fait que RHN permet de pousser les mises à jour sur les machines inféodées à ce système... risque théoriquement mitigé par la signature cryptographique des paquets.

        Le jour où un rigolo prend le contrôle de RHN ainsi que des mécanismes de signature, ça va faire très mal pour les clients qui auront laissé leurs machines inféodées à RHN.
        • [^] # Re: Encore une bonne raison...

          Posté par (page perso) . Évalué à 3.

          bin franchement, je trouve débile d'avoir toutes les machines qui pointeraient vers un RHN sur Internet, pour moi ça doit pointer vers un satellite server sous _son_ contrôle et qui permet de décider quand je mets à jour le parc (cela permet d'avoir ipso facto un proxy qui éviter de tirer N fois le même paquet d'internet alors qu'on peut l'avoir sur le LAN).

          Après, tu semble omettre ce que j'ai décrit et qui permet (même avec un RHN) de ne pousser que ce que l'on souhaite quand on le souhaite, mais je n'ai pas forcément donné tous les éléments ?
          • [^] # Re: Encore une bonne raison...

            Posté par . Évalué à 2.

            bin franchement, je trouve débile d'avoir toutes les machines qui pointeraient vers un RHN sur Internet

            Vu le prix du satellite, de nombreuses entreprises le font encore...
            RedHat donne le choix entre une solution que tu qualifies toi-même de débile et une solution onéreuse pour un petit parc... même quand on veut juste pouvoir lancer des "yum install" localement, il faut passer par là si on veut avoir les mises à jour.
            • [^] # Re: Encore une bonne raison...

              Posté par (page perso) . Évalué à 2.

              Justement, c'est pour ça qu'il parlait de Spacewalk.
              Je pense que l'ouverture du code du RHN Satellite permettra enfin de réaliser à peu de frais les mises à jour.
              • [^] # Re: Encore une bonne raison...

                Posté par . Évalué à 2.

                il faudra alors que redhat change son contrat de maintenance, parceque pour le moment, il me semble que les utilisateurs s'engagent à ne pas utiliser des méthodes autres que les canaux officiels pour les updates...
                • [^] # Re: Encore une bonne raison...

                  Posté par (page perso) . Évalué à 3.

                  en:Spacewalk_(software) est effectivement beaucoup plus élégant comme solution, mais sur RHN tu bénéficies des mêmes fonctionnalités : c'est toi qui décide aussi quand tes clients se mettent à jour, idéalement après tes tests de non régression, par lots de serveurs.

                  Tu ne changes pas le canal officiel, tu ne rajoutes qu'un "proxy" sur le chemin... puis bon le prix du satellite, c'est 5 jours * 2 consultants * prix d'un consultant éditeur, donc bon, autant qu'il soit au même prix pour le service et en libre.

Suivre le flux des commentaires

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