Journal Faille OpenSSH : qu'une rumeur mais...

Posté par  (site web personnel) .
Étiquettes :
20
8
juil.
2009
Bonjour,

Ce n'est encore qu'une rumeur, mais tout le monde s'affole.

Au cas ou se serait sérieux et confirmé, autant commencer à s'y intéresser.

Pour moi, les premières infos viennent d'ici : [http://isc.sans.org/diary.html?storyid=6742]

Ce que je sais pour le moment :
Chez mon hébergeur (OVH) ils prennent leurs précautions :
leur ancienne distrib interne qui tourne encore chez beaucoup de clients (OVH release 1, basé sur redhat 7.2) avait OpenSSH 4.x
Ils sont en train de tout patcher pour passer en 5.2.
C'est préventif, on ne sais pas trop si le fait de passer de 4.x en 5.x peut éviter la supposée faille, mais c'est toujours mieux d'être à jour.

Sur une mailing-liste OVH, un des clients pense qu'il s'est déjà fait hacké un serveur, mais n'a rien pour le prouver.

J'ouvre donc ce journal pour :

- vous informer qu'il faut suivre un minimum (au cas ou... être prêt)
- proposer de regrouper en commentaire toute information complémentaire qu'on trouverait

Pour infos sur Debian :
En Debian Lenny on est en version : openssh_5.1p1-5 ( http://packages.debian.org/fr/lenny/openssh-server )
Attention en Debian etch c'est encore openssh_4.3p2-9etch3 ( http://packages.debian.org/fr/etch/openssh-server )

Les conseils :
- un fail2ban ne suffirait pas puisque l'attaque n'est pas un brute-force
- il est bien de changer le port par défaut de SSH puisqu'il semble qu'il y ait une augmentation statistique des scans pour vérifier l'ouverture de ce port 22
- suivre l'actu.....

Bonne soirée à tous,

Julien
  • # Et si....

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

    Bon je deviens peut-être/sûrement parano, mais et si c'était la dernière version qui était trouée, et pas les anciennes, mais qu'ils poussent à la mise à jour car ils ont une cible précise ?
    • [^] # Re: Et si....

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

      En effet, version plus récente ne veut pas toujours dire plus sécurisée.

      Mais dans le cas présent, un autre commentaire pointe sur cette histoire commentée :
      [ttp://www.tux-planet.fr/astalavista-pwnage-expose-by-anti-sec-group/]

      A priori la cible était un OpenSSH_4.3 si je comprend bien.

      ça ne dit pas que la 5.x n'est pas touchée, mais ça prouverait que la 4.3 l'est...
      • [^] # Re: Et si....

        Posté par  . Évalué à 5.

        • [^] # Re: Et si....

          Posté par  . Évalué à 2.

          sauf que si on lis bien certains commentaires, il est semblerait que c'est une 4.3 avec les patchs de sécu backporter par rh, donc une plus a jour qu'une simple "4.3"
        • [^] # Re: Et si....

          Posté par  . Évalué à 3.

          Peut être que quelqu'un a trouvé une faille dans la version 5 et lance une rumeur de faille dans la version 4 pour que tout le monde upgrade afin de pouvoir toucher plus de monde.

          (bon, c'est certainement faux, mais je trouverais ça marrant)
          • [^] # Re: Et si....

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

            C'est bien, tu as réussi à lire le premier commentaire du fil.
            • [^] # Re: Et si....

              Posté par  . Évalué à 2.

              Argh, oui, j'avais mal lu son commentaire. Désolé pour le (les) commentaire(s) inutile(s).
              • [^] # Re: Et si....

                Posté par  . Évalué à 3.

                Pas du tout, tu as fait ça en toute connaissance de cause en pensant à ceux qui auraient zappé le premier commentaire!

                Bon, je vais de ce pas recopier le second!


                -------------> [ ]
  • # Knockd

    Posté par  . Évalué à 6.

    Un petit coup de knockd sur le port du ssh et hop :]
  • # humm

    Posté par  . Évalué à -1.

    Hier j'ai observé une anomalie assez étrange sur un serveur... un mot de passe devenu invalide pour une base mysql alors que je n'y ai absoluement pas touché...

    => soupçon et surveillance

    + Ce journal

    => serveur compromis... :-/ (une recherche active des dégâts en perspective)
  • # Hadopi

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

    Ça va faire bizarre de voir des mecs sous OpenBsd se faire couper leur connexion internet, car leur ligne n'était pas assez sécurisé.
    • [^] # Re: Hadopi

      Posté par  . Évalué à -8.

      Aucun rapport :
      http://openbsd.org/45.html
      -> OpenSSH 5.2
      La faille ne semblerait toucher qu'openssh 4.3 fournis avec les derniers redhat et clones.
  • # Un rapport avec ceci?

    Posté par  . Évalué à 3.

    Une attaque sur une des serveurs d'Astalavista : http://www.tux-planet.fr/astalavista-pwnage-expose-by-anti-s(...)

    (l'attaque : http://www.tux-planet.fr/public/hack/nowayout.txt mais pas assez pour comprendre la faiblesse utilisée...)
    • [^] # Re: Un rapport avec ceci?

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

      on dépasse la petite rumeur en effet...
      • [^] # Re: Un rapport avec ceci?

        Posté par  . Évalué à 5.

        Non, je ne trouve pas qu'on soit au delà du stade de la rumeur actuellement. Toutes les infos que l'on peut trouver sortent de ce site : http://romeo.copyandpaste.info/. Plus éventuellement quelques mails anonymes... Après le fait que ce soit recopié ça et là lui donne une crédibilité exacerbée.
    • [^] # Re: Un rapport avec ceci?

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

      Astalavista existe encore ?
      Où n'est-ce pas une méthode pour faire parler d'eux ?
      • [^] # Re: Un rapport avec ceci?

        Posté par  . Évalué à 10.

        Ben se faire de la pub sur le thème «on vit encore, la preuve: nos serveurs viennent de se faire défoncer!», je ne sais pas si c'est une méthode marketing très maligne...
    • [^] # Re: Un rapport avec ceci?

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

      Non ça n'a pas de rapport, car manifestement l'intrusion sur Astalavista.com (à ne pas confondre avec Astalavista.box.sk) s'est faite au moyen d'une faille dans le serveur web (qui n'était pas Apache ; je sais plus le nom).
      • [^] # Re: Un rapport avec ceci?

        Posté par  . Évalué à 2.

        C'est pas ce que dit le récit/log de l'attaque :

        anti-sec:~/pwn# ./infoz infosec.org.uk

        IP: 66.96.220.213
        NS:
        - ns1.webhostline.com
        - ns2.webhostline.com
        Mail Server:
        - 66.96.220.213 > 6696220213.hostnoc.net
        WWW Server:
        Apache
        SSH Banner:
        SSH-2.0-OpenSSH_4.3 : PORT 2222

        anti-sec:~/pwn# cd xpl/

        anti-sec:~/pwn/xpl# ./openPWN -h 66.96.220.213 -p 2222 -l=users.txt

        [+] openPWN - anti-sec group
        [+] Target: 66.96.220.213
        [+] SSH Port: 2222
        [+] List: users.txt

        [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]

        user: crownvip
        uname: Linux srv01.webhostline.com 2.6.21.5-hostnoc-3.1.7-libata-grsec-32 #1 SMP Mon Feb 11 06:36:58 EST 2008 i686 i686 i386 GNU/Linux


        Manifestement, si le "log" (partiel) est bien celui de l'attaque, c'était bien un apache et c'est sur le port SSH que s'est déroulé l'attaque...

        à moins que tu n'es d'autres sources à nous faire partager ;-)
        • [^] # Re: Un rapport avec ceci?

          Posté par  . Évalué à 2.

          D'ailleurs tant qu'on parle de ce log, j'ai deux petites observations :

          * en paramètre de son script, il utilise un fichier users.txt. C'est donc a priori nécessaire d'attaquer avec une liste de noms, je ne vois pas de raison qui proscrive l'utilisation d'une brute force pour rentrer dans OpenSSH.

          * Il fait juste après l'entrée sur le serveur un "jail break". Le noyau est patché grsec (cf le uname -a), et il se trouve qu'il a une faille connue donnée en lien plus haut : http://www.digitalarmaments.com/2007200184936274.html. Il n'est pas impossible que ce soit cette faille qui soit utilisée.

          On peut trouver des sites qui commencent à parler de hoax à ce sujet : http://isc.sans.org/diary.html?storyid=6760
          • [^] # Re: Un rapport avec ceci?

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

            Pour avoir lu en détail les deux logs postés début juin, je ne pense pas que ce soit un hoax (beaucoup trop de détails à la con), par contre clairement les auteurs ont masqué / allégé / camouflé la manière utilisée pour entrer sur les serveurs. La commande g0tshell peut tout aussi bien être un véritable outil écrit par eux qu'un gros coup de pipeau. Par contre le fait qu'ils aient pu trouver une faille dans LiteSpeed est tout à fait crédible. Une fois sur la machine par contre, peu de raisons de croire que les infos soient fausses.
        • [^] # Re: Un rapport avec ceci?

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

          L'attaque dont je parlais (dont tout le monde s'est mis à parler le 6 juin) commence comme ça :

          anti-sec:~# ./g0tshell astalavista.com -p 80
          [+] Connecting to astalavista.com:80
          [+] Grabbing banner...
          LiteSpeed
          [+] Injecting shellcode...
          [-] Wait for it

          [~] We g0tshell
          uname -a: Linux asta1.astalavistaserver.com 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:35:59 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
          ID: uid=100(apache) gid=500(apache) groups=500(apache)

          sh-3.2$ cat /etc/passwd
          (...)

          C'est le serveur web (LiteSpeed) qui a été craqué (il s'exécutait en tant qu'utilisateur nommé « apache » ce qui porte à confusion).

          Source : cache Google, car l'original a disparu (comme prévu) : http://209.85.135.132/search?q=cache:mA8d4EnYvj8J:pastebin.c(...)
          • [^] # Re: Un rapport avec ceci?

            Posté par  . Évalué à 2.

            On parle bien de deux attaques différentes ;-)

            Celle que je cite en premier semble bien avoir un lien avec la rumeur qui traîne depuis hier.
  • # Des infos supp

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

    Bonsoir,

    Encore quelques infos [http://www.zataz.com/forum/index.php?autocom=blog&blogid(...)]

    A priori ça comporterait un minimum de brute-force, mais sur l'user !
    Voici par exemple la liste des users testés sur un serveur de zataz:
    [http://www.zataz.net/eromang/invalide-ssh-user-list.txt]

    Les classiques comme root ou ROOT, mais également les prénoms très portés comme john y sont présents (julien également ;-) )
    • [^] # Re: Des infos supp

      Posté par  . Évalué à 3.

      Il y a aussi porn ;)
    • [^] # + d'infos

      Posté par  . Évalué à 10.

      Un contributeur à openssh en parle ici : http://lwn.net/Articles/340483/ en ces termes :

      In particular, I spent some time analysing a packet trace that he provided, but it seems
      to consist of simple brute-force attacks.

      So, I'm not pursuaded that an 0day exists at all. The only evidence so
      far are some anonymous rumours and unverifiable intrusion transcripts.
      • [^] # Re: + d'infos

        Posté par  . Évalué à 6.

        Contributeur, contributeur... c'est jamais que djm@, qui est un des auteurs principaux de OpenSSH depuis le début.
  • # Pas facile de ce prononcer...

    Posté par  . Évalué à 8.

    Personellement, je ne sais pas trop quoi en penser...

    D'un côté, le seul début de preuve de l'existence d'un tel exploit sont les logs publiés par ceux qui se proclament les auteurs de ceux-ci. Rien de vraiment tangible donc. D'ailleurs la reprise de ce log dans divers sites d'informations concernant la sécurité informatique à un peu tendance à lui donner une importance démesurée. C'est peut-être un gros coup de bluff, je peux rédiger de tels logs dans la demi-heure qui suit. OpenSSH est quand même la cible idéale pour un gros coup de bluff : très utilisé et surtout réputé très sécurisé. Quelqu'un capable de trouver une faille dans OpenSSH est supposé capable d'en trouver une dans une multitude de logiciels. Ce genre d'annonce fait planer le spectre de l'impossibilité de sécuriser quoique ce soit...

    D'un autre côté, on note actuellement une augmentation des scans de port SSH en ce moment. Dans la même veine, ça ne veut rien dire non plus. Je peux également faire des tas de scans SSH dans la demi-heure qui suit.

    Bref, à mon sens aucun élément de preuve valable, juste des bribes d'infos.
    Ce qui permettrait à mon avis d'éclaircir cette rumeur serait que les personnes ayant eu des serveurs compromis le signalent, de ma manière à voir si l'on a une augmentation statistique significative des attaques
    • [^] # Re: Pas facile de ce prononcer...

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

      Sur une ML OVH, une personne se pense victime, voici son récit (qui n'apprend rien, hormis son inquiétude):


      Je pense avoir été touché sur un SP sur centos.

      Mon fail2ban est plutôt chatouilleux (2 erreurs = 1 ban 48h), et
      pourtant, il y'a 72 ou 96h , j'ai eu 2 users root qui ont réussi à se
      logger depuis des ip roumaines.

      Le mot de passe était assez fort, et vu la vitesse des scans, je ne
      pense qu'il ait pu le casser. De +, le passe n'est enregistré nul part.

      Mon bash_history a été vidé of course....Je ne pense pas qu'ils aient eu
      le temps de faire quoique ce soit....

      J'ai viré le port 22, et j'ai désactivé le login par password pour du
      only RSA (2048 bits cette fois) en attendant de voir ce que ça dit.

      Je pense vraiment à une faille car je vois pas comment ils auraient pu
      casser le password sinon... :(


      Depuis il n'a pas donné d'info supplémentaire sur sa recherche d'information.
      • [^] # Re: Pas facile de ce prononcer...

        Posté par  . Évalué à 4.

        Il m'était arrivé en gros la même chose il y a quelques années. Log du premier coup avec le bon nom d'utilisateur. En revanche il n'avaient pas vidé le .bash_history et il n'ont visiblement pas réussi à passer en root. Par précaution je me suis tout de même livré à un formatage en règle. La seule piste plausible que je vois dans mon cas c'est une connexion avec une machine vérolée par un keylogger. Enfin bref, tout ça m'avait bien refroidi à l'époque.
      • [^] # Re: Pas facile de ce prononcer...

        Posté par  . Évalué à 10.

        > Sur une ML OVH, une personne se pense victime, voici son récit (qui n'apprend rien, hormis son inquiétude):

        Pour relativiser un tel témoignage, il est bon de préciser que les m-l d'OVH sont saturées de bras cassés et autres admins du dimanche... (pas toujours capables de découvrir _comment_ ils se sont fait pirater, par ex.).

        Quant au "patch" fournis par OVH (une réaction du type : "la *rumeur* semble vaguement indiquer qu'un problème touches les vielles [sans précisions] versions alors upgradons tout sur la dernière release"), là aussi il convient de connaître cet hébergeur pour ne pas s'affoler prématurément.

        OVH est champion de la sécu à la kéké / jacky (on sécurise une distro comme on tune une voiture : en ajoutant des ailerons qui brillent). En témoigne leur distro (un fork de gentoo, ça va de soi) basée sur un kernel patché GRsec, le fameux jeux de patchs dont les mainteneurs du noyau - et les distros commerciales employant des devs noyaux (pas le cas d'ovh à priori...) - ne veulent pas.

        Alors les voir "résoudre" au pifomètre ("on upgrade à la dernière release") un problème dont personne ne sait rien (y compris comment le résoudre) ne doit pas vous alarmer, et n'est en aucun cas un signe indiquant que la rumeur serait fondée.

        Je crois que la meilleur source d'information à cette heure (la plus crédible) reste l'analyse du mainteneur principal d'OpenSSH. S'il y a un vrai problème, il sera l'un des premiers informés, et probablement l'un des premier à trouver/fournir la solution adaptée :

        http://marc.info/?l=openssh-unix-dev&m=124705272824524&a(...)

        Concernant la prévention : pour contenir les vrais problèmes courants ou avérés (mots de passes faibles ou "leakés", applis installées ayant crée des users avec mots de passes std/par défaut, certificats/clefs pourries, brute force, mdp saisi sur une machine keylogguée dans un cybercafé polonais, ...), il est utile de restreindre (avec un firewall) l'accès au port 22 aux seules IP utilisées par les admins. Ne pas exposer un tel service à tout l'internet tant que ce n'est pas nécessaire.
        • [^] # Re: Pas facile de ce prononcer...

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

          OVH est champion de la sécu à la kéké / jacky

          Eux gèrent >50 000 serveurs sans trop de casse (ils subissent de nombreuses attaques, forcément autant de machines c'est intéressant), qui es-tu pour penser être meilleur qu'eux?
          Tu peux amener une preuve que tu sais gérer des machines mieux qu'eux (avec des vrais serveurs, hein)?

          Les attaques gratuites sur OVH, c'est lourd.
          • [^] # Re: Pas facile de ce prononcer...

            Posté par  . Évalué à 10.

            euhh ... ils "gèrent" pas les serveurs dédiés, il les louent. C'est d'ailleurs l'intérêt d'un dédié.
            D'un coup ca diminue un peu ton chiffre.
            • [^] # Re: Pas facile de ce prononcer...

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

              tu exagères un poil. Ils ont plein de serveur pour faire du partagé. De plus, ils monitorent aussi leur réseau pour couper les serveurs compromis.

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

              • [^] # Re: Pas facile de ce prononcer...

                Posté par  . Évalué à 3.

                tu exagères un poil. Ils ont plein de serveur pour faire du partagé
                J'ai pas dis que le nombre de serveurs qu'ils géraient étaient à "0" , mais que si ils ont 50 000 serveurs dont 30 000 de dédiées, c'est pas tout a fait la même chose

                De plus, ils monitorent aussi leur réseau pour couper les serveurs compromis.
                Ce qui n'est absolument pas leur boulot (et si j'ai envie de payer pour un honey pot, je fais comment ?) (et si j'ai un traffic qui peut faire penser à une DDoS mais qui est un test de charge ?)
                • [^] # Re: Pas facile de ce prononcer...

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

                  Ils interdisent la présence de proxy, et surtout il interdisent les scan qui partent de leur réseau (si ils ne le font pas il risque de se faire couper l'accès par les réseaux scanné).

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

                  • [^] # Re: Pas facile de ce prononcer...

                    Posté par  . Évalué à 6.

                    ils interdisent tor, et ils interdisent irc, et ils suppr des serveurs comme ça sans essayer de joindre les gens (a si un mail automatique le samedi, serveur supprimé le lundi ... Génial!)
                  • [^] # Re: Pas facile de ce prononcer...

                    Posté par  . Évalué à 2.

                    Mouais, ben les scans ils passent sans problème :-)
                    J'ai testé en début d'année depuis un dédié 1 Gb/s chez OVH pour trouver des serveurs d'administration Kaspersky. J'ai scanné genre brute épaisse les adresses jusqu'à je crois 120.0.0.0 en quelques heures sur 2 ports.

                    Conclusion du test: il y a bel et bien une grande facilité pour récupérer des clefs de licences Kaspersky. Incroyable la nullité de beaucoup d'administrateurs.

                    Je n'ai pas osé tester le mot de passe par défaut, mais là ce serait le ponpon: contrôle à 100% sur les clients connectés :-)
                    • [^] # Re: Pas facile de ce prononcer...

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

                      Tu veux dire que la majorité des windowsien avec un anti-virus Kaspersky dispose d'une jolie backdoor ?

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

                      • [^] # Re: Pas facile de ce prononcer...

                        Posté par  . Évalué à 6.

                        Non :-)

                        Une phrase d'un collègue m'a fait soupçonner un problème avec une facilité offerte par les serveurs d'administration Kaspersky. Ce sont les serveurs des entreprises qui ont un certain nombre de machines à administrer au niveau de l'anti-virus, et donc elles mettent en place un serveur d'administration Kaspersky au lieu de tout se palucher à la mimine.
                        J'ai testé chez nous, le problème est réel. J'ai pour cela mis en route la facilité en question, car elle ne nous sert pas... et j'ai horreur de ces soi-disant facilités qui font toujours des trucs dans ton dos.

                        Après ça, je me suis dit qu'il existe probablement des milliers de serveurs d'administration Kaspersky accessibles sur les ports standards ET avec la facilité activée. D'où mon scan de machines. J'avais scanné 3 port en fait. Les deux ports Kaspersky, plus un port bidon sensé être fermé, afin d'éviter trop de faux positifs.
                        Le scan m'a ramené plus d'une centaine de machines (donc pas des milliers finalement). Sur le lot, beaucoup étaient visiblement autre chose que ce que je voulais. Les quelques autres que j'ai testé étaient presque toutes des serveurs Kaspersky. Et presque toutes avec la facilité activée. Je connecte un poste fraîchement installé (et surtout à réinstaller illico) sur le premier serveur trouvé... une clef de licence. Sur le second... une clef. Etc :-)
                        La facilité en question permet d'attribuer automatiquement une licence aux clients qui se connectent. Ca évite à l'admin d'avoir à être compétent.

                        En gros, ça permet d'avoir des licences facilement. Mais bon, il y a déjà un site web rempli de licences Kaspersky valides. Ca permet surtout de consommer toutes les licences d'une victime.

                        Le pire: si un serveur a toujours le mot de passe par défaut, tu peux ouvrir la console d'administration (librement récupérable chez Kapersky), créer un paquet d'installation maison (avec la charge voulue), déployer ce paquet sur les postes... et boum :-)

                        J'ai dans l'idée que beaucoup de ces serveurs ont le mot de passe par défaut.
                        • [^] # Re: Pas facile de ce prononcer...

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

                          Tu veux dire qu'il existe des admin système qui installent ce genre de machine avec une IP accessible directement sur Internet (déjà, c'est un peu limite...),mais en plus, ils ne sont pas fichus de : 1) limiter la connexion aux services Kapersky à la plage d'adresses IP de leur réseau interne, ou 2) de mettre un firewall qui empêche les utilisateurs externes de se connecter à ce service ?

                          Mais ces types ont des Classe B ou C publiques ou quoi ? C'est donner de la confiture au chochons ca !

                          Et ils sont payés pour faire ce type de boulettes ?

                          Je comprends mieux pourquoi des "gros" réseaux ont tant de problème de sécurité...

                          Ca permet surtout de consommer toutes les licences d'une victime.
                          Je sais que c'est de l'humour. Mais j'imagine la tête de l'admin de la machine lorsqu'il s'apercevra qu'il n'a plus de clés de dispo.. ;)
                          • [^] # Re: Pas facile de ce prononcer...

                            Posté par  . Évalué à 2.

                            j'imagine la tête de l'admin de la machine lorsqu'il s'apercevra qu'il n'a plus de clés de dispo
                            C'était une de mes préoccupations. Je voulais savoir si nous étions soumis à ce risque (donc oui si nous ne faisons pas attention, donc comment supprimer le risque quasi-totalement ?).
          • [^] # Re: Pas facile de ce prononcer...

            Posté par  . Évalué à 10.

            > Eux gèrent >50 000 serveurs sans trop de casse

            Alors :
            1- Ils ne gèrent eux-même qu'une fraction des serveurs qu'ils hébèrgent.
            2- Vu les merdes que remontent mes services et mon fw (bots scannant depuis des serveurs voisins), en nombre bien plus conséquent que chez mes autres et mes précédents hébergeurs, je ne dirait pas qu'ils s'en sortent bien

            > Tu peux amener une preuve que tu sais gérer des machines mieux qu'eux

            J'aurais tendance à dire que c'est à eux d'amener la preuve qu'ils fournissent autre chose que de la "snake oil security" vu que :

            - Ils ont des prétentions dans ce sens (voir leur com')
            - C'est eux qui vendent des services, pas moi.
            - Ils installent d'office un frankenkernel "grsec" contre l'avis des spécialistes du kernel au sujet de ce patchset (les mainteneurs), et bien sûr compilé sans SELinux. "Qui sont-ils pour prétendre mieux savoir que les devs du kernel eux-même ?".
            - Ils l'installent aussi lorsqu'ils fournissent des serveurs installés avec autre chose que leur distro cocasse. Par exemple ils fournissent les Debian avec leur kernel (installé et booté). "Qui sont-ils pour prétendre mieux faire que les fournisseurs de ma distro ?".

            Pour donner tout son sel au dernier point (les Debian sont installées sans le kernel standard de la distro), il faut préciser que la kermerde qu'ovh nous inflige _n'est pas packagée_ (ils posent un bzimage dans /boot et basta). Histoire de donner de bonnes chances aux users de louper les upgrades sécu importantes telles que fournis par les canaux usuels de la distro. Chapeau.

            Ca ne veux pas dire qu'ils n'ont pas des gens compétents et intelligents en interne, mais il y a de bonnes chances pour qu'il s'agisse d'une de ces boites où un manager/décideur/monsieur-je-sais-tout fort en gueule et ne sachant pas déléguer, au hasard Oles, décide arbitrairement de choses qui le dépasse, et l'équipe technique n'a plus qu'à faire au mieux ... (pure supposition bien sûr...).

            De mon point de vue, lorsque quelqu'un s'amuse à distribuer des versions patchées "pour la sécu" de logiciels bien maintenus et développés par des gens compétents, je crois que la preuve de la qualité et fiabilité de l'apport en incombe au amateurs du tuning. Le carnage de l'OpenSSL patché de Debian devrait le montrer assez pour faire réflechir les jackys de service. Le passé de Grsec aussi*.

            * http://www.digitalarmaments.com/2007200184936274.html
            • [^] # Re: Pas facile de ce prononcer...

              Posté par  . Évalué à 4.

              Il est clair que le métier d'OVH n'est pas la sécurité. Leur métier est la location de serveurs, de connectivité réseau, d'espace d'hébergement, et ils le font bien. Voire presque très bien. Le reste est à oublier.

              Sur notre dernier dédié, installé avec Lenny 64-bits, les utilitaires supplémentaires qu'ils ne peuvent s'empêcher de mettre sont en 32-bits. J'ai mis plusieurs minutes avant de comprendre pourquoi ça ne se lancait pas :-)
              Et les utilitaires en question c'est quoi ? La surveillance matérielle via leur RealTime Monitoring, rien que ça.

              J'arrête, ils se débrouillent globalement très bien. Il faut juste ne pas leur demander pour tel serveur n'est pas joignable de l'extérieur de leur réseau alors qu'il l'est de l'intérieur, ou des choses un peu velues.
        • [^] # Re: Pas facile de ce prononcer...

          Posté par  . Évalué à 6.

          Alors les voir "résoudre" au pifomètre ("on upgrade à la dernière release") un problème dont personne ne sait rien (y compris comment le résoudre) ne doit pas vous alarmer, et n'est en aucun cas un signe indiquant que la rumeur serait fondée.

          C'est ça que je ne pige pas : ils mettent à jour, sans même connaître la faille. Si ça se trouve, c'est la version qu'ils installent qui apporte la fameuse faille...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Pas facile de ce prononcer...

        Posté par  . Évalué à 5.

        Hem, personnellement je n'autorise jamais la connexion en root via SSH, aussi fort le mot de passe soit-il...

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Pas facile de ce prononcer...

          Posté par  . Évalué à 2.

          moui ça me paraît une bonne idée ^^
          c'est par ailleurs la config par défaut sur ma mandriva en niveau de sécurité élevé (je ne sais pas pour le standard)
          L'autre sécurité est les login de connexion pas courant, et des mots de passe fort. cependant, pour plus de sécurité j'ai stoppé le serveur ssh (j'en ai pas besoin pour le moment, et le reste de la famille étant en vacance sans accès à internet ça ne peut pas nuire.)

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Pas facile de ce prononcer...

            Posté par  . Évalué à 3.

            pour plus de sécurité j'ai stoppé le serveur ssh

            Tiens, pareil ce matin...

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Pas facile de ce prononcer...

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

          En plus de ca, je recommande de n'ouvrir le port 22 qu'aux IP susceptibles de l'utiliser.
          • [^] # Re: Pas facile de ce prononcer...

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

            C'est bien le problème en ce qui me concerne, je ne peux pas savoir à l'avance depuis quelle IP je vais accéder à ma machine, donc j'aimerais bien mais je peux pas.

            Cela dit, s'il y a moyen de passer par une console d'admin web ultra sécurisée (avec mdp+certificat pas public+autre systèmes de sécu pour parano inconsolable) pour rajouter à la volée les IP accessibles dans la conf iptables pour ssh, je suis preneur.
          • [^] # Re: Pas facile de ce prononcer...

            Posté par  . Évalué à 3.

            :-) pour moi c'est facile: depuis n'importe quelle connexion ADSL de France, depuis n'importe quelle connexion 3G de France, depuis n'importe quelle connexion WiFi de France. Pour l'instant uniquement depuis la France.

            Quelles mesures de protection prenez vous ?
            Pour moi:
            - port 22 avec un démon ssh_bidon qui refuse toutes les connexions
            - port xxx avec le vrai ssh
            - fail2ban après 2 tentatives, banissement sur tous les ports pendant 24 heures
            - root ne peut pas se connecter directement en ssh

            Il faudrait que j'ajoute:
            - portknockd ou fwknop
            - des clefs, mais je dois me connecter depuis beaucoup d'endroits différents et pas toujours avec une machine qui m'appartient. Dans ce cas il me faudrait probablement un mot de passe qui change à chaque connexion. Ca fonctionne bien mais je ne l'ai pas industrialisé chez nous.
    • [^] # Re: Pas facile de ce prononcer...

      Posté par  . Évalué à 9.

      Moi, y a un truc que je trouve bizarre.
      Qui, avec une zero day dans openssh et toutes les possibilités que ça offre, irait se faire chier à attaquer astalavista.com ?
      • [^] # Re: Pas facile de ce prononcer...

        Posté par  . Évalué à 2.

        Guerre de hackers ?

        Apparemment, en outre, la faille de sécurité ne concernerait que des anciennes versions d'OpenSSH... Mais il est clair qu'il doit y avoir bien plus intéressant et bien plus tentant à attaquer !
      • [^] # Re: Pas facile de ce prononcer...

        Posté par  . Évalué à 4.

        Quelqu'un qui s'est fait attaquer et a voulu déjà se venger (et en plus se fait traiter de script kiddie, z'ont pas aimé visiblement ^_^)
        • [^] # Re: Pas facile de ce prononcer...

          Posté par  . Évalué à 4.

          non, il a attaqué astalavista, et ensuite le gars les a traité de script kiddie. Et ils se sont venger en rm -rf /
          • [^] # Re: Pas facile de ce prononcer...

            Posté par  . Évalué à 1.

            ben surtout, visiblement, ils savaient pas encore qu'ils s'etaient fait traite de script kiddies avant de reattaquer les machines.

            Ca les a peut etre motive pour le rm -rf / cela dit.
      • [^] # Re: Pas facile de ce prononcer...

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

        Les gens d'Astalavista, histoire de faire parler d'eux ?
    • [^] # Re: Pas facile de ce prononcer...

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

      « Ce qui permettrait à mon avis d'éclaircir cette rumeur serait que les personnes ayant eu des serveurs compromis le signalent, de ma manière à voir si l'on a une augmentation statistique significative des attaques »

      Ça sert à rien : on aurait une simple augmentation statistique des récits d'attaques, et on pourrait rien en déduire de plus.
  • # Ce qu'en disent les mailing lists

    Posté par  . Évalué à 1.

    Pour si ça vous intéresse : http://lwn.net/Articles/340483/
  • # Open0wn

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

    Le top ce serait d'avoir le programme et de le tester sur nos serveurs. Personne ne l'a trouvé ?
  • # openvpn

    Posté par  . Évalué à 2.

    Une alternative à ce genre de problèmes serait à mon humble avis d'utiliser openvpn quand c'est possible. Cela permet de ne pas ouvrir le port ssh directement vers l'exterieur.

    Personnellement, je n'ouvre ssh que pour l'addresse IP de mon boulot car je l'estime être de confiance. Pour le reste, c'est openvpn pour pouvoir accéder au ssh de ma machine.
    • [^] # Re: openvpn

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

      perso j'ai désactivé l'authentification par mot de passe, seul l'auth par clef est autorisé.

      ChallengeResponseAuthentication no
  • # FUD ?

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

  • # Væ victis

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

    C'était bien du FUD, mais ceux qui y ont cru au point de télécharger et d'exécuter bêtement les prétendus exploits s'en mordent les doigts :

    http://news.softpedia.com/news/Rogue-OpenSSH-0-Day-Exploit-D(...)

Suivre le flux des commentaires

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