Journal De l'approche ultra-légère de la sécurité sur linuxfr

Posté par .
-25
17
juil.
2014

Comme vous le savez, linuxfr a été très lent ces derniers jours. Cette lenteur est en fait dûe à un problème de sécurité au niveau du service elasticsearch, qui a permis à des bots floodeurs de s'exécuter.

Comme on peut voir dans le lien, les admins linuxfr ont arrêté elasticsearch et verrouillé le compte concerné. A première vue c'est assez logique : on peut penser que les bots ont profité d'une API trop ouverte d'elasticsearch pour le faire indexer des pages de spam. Il n'y aurait donc aucun risque que le serveur soit vérolé au delà d'elasticsearch.

Sauf qu'on apprend que le problème n'était pas celui là : le problème était qu'une fonctionnalité permettant d'exécuter du code arbitraire était ouverte.

Je cite la doc. d'elasticsearch :

Well, the issue with dynamic scripting is that it opens the full power of the JVM to execute arbitrary scripts. Scripts can be sent that read files from disk, execute commands through the java.lang.Runtime package, access the internals of Elasticsearch, and so on.

Bref, n'importe quoi a pu être exécuté par l'user d'elasticsearch.

En résumé :

  • Du code arbitraire a pu être exécuté depuis le début de la version RoR de linuxfr
  • La faille a été exploitée pendant plus d'une semaine
  • La réponse est uniquement de désactiver le service problématique
  • Il n'y a eu aucune vérification que le système n'est plus vérolé, aucune vérification que les données des utilisateurs n'ont pas été leakées, et en plus il n'y a aucune indication qu'il est prévu de le faire.

Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte ?

  • # tu as raison

    Posté par . Évalué à 5.

    moi je vais regarder si des retraits de carte bleue suspect n'ont pas ete fait et je porte plainte contre linuxfr
    dans ce cas
    en plus il ont pu aussi obtenir mes numeros secret que je joue ou loto et si a cause de ça je perds des gains je porte plaine

    • [^] # Re: tu as raison

      Posté par . Évalué à 7.

      Si les mots de passe sont partis, c'est autrement plus gênant.

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

      • [^] # Re: tu as raison

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

        J'ose espérer qu'il sont au moins hashés et salés (dans n'importe quel sens)

        • [^] # Re: tu as raison

          Posté par . Évalué à 10.

          Je crois qu'ensuite ils sont doucement mijotés.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: tu as raison

          Posté par . Évalué à 2.

          Ce qui, avec hashcat, est d'une très relative utilité.

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

        • [^] # Re: tu as raison

          Posté par . Évalué à 7.

          hashés et salés (dans n'importe quel sens)
          Vaut vraiment mieux les saler avant de les hacher. Sinon, ça enlève tout intérêt au sel.

          • [^] # Re: tu as raison

            Posté par . Évalué à -3.

            Clair. Sinon à ce compte-là, autant mettre du poivre.

  • # Précision sur les aspects légaux

    Posté par . Évalué à 2.

    On me demande sur la tribune qui est responsable de quoi et les risques encourus.

    C'est l'article 34 de la loi informatique et libertés qui traite la question : http://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=9FC0185CD5DE2827331EDF16ADB7E619.tpdjo16v_2?idArticle=LEGIARTI000006528132&cidTexte=LEGITEXT000006068624&dateTexte=20140717

    Et l'article afférent du code pénal : http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006417964&cidTexte=LEGITEXT000006070719

    Evidemment, ce n'est que très théorique, les données sur dlfp n'étant pas vraiment sensibles.

    • [^] # Re: Précision sur les aspects légaux

      Posté par . Évalué à 6.

      A partir du moment où il y a des mots de passe, c'est sensible. Beaucoup de gens réutilisent le même mot de passe sur beaucoup de services, y compris leur adresse mail. Et si tu as accès à un mail, tu peux faire plein de choses sur tous les comptes enregistrés dessus…

  • # Yakafokon

    Posté par . Évalué à 10.

    Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte ?

    Tes capacités d'administrateur ou de développeur sont attendues ? Plus d'informations sont disponibles sur participer-a-linuxfr.

    • [^] # Re: Yakafokon

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

      Je dirais même plus: Tes capacités d'administrateur ou de développeur sont attendues !

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Yakafokon

      Posté par . Évalué à 5.

      Tes capacités d'administrateur ou de développeur sont attendues ? Plus d'informations sont disponibles sur participer-a-linuxfr.

      Euh, le fait que je n'ai ni le temps ni l'envie de participer à l'administration de linuxfr ne signifie pas que je n'ai pas le droit de m'attendre à ce que mes données soient traitées conformément aux pratiques habituelles de sécurité et à la législation.

      • [^] # Re: Yakafokon

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

        Typique de la pensée clientéliste et non communautaire primant de nos jours.

        Un site vivant de la publicité je suis d'accord que tu sois en droit d'attendre quelque chose, vu que tu es client indirectement.

        Un site communautaire sans pub, je ne vois pas en quoi tu es en droit d'attendre quoi que ce soit si tu n'y participes pas. Pour autant je pense que décrire ce qui pourrait être amélioré est en soi une forme de participation.

        Personnellement je ne contribue pas à Linuxfr et je ne me sens absolument pas en position d'avoir le droit d'attendre quoi que ce soit.

        • [^] # Re: Yakafokon

          Posté par . Évalué à 2.

          Personnellement je ne contribue pas à Linuxfr et je ne me sens absolument pas en position d'avoir le droit d'attendre quoi que ce soit.

          Pour ma part, je ne me sens pas en position d'attendre que des fonctionnalités soient implémentées, ou qu'un contenu sur un sujet particulier soit réalisé, ou même que les admins soient polis avec moi.

          Par contre, et comme dit dans le commentaire précédent, je m'attends à ce que les données que je confie soient traitées conformément aux pratiques de sécurité habituelles.

          • [^] # Re: Yakafokon

            Posté par . Évalué à 9.

            exactement ! "habituelles". jusqu'à la preuve du contraire, la team dlfp n'a pas volontairement exposé des données. La faille résulte d'un manque de temps, compétence, experience, savoir, etc.

            ET ALORS ? Que veux-tu y faire ?
            Quel est ton but dans la vie si ce n'est te la jouer Jean Jacques Bourdin et racoler tout ce que tu peux pour essayer de passer pour quelqu'un qui pèse dans un quelconque débat ?

            Il y a une faille, elle est corrigée ou en cours. S'il faut s'inquiéter pour nos données, ils nous le diront. Dans le doute tu peux changer tes mots de passe. Maintenant, NEXT.

          • [^] # Re: Yakafokon

            Posté par . Évalué à 10.

            Par contre, et comme dit dans le commentaire précédent, je m'attends à ce que les données que je confie soient traitées conformément aux pratiques de sécurité habituelles.

            Va falloir que tu me décrives le "habituelles", parce que c'est un peu vague, et pour moi ça va de la petite boite avec l'admin IT qui est un pote du cousin qui s'y connaît vachement en Windows et la multinationale qui a une équipe IT sécurité à plein temps.

            Voilà bien une expression vide de sens "pratiques de sécurité habituelles", l'énorme majorité des sites qui ont un système login/mot de passe ne décrivent pas leur architecture et leur approche sécurité. Mais toi tu sais que "habituellement", y'a aucun reproche à faire?

          • [^] # Re: Yakafokon

            Posté par . Évalué à 8.

            je m'attends à ce que les données que je confie soient traitées conformément aux pratiques de sécurité habituelles.

            Ben pourquoi tu râle? Le niveau de sécurité de linuxFr est trop élevé? Je commence à comprendre, on est parti sur un quiproquo depuis le départ.

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

      • [^] # Re: Yakafokon

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

        Dans ce cas, toute ton indignation ne motive-t'elle pas un don pour acheter la prestation d'un expert en sécurité pour réaliser les actions sus-citées ?

        Il ne faut pas oublier que DLFP est un site qui ne génère pas d'argent, qui est maintenu simplement par de gentils bénévoles pendant leur temps libre, et tant pis pour "les pratiques habituelles de sécurité et […] la législation". Râler dans un journal sans proposer d'aide ne fera que diminuer leur précieuse motivation.

        • [^] # Re: Yakafokon

          Posté par (page perso) . Évalué à 1. Dernière modification le 17/07/14 à 15:49.

          OK, je note : faire une chose gratuitement excuse de tout.

          Euh… Sérieusement, vous êtes dans cet état d'esprit?
          Je m'en vais vite enlever un enfant nigérien de ses méchants parents (oui je prend gros, juste pour montrer où va cette idée), de manière bénévole hein, et on ne me dira rien (illégal? Je fais comme je peux, hein, j'ai pas l'argent pour faire les démarches légales).

          Désolé, faire une chose bénévolement n'enlève aucunement de responsabilités déjà légale, et ensuite de gestion de sécurité. La menace "ne fera que diminuer leur précieuse motivation." est un peu facile… Dans beaucoup d'autres cas (jen parle pas d'ici), la conclusion a été qu'il vaut mieux fermer que de faire quelque chose de cassé. Bénévole ou pas, quand on fait une chose, ça implique parfois des responsabilités.

          PS : je ne veux aucunement attaquer les admins sur le point précis d'ES et d'une fuite potentielle de données, je n'ai aucune compétance sur le sujet et des erreurs, ça arrive, mêmes aux Google/Twitter/Facebook qui se paient les meilleurs… Le travail accompli est sans doute conforme à l'importance du site. Je juge le journal pas mal aggressif, mais cette aggressivité n'excuse pas de sortir n'importe quoi pour excuser quelque chose.

          • [^] # Re: Yakafokon

            Posté par . Évalué à 1.

            Je m'en vais vite enlever un enfant nigérien de ses méchants parents (oui je prend gros, juste pour montrer où va cette idée), de manière bénévole hein, et on ne me dira rien (illégal? Je fais comme je peux, hein, j'ai pas l'argent pour faire les démarches légales).

            Je prendrais plutôt un autre exemple : tu es animateur bénévole dans une crèche, et le manque d'animateurs associé à une erreur fait qu'un gamin sort et se fait écraser par une bagnole.

            La crèche répond "ce n'est pas de notre faute t c'est normal, si tu veux qu'on fasse mieux tu n'as qu'à contribuer".

            Bah non, si tu n'es pas capable de faire les choses conformément à la loi et aux bonnes pratiques avec les moyens que tu as, tu ne les fait pas.

            • [^] # Re: Yakafokon

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

              Et moi je prendrais l'exemple du chat qui fait ça toilette, mais je ne vois pas bien le rapport non plus.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Yakafokon

                Posté par (page perso) . Évalué à -1. Dernière modification le 17/07/14 à 16:01.

                Assez rigolo : si tu ne vois pas le rapport entre l'exemple donné et vos réaction, c'est énorme : vous dites exactement ça : c'est bénévole, donc toute erreur est acceptable "fallait aider sinon". C'est la vision que vous avez.

                Hum… C'est triste cette déresponsabilisation. Ha oui, bien évidement ça marchera que pour ce que vous voulez défendre, et pas ceux que vous voulez "punir", j'imagine…

                PS : encore une fois, je ne critique pas les admins, si j'ai bien suivi ce ne sont pas eux qui moinssent et Benoît Sibaud a une bien meilleure réponse plus posée…

                • [^] # Re: Yakafokon

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

                  vous dites exactement ça : c'est bénévole, donc toute erreur est acceptable

                  Ah bon, où ça au fait ?

                  C'est triste cette déresponsabilisation

                  T'as raison, le mec qui grogne ne se sent pas responsable alors qu'il n'a rien fait pour améliorer la situation.

                • [^] # Re: Yakafokon

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

                  Une activité bénévole requiert de se conformer la loi, comme pour n'importe quelle activité.

                  Donc s'attendre que LinuxFR soit en conformité avec la loi, oui.

                  S'attendre à ce que LinuxFR traite les données conformément aux pratiques habituelles de sécurité, uniquement dans le cadre posé par la loi (qui est citée précédemment, et qui assez vague et peut être précisée par des décrets dont je n'ai pas connaissance).

                  Et d'ailleurs l'article 34bis précise que si des données personnelles sont violées, le fournisseur de service doit notifier la CNIL et l'utilisateur si nécessaire.

                • [^] # Re: Yakafokon

                  Posté par . Évalué à 7.

                  Assez rigolo : si tu ne vois pas le rapport entre l'exemple donné et vos réaction, c'est énorme : vous dites exactement ça : c'est bénévole, donc toute erreur est acceptable "fallait aider sinon". C'est la vision que vous avez.

                  Ouai mais ça n'a rien avoir avec le propos initial qui ne parle pas d'excuse, mais de réfléchir à comment améliorer les choses. Est-ce qu'on paie un audit ou un gars à pleins temps pour s'occuper de la maintenance ? Est-ce qu'on finance une fonctionnalité d'authentification sans mot de passe ou on loue/achète un HSM ? Est-ce qu'il y a besoin de bras en plus ?

                  La question légale n'a rien avoir avec le sujet.
                  La question de la résponsabilité c'est juste du troll et on est pas vendredi.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Yakafokon

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

              Si t'es pas capable de t'assurer à 100% qu'un site sur lequel tu as créé un compte n'a aucune faille de sécurité, ne crée pas de compte.

            • [^] # Re: Yakafokon

              Posté par . Évalué à 10.

              Désolé, mais de mon point de vue LinuxFR rempli plus que largement ses obligations de sécurité.

              Pour reprendre ton exemple de la crèche, t'es plutôt le gars qui râle réclamant des mesures de sécurité supplémentaire aux exigences légales (genre 1 adulte pour 2 enfants) et qui refuse de payer pour.

              La loi réclame que le site ait un niveau de sécurité relatif a la criticité des données traitées. Les mots de passes sont hashés et salés. Tu veux quoi? Qu'est ce qu'il y a de si critique pour que tu réclames plus? C'est tes 37 commentaires ou tes deux journaux qui pourraient êtres dénaturés ? Ton adresse mail qui partirait dans la nature?

              Bref la loi n'impose pas de faire une forteresse numérique dès qu'on crée un site web (heureusement)

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

            • [^] # Re: Yakafokon

              Posté par . Évalué à 6.

              Bah non, si tu n'es pas capable de faire les choses conformément à la loi et aux bonnes pratiques avec les moyens que tu as, tu ne les fait pas.

              Ouvre une petition pour demander la fermeture de linuxfr.

          • [^] # Re: Yakafokon

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

            OK, je note : faire une chose gratuitement excuse de tout.

            C'est pas une excuse, c'est une explication. Quand on reçoit un service de bénévoles qui font sur leur temps libre, faut pas s'attendre a un niveau de qualité maximale. Non pas que ça soit normal; juste, faut pas s'attendre a la lune.

            • [^] # Re: Yakafokon

              Posté par . Évalué à 2.

              Quand on reçoit un service de bénévoles qui font sur leur temps libre, faut pas s'attendre a un niveau de qualité maximale. Non pas que ça soit normal

              Jolie oxymore :)

            • [^] # Re: Yakafokon

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

              faut pas s'attendre a un niveau de qualité maximale

              Et dans les faits, t'as des chances d'avoir quand même une bonne sécurité, voire meilleure que chez certains acteurs commerciaux (qui eux ont l'argent kivabien pour faire cekilfau).

              Par exemple, Free stocke les mdp des comptes mail en clair dans sa bdd. Comment je le sais ? Tu te connectes sur ton compte abonné (pas le compte mail, hein, celui de la ligne adsl), tu demandes à recevoir les mdp des comptes mail, et hop, tu les reçois en clair dans ta boîte mail. Ta boîte mail ! Genre le mail n'est pas l'équivalent d'une carte postale ? #Lol

              It's a fez. I wear a fez now. Fezes are cool !

              • [^] # Re: Yakafokon

                Posté par . Évalué à 3.

                Ça veut pas dire qu'ils le stockent non chiffré, peut-être que l'algo est réversible, et qu'ils utilisent une clé dans l'appli.

                Bon, ok, j'y crois moyen moi aussi, mais tu ne peux pas présumer d'un fonctionnement alors que tu n'en vois qu'un si petit morceau.

                • [^] # Re: Yakafokon

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

                  Tu as tout fait raison. Mais le résultat est là : une sécurité en carton. Un mot de passe ne devrait jamais pouvoir être retrouvé, que ce soit avec une clé ou parce qu'il est en clair. De la même façon, il ne devrait jamais être envoyé par mail.

                  Je ne me rappelle plus du site, mais y en avait un qui m'avait envoyé login/mdp en clair par mail après l'inscription. Euh, ça sert à quoi à part permettre qu'on me pique mon compte plus facilement ?

                  It's a fez. I wear a fez now. Fezes are cool !

          • [^] # Re: Yakafokon

            Posté par . Évalué à 8.

            je n'ai aucune compétance sur le sujet et des erreurs

            Et ben si t'as rien a dire, le dit pas. T'es pas oblige d'avoir un avis sur tout et de t'exprimer sur le moindre journal/commentaire.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Halte à la paranoïa

    Posté par . Évalué à 7.

    Il n'y a eu aucune vérification que le système n'est plus vérolé,

    Si tout le système est vérolé cela implique qu'une faille permettant l'élévation de privilège du compte Elasticsearch ait été exploitée. Non ?

    aucune vérification que les données des utilisateurs n'ont pas été leakées

    Tu penses bien aux mots de passe je suppose ? Parce que (presque) tout le reste des données des utilisateurs est publique (sauf ses préférences en fait).

    J'ai du mal à croire qu'ES puisse accéder aux hash des mots de passe qui doivent se trouver dans une BDD. Mais effectivement si un attaquant récupère ces hash cela lui permet de faire une tentative de brute-force…

    • [^] # Re: Halte à la paranoïa

      Posté par . Évalué à 10.

      Il n'y a eu aucune vérification que le système n'est plus vérolé,

      Si tout le système est vérolé cela implique qu'une faille permettant l'élévation de privilège du compte Elasticsearch ait été exploitée. Non ?

      Tout a fait, j'avais lu que LinuxFR utilisait beaucoup LXC (c'est d'ailleurs une des raisons pour laquelle ils utilisent ubuntu server). J'ose espérer que Elastic Search est dans un autre container que le serveur d'application et la base de donnée, ainsi que Elastic Search se connecte à la base de donnése avec des permissions sur mesure. (Et connaissant le niveau technique de l'équipe de LinuxFR, ça m'étonnerais beaucoup que ce ne soit pas le cas.)

      Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

  • # too much

    Posté par . Évalué à -10. Dernière modification le 17/07/14 à 14:04.

    La sécurité ils l'ont pris en compte, manque de bol, c'était

    mentionné nulle part dans ce qui sert de doc [ndr: doc d'ES]

    Quote tirée de tes liens.

    … Il faut activement moinsser ce journal. Et éventuellement en re poster un nouveau, plus constructif, pour parler de la sécurité de lfr. Qui c'est qui se tente pour lancer un metasploit ?

    • [^] # Re: too much

      Posté par . Évalué à 4.

      Qui c'est qui se tente pour lancer un metasploit ?

      Ça ne me semble pas une bonne idée de suggérer que n'importe qui puisse le faire pour le bien commun. D'ailleurs je crois que même pour le bien commun, chez pas mal d'hébergeurs, c'est tout simplement interdit, non?

      • [^] # Re: too much

        Posté par . Évalué à 1.

        L'hébergeur tu lui demandes une dérogation et c'est ok.

        Au sujet de la suggestion, tout ce que je peux dire dans l'immédiat, c'est que ta quote est mal habile pour le coup ; )
        Après je vois ce que tu veux dire, mais tu n'as pas idée comme cela me désespère. EnnnnnnnnnnnnnNfin BreF!

  • # bof

    Posté par . Évalué à 10.

    Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte ?

    Pas vraiment, en fait pour des raisons historiques, mon compte linuxfr est sur un compte mail différent de ma boite principal actuelle et date de l'époque où j'avais un groupes de logins et des mots de passes différents pour tous les sites; j'étais parano, et je n'étais inscrit que sur quelques sites.

    Historiquement mon mot de passe sur linuxfr est faible (trop court, pas assez varié), mais aussi unique, et n'a pas du changer depuis sa création; si quelqu'un le trouve, tout ce qu'il aura c'est accès à mon compte linuxfr, qui lui même n'est rattaché à aucune identité; tout ce que peu faire un pirate c'est nuire à mon karma.

    Ce qui serait vraiment hallucinant c'est quelqu'un qui veut faire attention à sa sécurité sur linuxfr utilise le même mot de passe ailleurs :D

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

  • # Un peu trop d'interprétation

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

    Du code arbitraire a pu être exécuté depuis le début de la version RoR de linuxfr

    -> Je ne crois pas que elasticsearch soit là depuis le début.

    La faille a été exploitée pendant plus d'une semaine

    -> La faille a consisté à (au moins) générer un flux UDP en sortie.

    La réponse est uniquement de désactiver le service problématique

    -> Non, la réponse immédiate est de désactiver le service. Il me semble que c'est la procédure normale, résoudre l'incident pour remettre en route et ensuite résoudre le problème pour une solution longue durée.

    Il n'y a eu aucune vérification que le système n'est plus vérolé, aucune vérification…

    -> Il faudrait utiliser l'outil de suivi pour voir si quelque chose est prévu mais faute de vacances, rien n'avance vite. Mais d'après ce que j'ai compris, elasticsearch tournait sur son propre utilisateur et le compte a été désactivé.

    Christophe

    • [^] # Re: Un peu trop d'interprétation

      Posté par . Évalué à -2.

      -> Je ne crois pas que elasticsearch soit là depuis le début.

      Je t'avoue que c'est le seul point que je n'ai vérifié. Cependant on est dans le point de détail : cela fait largement plus d'un an que la recherche, qui utilise la version problématique d'elasticsearch (pré-1.2.0) est utilisée.

      -> La faille a consisté à (au moins) générer un flux UDP en sortie.

      Tout est dans le "au moins". La faille permet d'exécuter du code arbitraire. Tu as constaté que un flux UDP a été généré, rien ne te permet de dire que rien de plus n'a été fait.

      -> Non, la réponse immédiate est de désactiver le service. Il me semble que c'est la procédure normale, résoudre l'incident pour remettre en route et ensuite résoudre le problème pour une solution longue durée.

      Non, la procédure normale en sécurité est d'arrêter la machine vérolée, et d'assurer la continuité de service à partir d'un état que l'on sait sain. Pas de continuer avec une machine potentiellement vérolée qu'on n'a pas audité.

      -> Il faudrait utiliser l'outil de suivi pour voir si quelque chose est prévu mais faute de vacances, rien n'avance vite. Mais d'après ce que j'ai compris, elasticsearch tournait sur son propre utilisateur et le compte a été désactivé.

      Moi, j'ai regardé l'outil de suivi, et je n'ai rien vu.

      Bref, tu es administateur, et, si ta position représente celle de la team linuxfr, ça confirme ce qui est dit dans le journal : la sécurité de linuxfr est prise en compte de façon ultra-légère.

      • [^] # Re: Un peu trop d'interprétation

        Posté par . Évalué à 2.

        Non, la procédure normale en sécurité est d'arrêter la machine vérolée, et d'assurer la continuité de service à partir d'un état que l'on sait sain. Pas de continuer avec une machine potentiellement vérolée qu'on n'a pas audité.

        Bienvenue en 2014. On t'a déjà dit pour la virtualisation ?

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: Un peu trop d'interprétation

          Posté par . Évalué à 0. Dernière modification le 17/07/14 à 13:54.

          Bienvenue en 2014. On t'a déjà dit pour la virtualisation ?

          Oui. On m'a aussi dit que personne n'a confirmé que elasticsearch est sur une vm isolée.

          Et on m'a surtout dit que pour isoler correctement les conteneurs LXC (qui sont utilisés sur dlfp), il y a un certain nombre de subtilités à prendre en compte (devices, utilisateurs utilisés, règles selinux…). Vu comment la subtilité du dynamic scripting d'elasticsearch a été prise en compte, et ce malgré la documentation abondante sur le net, je pense avoir le droit d'être méfiant.

      • [^] # Re: Un peu trop d'interprétation

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

        Je suis tagué administrateur parce que j'héberge le xmpp mais je n'ai aucun accès particulier sur la partie web. D'après ce que je suppose, seul le compte elasticsearch a été atteint et ça explique pourquoi rien d'autre n'a été coupé. Si "on" coupe le reste, pas sûr que ce soit relancé avant quelques semaines à cause des vacances. Il n'y a pas de solution idéale mais supposons un instant que des données soient volées, couper le service ne fera pas revenir les données comme les moutons du berger. Il faut attendre pour savoir ce qui a été fait et ensuite pour avertir si besoin mais j'ai seulement l'impression qu'il n'y a pas personne pour s'en occuper actuellement : tout le monde est bénévole, problème de vacances, et manque de temps libre.

        Christophe

        • [^] # Re: Un peu trop d'interprétation

          Posté par . Évalué à 10.

          tout le monde est bénévole, problème de vacances, et manque de temps libre.

          Un peu comme papatte3 qui, après avoir épuisé les moules par ses trolls incessants sur la tribune, vient le faire ici.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Un peu trop d'interprétation

        Posté par . Évalué à 8.

        Tu es prêt à payer un admin sys pour linuxfr, c'est gentil ;)

        Non, la procédure normale en sécurité est d'arrêter la machine vérolée, et d'assurer la continuité de service à partir d'un état que l'on sait sain

        C'est gentils mais reprendre le site d'il y a 1 ou 2 ans c'est autre chose que repartir 1 ou 2 semaines, sans oublier que certains vont avoir oublié les mots de passes de l'époque. La problématique des mots de passes a été suffisamment abordée ici pour que ceux qui se soucient de sécurité aient un mot de passe unique.

        Il faut aussi différencier ce que l'on considère comme critique (par exemple le site d'une banque ou de paiement qui voie passer des n° de CB) de ce qui l'est pas. Et désolé mais je ne considère par linuxfr comme critique, et de ce fait je préfère une solution qui a le moins d'impact sur son usage.

        Bref ton niveau d'exigence dépasse de très loin ce que j'estime nécessaire pour un site bénévole n'ayant rien de critique (y'a même plus les messages privés).

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

      • [^] # Re: Un peu trop d'interprétation

        Posté par . Évalué à 9.

        Non, la procédure normale en sécurité est d'arrêter la machine vérolée, et d'assurer la continuité de service à partir d'un état que l'on sait sain. Pas de continuer avec une machine potentiellement vérolée qu'on n'a pas audité.

        je crois qu'un moment donné faut se calmer aussi, on est sur un site de news géré par des bénévoles, pas sur une plateforme nationale de paiement bancaire ou autre infrastructure ultra sensible…

      • [^] # Re: Un peu trop d'interprétation

        Posté par . Évalué à 10.

        Bref, tu es administateur, et, si ta position représente celle de la team linuxfr, ça confirme ce qui est dit dans le journal : la sécurité de linuxfr est prise en compte de façon ultra-légère.

        Oui, supposons qu'un compte ait été volé, le malveillant aurait pu flooder le site en envoyant des dizaines de commentaires par jour sur tous les sujets. On ne serait pas dans la merde. J'ose espérer qu'un administrateur responsable digne de ce nom a sérieusement audité le compte de Zenitram.

        • [^] # Re: Un peu trop d'interprétation

          Posté par . Évalué à -3.

          J'ose espérer qu'un administrateur responsable digne de ce nom a sérieusement audité le compte de Zenitram.

          je propose une suppression volontaire du compte, (aussi dit suppression de confort)

      • [^] # Re: Un peu trop d'interprétation

        Posté par . Évalué à 7.

        -> Il faudrait utiliser l'outil de suivi pour voir si quelque chose est prévu mais faute de vacances, rien n'avance vite. Mais d'après ce que j'ai compris, elasticsearch tournait sur son propre utilisateur et le compte a été désactivé.

        Moi, j'ai regardé l'outil de suivi, et je n'ai rien vu.

        Oh my god ! DLFP n'a pas une SLA de 5h pour ça ! On est très loin de la gestion habituelle de sécurité. Si ça continue je vais demander remboursement !

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Un peu trop d'interprétation

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

        Non, la procédure normale en sécurité est d'arrêter la machine
        vérolée, et d'assurer la continuité de service à partir d'un
        état que l'on sait sain. Pas de continuer avec une machine
        potentiellement vérolée qu'on n'a pas audité.

        Pas forcément. D'une part, arreter la machine va détuire les processes en cours et donc des informations potentiellement intéressante.

        Ensuite, le but est aussi d'assurer la continuité du service si possible. Dans le cas d'une banque, la perte en réputation est tel que tu peux difficilement prendre le risque que la machine soit vérolé. Dans le cas de linuxfr et aux vues des réactions des gens icis, ils estiment que la continuité passe avant tout. C'est leur droit, et visiblement, entre couper tout linuxfr ou couper à minima et fouiller aprés, ils ont choisi.

        Bien sur, tu peux faire un choix différent, mais c'est eux les admins et le concept de responsabilité fait qu'ils ont toute latitude dans le fait de choisir en ignorant ou pas tes arguments.

  • # Front de défence du bot Zenitram !

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

    Cette lenteur est en fait dûe à un problème de sécurité (…) qui a permis à des bots floodeurs de s'exécuter. Comme on peut voir dans le lien, les admins linuxfr ont (…) verrouillé le compte concerné.

    Pour ce bot là, ok, on peut le supprimer car il a fait ramer le site ! Mais il ne faut pas non plus que les admin fasse de l’excès de zèle. Sans Zenitram (qui relance en boucle les mêmes discussions) Linuxfr ne serait pas un site aussi actifs ! Donc, non, ne verrouillez pas son compte !

    À propos, quelqu’un sait où l’on peut télécharger le code source de Zenitram ? Il est libre au moins ?

    --> []

  • # Gros poutous à toi aussi

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

    Si je résumé tes propos, tu ne peux pas vraiment savoir de quoi tu parles ou quelles sont les mesures prises actuellement (vu que tu n'es pas dans l'équipe du site), tu ne connais pas la doc, le code ou la conf' des serveurs, tu t'empresses de faire un journal qui dénonce grave à chaud (à coup de présupposés évidemment) et tu voudrais comparer avec la sécurité des autres sites web ?

    Concernant les mesures en cours, l'équipe d'adminsys travaille sur le sujet et communiquera par la suite comme elle l'a fait précédemment (en fidèle lecteur attentif, tu as sûrement déjà noté les divers annonces concernant le code publié sous licence libre, la configuration de serveurs, les dépêches sur la sécurité et le site, etc., etc.). Dans l'immédiat, plutôt que jouer à la communication de crise à chaud et sans toutes les infos, il est plus utile de s'intéresser pour l'instant à la partie technique.

    Pour contribuer au site, la partie plan fournit tous les liens utiles.

    Concernant ce journal, à titre personnel, je le trouve malvenu, accusateur, provocateur à deux sous et factuellement erroné. Les questions posées sont par contre de bonnes questions auxquelles il conviendra de répondre (comme on l'a fait précédemment dans les cas de pannes matérielles, logicielles ou d'autres soucis de sécurité).

    Enfin concernant la comparaison entre un site à accès gratuit géré par des bénévoles et d'autres sites du même type ou des sites commerciaux, avec ou sans pub, à accès payant ou non, gérant des données personnelles ou non, nous sommes malheureusement à mon avis plutôt dans le haut du panier : trop peu de sites ont une configuration de courriel comme la nôtre, trop peu ont des sites accessibles en HTTPS uniquement, ont des discussions sur TLS et les certificats, sur GPG, trop peu de sites ont des versions à jour des logiciels, trop de sites ont encore des mots de passe non hashés pour renvoi par courriel, trop de sites ne gèrent pas le spam aussi efficacement que nous, etc. Et pourtant, tout n'est pas parfait, idéal et ultime. Et pourtant, je (et plus largement l'équipe d'adminsys) ne trouve pas la situation satisfaisante et le travail continue encore et toujours pour améliorer divers points.

    Bref nous sommes preneurs d'entrées de suivi quand des problèmes de fonctionnement ou de sécurité sont constatés ; nous sommes preneurs de développeurs pour aider à ajouter des fonctionnalités, corriger des bugs et améliorer le site et ses services ; nous sommes preneurs d'adminsys pouvant aider à gérer le site et ses services ; et nous sommes preneurs de libristes qui contribuent, participent, suggèrent, conseillent et aident, comme il se doit (ou se devrait) dans les communautés du libre.

    Gros poutous à toi aussi.

    • [^] # Re: Gros poutous à toi aussi

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

      trop peu ont des sites accessibles en HTTPS uniquement

      Mais beaucoup ont un certificat sérieux!

      Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Gros poutous à toi aussi

      Posté par . Évalué à -9.

      trop peu ont des sites accessibles en HTTPS uniquement, ont des discussions sur TLS et les certificats

      et

      Concernant les mesures en cours, l'équipe d'adminsys travaille sur le sujet et communiquera par la suite comme elle l'a fait précédemment (en fidèle lecteur attentif, tu as sûrement déjà noté les divers annonces concernant le code publié sous licence libre, la configuration de serveurs, les dépêches sur la sécurité et le site, etc., etc.).

      Dois-je déduire de ces deux phrases que le certificat SSL de linuxfr a été révoqué puis changé, et qu'une communication a été faite à ce sujet suite à la faille heartbleed ?

      • [^] # Re: Gros poutous à toi aussi

        Posté par . Évalué à 10.

        Je crois que sur ce site il existe un service appelé elasticsearch qui pourrait t'aider à répondre à ta question.

      • [^] # Re: Gros poutous à toi aussi

        Posté par . Évalué à 8.

        C'est curieux mais je cherche ton entrée dans le suivi à ce sujet, et je ne la trouve pas.

  • # Un peu rapide les conclusions...

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

    La réponse est uniquement de désactiver le service problématique

    Ah bon ? Tu fais partie des admin sys du site ? Tu sais exactement ce qu'ils sont en train de faire ?

    Il n'y a eu aucune vérification que le système n'est plus vérolé, aucune vérification que les données des utilisateurs n'ont pas été leakées, et en plus il n'y a aucune indication qu'il est prévu de le faire

    Ah bon ? Tu fais partie des admin sys du site ? Tu sais exactement ce qu'ils sont en train de faire ?

    Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte

    Oui, ou en tout cas, je pense que rare sont les personnes qui trouvent que le problème est pris à la légère.
    À moins qu'avant d'écrire ce journal alarmiste, voire incendiaire, tu ai pris le temps de contacter les admins du site pour te renseigner, et mon petit doigt me dit que ce n'est pas le cas, je pense que tu t'emportes sans prendre le temps de te renseigner, ce qui me parait déplacé envers les gens qui consacrent du temps à avoir une attitude plus constructive.
    Surtout sur Linuxfr où l'on a l'habitude de voir l'équipe aux commandes communiquer sur les incidents/évolutions qui construisent la vie du site.

    Mais c'est vrai, écrire un journal qui dénonce grave est sûrement plus tripant que prendre le temps de se renseigner…

    Accessoirement, pour répondre également à l'un de tes commentaires, en sécurité, quand une machine est vérolée, autant que possible, on ne l'éteint pas. On l'isole du reste du monde, et on la laisse allumée pour qu'il soit possible d'établir des diagnostiques dessus.

  • # Merci

    Posté par (page perso) . Évalué à 10. Dernière modification le 17/07/14 à 16:53.

    • Merci aux moules d'avoir remonté le problème dès le début, sur la tribune puis sur le suivi.
    • Merci aux équipes d'admins de dlfp d'avoir investigué sur le problème
    • Merci à la Fondation Free d'héberger dlfp

    Ce n'est pas un commentaire qui dénonce grave, mais un commentaire qui enfonce des portes ouvertes. LOL pan

    ps : très beau déroulé, ton nourjal, belle réussite. on a failli y croire que c'était grave !

  • # Oui

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

    » Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte ?

    De toute évidence, t'as pas prouvé que ton opinion était bien fondée. En gros, ton avis, une grosse partie des commentateurs de ce journal trouvent qu'il est nul. Et si tu me le demandais, je dirais qu'ils ont raison.

    Voilà ♪

    • [^] # Re: Oui

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

      Et si tu me le demandais, je dirais qu'ils ont raison.

      d'autant qu'il y a un historique de transparence de l'équipe concernant les évolutions, ce qui transparaît dans les communications régulières avec le tag dlfp

  • # OUI

    Posté par . Évalué à 6.

    Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte ?

    Pour commencer, il y a quoi comme données à sécuriser ?
    - seul ton mot de passe pour pouvoir poster sur le site est "secret". La sécurisation de ce mot de passe
    c'est a toi de la faire : mot de passe unique, fort, et changé tous les mois.

    Pour finir : demande l'effacement de ton compte ainsi qu'un remboursement.

    cordialement

  • # Commentaire supprimé

    Posté par . Évalué à 8. Dernière modification le 19/07/14 à 18:52.

    Ce commentaire a été supprimé par l'équipe de modération.

Suivre le flux des commentaires

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