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 modr123 . É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 Nicolas Boulay (site web personnel) . É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 yohann (site web personnel) . É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 barmic . É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 Anonyme . Évalué à -3.
Avec des épices ?
[^] # Re: tu as raison
Posté par Nicolas Boulay (site web personnel) . É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 khivapia . É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 aurel . Évalué à -3.
Clair. Sinon à ce compte-là, autant mettre du poivre.
# Précision sur les aspects légaux
Posté par papatte3 . É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 patapon . É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 Nonolapéro . Évalué à 10.
Tes capacités d'administrateur ou de développeur sont attendues ? Plus d'informations sont disponibles sur participer-a-linuxfr.
[^] # Re: Yakafokon
Posté par lolop (site web personnel) . Évalué à 1.
Je dirais même plus: Tes capacités d'administrateur ou de développeur sont attendues !
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Yakafokon
Posté par papatte3 . Évalué à 5.
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 paulez (site web personnel) . É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 papatte3 . Évalué à 2.
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 Axel . É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 Maclag . Évalué à 10.
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 fearan . Évalué à 8.
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 Rémi PALANCHER (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 17 juillet 2014 à 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 papatte3 . Évalué à 1.
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 claudex . É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 Zenitram (site web personnel) . Évalué à -1. Dernière modification le 17 juillet 2014 à 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 Dr BG (site web personnel) . Évalué à 4.
Ah bon, où ça au fait ?
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 paulez (site web personnel) . É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 barmic . Évalué à 7.
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 Dr BG (site web personnel) . É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 fearan . É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 Anonyme . Évalué à 6.
Ouvre une petition pour demander la fermeture de linuxfr.
[^] # Re: Yakafokon
Posté par rakoo (site web personnel) . Évalué à 4.
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 Thomas Douillard . Évalué à 2.
Jolie oxymore :)
[^] # Re: Yakafokon
Posté par Framasky (site web personnel) . Évalué à 3.
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
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Yakafokon
Posté par hermenegilde . É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 Framasky (site web personnel) . É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 ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Yakafokon
Posté par groumly . Évalué à 8.
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 Marotte ⛧ . Évalué à 7.
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 ?
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 Ife . Évalué à 10.
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 maboiteaspam . Évalué à -10. Dernière modification le 17 juillet 2014 à 14:04.
La sécurité ils l'ont pris en compte, manque de bol, c'était
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 Maclag . Évalué à 4.
Ç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 maboiteaspam . É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 fearan . Évalué à 10.
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 rootix . É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é.
[^] # Re: Un peu trop d'interprétation
Posté par papatte3 . Évalué à -2.
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.
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 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é.
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 2PetitsVerres . Évalué à 2.
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 papatte3 . Évalué à 0. Dernière modification le 17 juillet 2014 à 13:54.
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 rootix . É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.
[^] # Re: Un peu trop d'interprétation
Posté par 2PetitsVerres . Évalué à 10.
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 fearan . Évalué à 8.
Tu es prêt à payer un admin sys pour linuxfr, c'est gentil ;)
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 Dabowl_75 . É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 gnx . Évalué à 10.
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 ckiller . Évalué à -3.
je propose une suppression volontaire du compte, (aussi dit suppression de confort)
[^] # Re: Un peu trop d'interprétation
Posté par barmic . Évalué à 7.
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 Misc (site web personnel) . Évalué à 6.
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 Diagonale de Cantor (site web personnel) . Évalué à 8.
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 ?
--> []
[^] # Re: Front de défence du bot Zenitram !
Posté par CHP . Évalué à 3.
http://www.ensembl.org/Homo_sapiens/Info/Index
# Gros poutous à toi aussi
Posté par Benoît Sibaud (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 9.
Mais beaucoup ont un certificat sérieux!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gros poutous à toi aussi
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Oui comme Google a des certificats sérieux, et comme ça la sécurité est bien meilleure, les gens sont contents et le monde est merveilleux. Cf le récent Indian government agency issues fake Google certificates (c'est au moins la 3è fois - et sans doute bien plus - pour Google d'ailleurs).
[^] # Re: Gros poutous à toi aussi
Posté par papatte3 . Évalué à -9.
et
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 pudbou . É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 Maclag . É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 Xavier Teyssier (site web personnel) . É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 bubar🦥 (site web personnel) . Évalué à 10. Dernière modification le 17 juillet 2014 à 16:53.
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 Axioplase ıɥs∀ (site web personnel) . É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 BAud (site web personnel) . Évalué à 4.
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 Guillaume D. . Évalué à 6.
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 Anonyme . Évalué à 8. Dernière modification le 19 juillet 2014 à 18:52.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Chère bombe fourchette, bomba fork à steack alias ... alias papatte3<,
Posté par papatte3 . Évalué à -3.
Je suis content que tu évoques ce problème, en effet :
Ce n'est pas une injection de css, cela permet uniquement d'ajouter la classe css "highlighted" à des éléments arbitraires.
Si les problèmes de sécurité de linuxfr étaient aussi réduits et résolus aussi rapidement, je n'aurais pas écrit de journal.
[^] # Re: Chère bombe fourchette, bomba fork à steack alias ... alias papatte3<,
Posté par Thomas Douillard . Évalué à 4.
C'est marrant pourtant j'aurai pas spécialement confiance si tu étais membre de l'équipe de sécurité de linuxfr /o\
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 19 juillet 2014 à 19:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Chère bombe fourchette, bomba fork à steack alias ... alias papatte3<,
Posté par hermenegilde . Évalué à 2.
http://linuxfr.org/suivi/robots-txt-pour-les-outils-d-archivage-web
[^] # Re: Chère bombe fourchette, bomba fork à steack alias ... alias papatte3<,
Posté par hermenegilde . Évalué à 2.
Arf, je me souviens combien papatte3< m'avait vraiment faire ch**r là dessus à l'époque où j'avais commencé à faire Olccs. Je m'interroge encore sur sa motivation à refaire un truc d'archivage quand on a sorti tout ce qu'il m'avait sorti à ce moment là.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.