Argos Panoptès, l’interview

Pour Framaspace, Framasoft a fait développer un outil de supervision de sites web nommé Argos Panoptès (ou juste Argos pour aller plus vite).

Développé par Alexis Métaireau, développeur entre autres du générateur de site statique Pelican, et de l’outil de gestion de dépenses à plusieurs « I Hate money » (repris dans l’app cospend sur Nextcloud), le besoin a été défini par Luc Didry, l’administrateur système de Framasoft.

Luc et Alexis répondent à nos questions dans cet interview, pour plus d’information concernant Argos vous pouvez consulter l’article dédié.

Bonjour à tous les deux 🙂 Ici on connaît déjà Luc puisque c’est notre admin sys préféré, mais Alexis, peux-tu nous dire qui tu es pour le framablog ?

Alexis : Bonjour, Framasoft, et merci pour la discussion ! Et bien, c’est parti pour l’exercice de la présentation alors.

Je suis un développeur de bientôt 40 ans, intéressé par les dynamiques collectives, le logiciel libre et la protection des données personnelles, depuis quelques années maintenant. Par le passé j’ai pu publier et maintenir quelques outils comme Pelican, un générateur de sites statiques et I hate money, pour gérer les dépenses partagées. J’ai travaillé quelques années pour Mozilla sur la partie synchronisation et chiffrement des données (Firefox Sync, Kinto) et sur quelques autres outils.

J’ai quitté le développement « pro » entre 2018 et 2023. Durant ces années j’ai eu la chance / le privilège de pouvoir monter une brasserie sur Rennes avec un ami. Nous avons essayé de faire vivre les valeurs de la collaboration (plutôt que celles de la compétition). Cela est resté très proche des valeurs du logiciel libre, nos recettes et les plans de nos machines étant par exemple publiés sur notre site web.

À l’été 2023 j’ai décidé de quitter la brasserie pour à la fois refaire du développement et travailler sur les outils de la prise de décision collective, et la gestion des conflits dans les collectifs. C’est à ce moment que nous sommes rentrés en contact avec Luc pour travailler sur Argos.

Pouvez-vous nous présenter l’outil Argos sur lequel vous avez travaillé ? À quel besoin répond-il pour Framaspace ?

Alexis : Argos est un outil de supervision de sites web. L’idée est assez simple: surveiller que les sites vont bien, et générer des alertes quand c’est utile, en envoyant des notifications par email ou autre.

La spécificité d’Argos est de pouvoir gérer un nombre de sites important. Framaspace, en grossissant, expose pas loin de 900 domaines au public, qui parfois tombent en panne. Je crois que le réel besoin derrière Argos était de simplifier la vie de Luc (vous saviez qu’il n’y avait qu’un seul adminsys chez Framasoft ?!!) et de lui permettre d’avoir une meilleure vision globale de l’état du service.

Les vérifications concernent les statuts du site web, mais aussi l’état des certificats SSL, par exemple, et quelques vérifications spécifiques.

Luc : On surveillait déjà plus de 200 sites via notre outil de supervision (Shinken), mais celui-ci, avec toutes les autres sondes de supervision de notre infrastructure, avait bien de la peine à repasser toutes les 5 minutes sur les sites. Ce qui faisait qu’on pouvait se rendre compte qu’un site était tombé au bout de trop de temps.

Avec Framaspace, je savais que j’aurai des centaines (et à terme des milliers) de sites à surveiller en plus, sachant qu’un site est la cible de plusieurs vérifications, comme dit par Alexis. Il fallait donc un outil dédié.

Les outils existants comme statping-ng ou Uptime Kuma présentent un défaut rédhibitoire : vouloir afficher l’état de chaque site en même temps sur l’interface web. Ça va bien quand on a quelques sites, pas quand on en a des centaines (l’outil peine à envoyer les données de centaines de sites).

C’est de là qu’est née l’idée d’Argos, qui a le bon goût de n’afficher qu’un résumé de l’état des sites par défaut.

 

4 blocs avec des statuts (inconnu, ok, avertissement, erreur) et pour chacun, un nombre correspondant.
Capture d’écran de la page de statut d’Argos

 

Si on regarde de plus près les coutures, on voit que c’est développé en langage Python avec une base de données en PostgreSQL. Laissez-moi deviner : Alexis a choisi Python et Luc a choisi PostgreSQL ?

Alexis : Ah, je vois que tu nous connais un peu, mais figure toi que même pas ! J’aurais aimé plaider coupable pour le coup, mais Luc cherchait spécifiquement quelqu’un qui savait faire du Python, et c’est comme ça qu’on s’est rencontré. J’ai proposé d’utiliser le framework FastAPI à la place de Flask parce que ça nous permettait de faire de l’asynchrone de manière plus simple, et d’utiliser les fonctionnalités de typage de Python.

Luc : Pour Framaspace, j’ai été plus ou moins obligé de faire du Python car Salt, l’orchestrateur utilisé pour déployer les espaces est en Python : je pouvais, en utilisant ce langage, l’utiliser comme une bibliothèque, sans utiliser de bidouilles sales.

Comme Argos a été créé dans le cadre de Framaspace, j’ai voulu garder le même langage de programmation, pour avoir un tout cohérent.

Python n’est pas un langage si pire que ça. Il n’est pas amusant, mais ça fait le job. Peut-être aussi que je vieillis : j’utilise de plus en plus Python pour des scripts. Peut-être qu’écrire des scripts ne m’amuse plus, et que je veux les écrire vite pour passer à autre chose.

Mème the Rock qui conduit - Et ton machin va être en Perl, comme d'hab - Non j'ai choisi Python cette fois The rock se retourne, interloqué

La question habituelle de libriste : pourquoi avez-vous choisi de développer un outil dédié, il n’existait pas d’outils libres pour de la supervision ? Quelles sont ses spécificités ?

Alexis : Je te laisse répondre Luc, c’est toi qui a affiné le besoin 🙂

Luc : Ah bah zut, j’ai déjà répondu au-dessus 😅

L’avantage d’avoir notre propre outil nous permet aussi de le tordre pour nos besoins spécifiques. Ainsi Argos envoie-t-il des notifications à notre serveur Gotify. Intégrer un tel canal de communication dans un outil existant aurait pu prendre du temps (comprendre le code, faire une PR, attendre une release…).

En lisant la doc, ça a l’air tout simple à utiliser par rapport à d’autres outils !! Comme administrateur⋅ice système du dimanche après-midi, si je veux surveiller l’état de mes sites, est-ce qu’il y a des pièges ou des choses à savoir ?

Alexis : Je pense que ça pourrait tout à fait permettre de surveiller l’état de quelques sites, bien que peut-être surdimensionné. Argos a besoin de lancer un serveur, une base de données et des agents. Est-ce bien utile pour un⋅e adminSys du dimanche ? Peut-être !

Luc : Franchement, je pense qu’il peut être utilisé aussi bien par une grosse organisation que par un·e adminSys du dimanche. La configuration est simple, l’installation pas très compliquée, et il n’a pas l’air de consommer beaucoup de ressources.

Alexis tu étais en mode prestation pour développer, comment s’est passée la relation avec Framasoft ?

Alexis : Franchement, c’était une surprise totale, et un plaisir du début à la fin. On a d’abord pu se faire quelques appels avec Luc pour clarifier les besoins, je me suis retrouvé avec une liste de fonctionnalités de base, et j’ai avancé comme ça.

Quand j’avais besoin j’ai pu échanger avec Luc qui était toujours assez réactif, et j’ai pu lever quelques blocages. J’ai beaucoup apprécié répondre à un besoin concret, en ayant l’utilisateur final au bout du fil pour clarifier les choses.

Par la suite, on a pu se faire quelques sessions ensemble, à la fois de présentation de l’outil, puis de pair-programming pour accompagner Luc sur certains aspects quand c’était utile, l’idée étant que ce soit lui qui prenne la main sur le projet.

C’était en fait ma première mission en tant que « prestataire », je crois que je suis très bien tombé !

Luc : Pareil de mon côté, c’était très agréable de bosser avec toi !

Est-ce que vous pensez que ça peut être utilisé dans d’autres contextes que Framaspace ?

Alexis : je pense que ça peut être utilisé dans d’autres contextes bien sûr. Je pense aux « fermes de sites », comme par exemple ce que peut faire NoBlogs en Allemagne, mais de manière générale c’est utile d’avoir un outil simple d’accès pour faire de la supervision. Bosser là-dessus m’a donné envie de permettre de faire de la supervision « en tant que service », pour des collectifs pour qui ce serait utile, mais… j’imagine que c’est une autre histoire.

Luc : Carrément ! Pas seulement pour des fermes de sites mais partout où on a besoin d’une supervision qui passe très régulièrement. On peut avoir des vérifications effectuées toutes les minutes, ce qui peut être utile sur des sites qui ne doivent pas tomber. Et un grand nombre de sites ne devrait pas faire peur à Argos : on peut multiplier le nombre d’agents (le logiciel qui s’occupe d’effectuer les vérifications et d’en remonter le résultat au serveur), et le choix de PostgreSQL comme base de données a (aussi) été fait parce que c’est un SGBD robuste qui peut encaisser de la charge de travail.

Et est-ce que vous imaginez une suite, avec une feuille de route ou des invitations à contribuer ?

Luc : Il y a déjà des idées de développements futurs pour améliorer Argos, mais ça n’est pas urgent : la première version est déjà tout à fait fonctionnelle.

Alexis : J’aime bien l’idée de ne pas avoir de feuille de route trop précise pour le futur, ce qui nous permet de se concentrer sur des besoins réels et de ne pas en faire une usine à gaz. Si vous l’utilisez et que vous avez des retours à faire, ou bien si vous souhaitez contribuer, n’hésitez pas. C’est pensé pour être simple à étendre, donc n’hésitez pas à jeter un œil et à proposer des changements.

Si vous avez encore des choses à dire 🙂

Alexis : Coucou Numahell, chouette de te recroiser par ici après ces quelques années 🙂

Luc : Merci à toi, Alexis, pour le temps bénévole que tu as consacré à Argos après ta prestation !

Pour aller plus loin




Argos Panoptès : la supervision de sites web simple et efficace

Un nouvel outil de supervision de sites web vient de sortir de la forge de Framasoft, tout beau, tout neuf, tout simple. Mais pourquoi ? On vous explique tout !

Le problème

Chez Framasoft, nous avons beaucoup de sites web. Vous connaissez les adresses de nos services, https://framacarte.org pour Framacarte, https://framapad.org pour les pads, etc.

Mais il y en a bien plus sous le manteau : nos outils associatifs (un Nextcloud, un Odoo, des wikis…), les versions de test des services (soit pour tester un nouvel outil, soit pour vérifier que la mise à jour se passera bien…), les sites des amis qu’on héberge (coucou Grisebouille, Affordance et les autres 👋), etc.

Comme je (nda : Luc) suis quelqu’un de plutôt méticuleux, tous nos sites sont supervisés, c’est-à-dire que nous avons un système qui vérifie périodiquement qu’ils fonctionnent bien, de façon à détecter rapidement un souci et le résoudre au plus vite.

Jusque là, nous utilisions Shinken pour toute notre supervision : aussi bien celle des sites web que celle des serveurs. Mais nous commencions à nous heurter à différents problèmes :

  • Shinken est en Python 2, une version totalement obsolète de Python, ce qui n’augure pas bien de la pérennité de l’outil (il est question d’une version en Python 3, mais qui se fait largement attendre)
  • nous avons trop de sondes (c-à-d de choses à superviser) pour que la vérification des sites se fasse suffisamment régulièrement à mon goût (je veux des tests toutes les 5 minutes, pas tous les quarts d’heure)

Nous devons migrer vers une autre solution de supervision, mais pour ça, il faut du temps que nous n’avons pas. Et Shinken fonctionne toujours, donc ce n’est pas une chose que je juge urgente.

Cependant, avec l’ouverture de Framaspace, le nombre de sites à surveiller allait nécessairement exploser (plus de 1 000 espaces à l’heure actuelle).

Il nous fallait donc une solution de supervision pour les sites pour éviter d’augmenter les problèmes de délai entre chaque vérification de site.

Anakin : « J’ai besoin d’un logiciel de supervision ». Padme, tout sourire : « Donc tu vas en prendre un qui existe ? ». Anakin ne dit rien et la regarde avec un rictus. Padme, inquiète : « Tu vas en prendre un qui existe, hein ? »

Une devise du monde Unix est « Un outil qui fait une chose et qui le fait bien ». Suivant cela, j’ai cherché des outils de supervision de sites web et de rien d’autre. J’ai trouvé statping-ng et Uptime Kuma.

Malgré leurs qualités, ces solutions souffrent du même problème : l’affichage sur la page d’accueil des résultats de toutes les sondes, avec l’historique des résultats sous forme d’une petite frise chronologique. Avec quelques sites à superviser, pas de souci. Avec plus de 100 sites, soit c’est l’affichage qui ne fonctionne plus, soit c’est le service lui-même qui peine… très fort !

Il nous fallait donc créer nous-même notre outil de supervision !

La solution

Comme la plupart des développeurs, j’ai commencé par le plus important : trouver un nom à notre logiciel ! 😅

Pour rester dans la thématique de la mythologie grecque des développements faits pour Framaspace, j’ai cherché sur le web et suis tombé sur Argos Panoptès, géant aux cent yeux, dont l’épithète Panoptès signifie « celui qui voit tout » (on se contentera de l’appeler « Argos » dans cet article)

La deuxième chose la plus importante dans le développement est… le temps disponible. Et nous n’en disposions pas. C’est pourquoi nous avons pris un prestataire, Alexis Métaireau, développeur entre autres du générateur de site statique Pelican, et de l’outil de gestion de dépenses à plusieurs I Hate money (repris dans l’app cospend sur Nextcloud), pour poser les bases d’Argos, en suivant notre cahier des charges.

Pour voir comment s’est passée notre collaboration, je vous renvoie à l’interview croisée d’Alexis et de votre serviteur.

La simplicité

Argos devait être simple pour être efficace. L’écran d’accueil est donc dépouillé du superflu et n’indique que le nombre de sites surveillés regroupés par état (inconnu, OK, attention, critique).

Capture d’écran de la page de statut d’Argos

Les mêmes informations sont aussi disponibles en JSON via un point d’API. À vous d’en faire ce que vous voulez, comme par exemple afficher une notification sur votre bureau si tout n’est pas au vert, déclencher un son… voire intégrer le résultat d’Argos dans votre solution de supervision pour tout avoir au même endroit ! L’API est auto-documentée sur le logiciel (la documentation est accessible depuis l’interface d’Argos).

La simplicité d’Argos réside aussi dans son mode d’installation : un simple pip install argos-monitoring aussi bien pour le serveur central que pour l’agent, une création d’une base de données PostgreSQL, un fichier de configuration en YAML et c’est tout. Avec ça, on a tout ce qu’il faut pour faire tourner le service.

La robustesse

Un mot : PostgreSQL. J’ai toute confiance en PostgreSQL pour encaisser une forte charge comme pourrait lui envoyer Argos.

Quelqu’un susurre « PostgreSQL » à l’oreille d’une autre personne, on voit un bras couvert de chair de poule

Plus concrètement, nous sommes passés de ±300 vérifications avant Framaspace à près de 2 000 en surveillant les espaces créés et Argos ne bronche pas.

Cela fait plusieurs mois maintenant que nous utilisons Argos en conditions réelles et passé la phase de débogage, ça se passe parfaitement bien 🥰

L’évolutivité

Vous ajoutez plein de sites et l’agent qui s’occupe de faire les vérifications et de les envoyer au serveur central ne suffit plus ? On peut ajouter autant d’agents supplémentaires que nécessaire en quelques minutes.

Vous voulez créer une nouvelle manière de vérifier que votre site fonctionne bien ? Le site de documentation est riche d’informations pour les développeur·euses et vous tend les bras 🙂

Les moyens de notifications actuels (mail et Gotify à l’heure de l’écriture de cet article) ne vous conviennent pas ? Le code, en Python, est très propre et il est très simple d’ajouter… à peu près n’importe quel moyen de communication, d’un webhook Mattermost à un SMS via une plate-forme quelconque.

Conclusion

Nous avons maintenant une solution de supervision spécialisée simple et efficace, flexible de par la simplicité de son code et qui nous donne déjà entière satisfaction.

Moins de fonctionnalités, moins de code. Moins de code, plus facile à modifier. Plus facile à modifier, plus facile à modifier.

Si Argos est déjà pleinement fonctionnel, il ne tient qu’à nous (et à la communauté !) de l’améliorer. Il y a déjà quelques tickets, majoritairement pour améliorer la documentation, mais pas que.

Est-ce qu’Argos Panoptès sera adopté par les administrateurices systèmes, du dimanche ou pas ? On verra bien !

Liens

Pour celleux qui se demandent pourquoi une queue de paon en image d’illustration de cet article : la déesse Héra a préservé, sur une queue de paon, les cent yeux d’Argos Panoptès après sa mort.




« I don’t want any spam ! »

Traduction : « Je ne veux pas de spam ! »

Le spam est un problème qu’à Framasoft, nous connaissons bien. Mais savez-vous à quel point ?
Je vais, dans cet article, vous dresser le tableau des soucis de spam que nous rencontrons et des contre-mesures que nous avons mises en place.

Avant cela, un peu d’histoire…

Qu’est-ce que le spam ?

Avant l’ère d’Internet, le spam n’était qu’une marque de viande en conserve.

Les Monty Python, humoristes anglais à qui l’on doit notamment les hilarants Sacré Graal ! et La vie de Brian, ont réalisé un sketch (version textuelle) dans lequel un couple, dans un restaurant, demande ce qu’il y a à la carte pour le petit déjeuner et où la serveuse ne propose que des plats avec du spam (et pas qu’un peu : « Spam, spam, spam, spam, spam, spam, baked beans, spam, spam, spam and spam. »). La femme du couple ne peut avoir de petit déjeuner sans spam, la serveuse ne lui proposant qu’encore plus de spam… (le titre de cet article est une citation de la femme du couple).

Un homme et une femme dans un restaurant
Capture d’écran du sketch des Monty Python sur le Spam

De ce sketch découle l’utilisation du terme spam pour les courriels indésirables (et tout autre message indésirable, quelle que soit la plateforme comme nous allons le voir).
De nos jours, le spam représente 50% des courriels échangés sur la planète.

Que serait une marque sans #CopyrightMadness ? Hormel Foods, l’entreprise derrière le spam a tenté d’utiliser le droit des marques pour éviter que le nom de son produit soit utilisé pour quelque chose dont personne ne veut et pour essayer d’empêcher d’autres entreprises d’utiliser le terme (comme des éditeurs de solutions anti-spam). Je croyais qu’Hormel Foods avait cessé cette lutte inutile, mais il semblerait que non, allant jusqu’à embêter Gee pour un dessin qu’il proposait sur RedBubble.

Un homme met un coup de pied dans une enveloppe pour l’envoyer dans une corbeille sur laquelle est marqué « spam »
Le dessin de Gee qui lui a valu une plainte d’Hormel Foods

Le spam dans les courriels

Chez Framasoft, nous sommes aux deux bouts de la chaîne : nous envoyons beaucoup de courriels (dans les 15 000 courriels par jour pour nos services – inscriptions, notifications, etc. – et plus de 200 000 courriels par jour pour Framalistes) et nous en recevons aussi, que ce soit au niveau de notre serveur de courriel interne ou sur Framalistes. Il y a aussi quelques autres services qui permettent d’interagir par courriel comme notre forum, Framavox et Framagit.

Deux astronautes regardant la terre. Une boîte de Spam est sur la terre. Le premier astronaute s’exclame « Mais le monde est plein de spam ! ». Le deuxième, un brassard « spam » sur le bras, braque un pistolet sur le premier astronaute et dit « Ça a toujours été ! »

Nous devons donc nous assurer, d’un côté, de ne pas passer pour des spammeur·euses et de l’autre, de nous en protéger.

Se protéger des spams par courriel

Rien de bien fantastique à ce niveau. Nous utilisons l’antispam Rspamd qui vérifie la validité du courriel par rapport à sa signature DKIM, à l’enregistrement SPF et à la politique DMARC du domaine (voir sur NextINpact pour un bon article sur le sujet). Bien entendu, cela ne vaut que si le domaine en question met en place ces mécanismes… On notera que la plupart des FAI français, s’ils vérifient bien les courriels entrants de la même façon que nous, se tamponnent allègrement le coquillard de mettre en place ces mécanismes pour leurs propres courriels. J’aimerais qu’un jour, ceux-ci arrêtent de faire de la merde 🙄 (remarquez, il semblerait que ça avance… très lentement, mais ça avance).

En plus de ces vérifications, Rspamd effectue aussi une vérification par filtrage bayésien, interroge des listes de blocage (RBL) et utilise un mécanisme de liste grise.

Thomas Bayes avec des yeux rouges (façon yeux laser)
Thomas Bayes analysant des courriels à la recherche de spam

Il y a toujours, bien évidemment des trous dans la raquette, mais le ratio spam intercepté/spam non détecté est assez haut et nous alimentons Rspamd avec les messages indésirables qui sont passés sous le radar.

Sur Framalistes, afin de ne pas risquer de supprimer de messages légitimes, nous avons forcé le passage des spams probables en modération : tout message considéré comme spam par Rspamd doit être approuvé (ou rejeté) par les modérateur·ices ou propriétaires de la liste.

(parenthèse technique)
Nous avons créé un scénario spam_status.x-spam-status dans Sympa :

title.gettext test x-spam-status  header

match([header->Subject][-1],/\*\*\*\*\*SPAM\*\*\*\*\*/) smtp,dkim,smime,md5 -> unsure
true()                                                  smtp,dkim,md5,smime -> ham

Et nous avons ajouté cette ligne à tous les scenarii de type send :

match ([msg->spam_status], /unsure/)   smtp,dkim,md5,smime   ->   editorkey

Le texte *****SPAM***** est ajouté au sujet du mail par Rspamd en cas de suspicion de spam. Si Rspamd est vraiment catégorique, le mail est directement rejeté.

Titre : « AdminSys, c’est pas drôle tous les jours. SPAM ou PAS SPAM ? ». Suit un bloc de texte où une femme propose d’envoyer des photos sexy d’elle. Un personnage : « J’hésite »
Difficile de déterminer si un message est du spam ou pas… 😅

Ne pas être considéré comme spammeur·euses

Là, c’est plus difficile. En effet, malgré notre respect de toutes les bonnes pratiques citées ci-dessus et d’autres (SPF, DKIM, DMARC…), nous restons à la merci de règles absurdes et non publiques mises en place par les autres services de courriel.

Vous mettez en place un nouveau serveur qui va envoyer des courriels ? Bon courage pour que les serveurs de Microsoft (hotmail.com, outlook.com…) l’acceptent. J’ai encore vécu ça il y a quelques mois et je ne sais toujours pas comment ça s’est débloqué (j’ai envoyé des courriels à des adresses chez eux que j’ai créées pour ça et je reclassais les courriels dans la catégorie « légitime », ça ne fonctionnait toujours pas mais quelques semaines plus tard, ça passait).

Bob l’éponge, les mains écartées et reliées par un arc-en-ciel. Texte : « It’s magic »

Votre serveur envoie beaucoup de courriels à Orange ? Pensez à limiter le nombre de courriels envoyés en même temps. Mais aussi à mettre en place un cache des connexions avec leurs serveurs. Eh oui : pas plus de X mails envoyés en même temps, mais pas plus de Y connexions par heure. Ou par minute. Ou par jour. C’est ça le problème : on n’en sait rien, on ne peut que poser la question à d’autres administrateurs de services de mail (pour cela, la liste de diffusion smtp-fr gagne à être connue. Le groupe des adminSys français, FRsAG est aussi à garder en tête).

Un autre problème est que nous ne sommes pas à l’origine du contenu de tous les courriels qui sortent de nos serveurs.
Par exemple, un spam arrivant sur une framaliste, s’il n’est pas détecté, sera envoyé à tou·tes les abonné·es de la liste, et ça peut vite faire du volume.

Les spams peuvent aussi passer de medium en medium : Framapiaf peut vous notifier par courriel d’une mention de votre identifiant dans un pouet (Ex. « Coucou @luc »). Si le pouet est un spam (« Coucou @luc, tu veux acheter une pierre magique contre les ondes 5G des reptiliens franc-maçons islamo-gauchistes partouzeurs de droite ? »), le spam se retrouve dans un courriel qui part de chez nous.

Mème avec le texte « Spam. Spam everywhere »

Certes, les courriels partant de chez nous sont aussi analysés par Rspamd et certains sont bloqués avant envoi, mais ce n’est pas efficace à 100 %.

Il y a aussi les faux positifs : que faire si nos courriels sont incorrectement classés comme spam par leurs destinataires ? Comme quelqu’un abonné sur une framaliste sans en être averti et qui d’un coup se retrouve submergé de courriels venant d’un expéditeur inconnu ?

Nous nous sommes inscrits à une boucle de rétroaction : nous recevons des notifications pour chaque courriel classé comme indésirable par un certain nombre de fournisseurs de messagerie.
Cela nous a permis (et nous permet toujours. Quotidiennement.) d’envoyer un message à de nombreuses personnes au courriel @laposte.net abonnées à des framalistes pour leur demander de ne pas nous mettre en indésirable, mais de se désabonner de la liste (en leur indiquant la marche à suivre) si elles ne souhaitent pas en recevoir les messages.

Au niveau de Framalistes, nous vérifions que les comptes possédant plus qu’un certain nombre de listes, et que les listes avec beaucoup d’abonné⋅es ne soient pas utilisées pour envoyer des messages indésirables. En effet, nous avons déjà souffert de quelques vagues de spam, nous obligeant à l’époque à modérer la création de listes en dehors des heures de travail car nous ne souhaitions pas, le matin, nous rendre compte que le service était tombé ou s’était fait bloquer pendant la nuit : l’envoi massif de courriels comme le faisaient les spammeur·euses rencontrait souvent un goulot d’étranglement au niveau du serveur, incapable de gérer autant de courriels d’un coup, ce qui faisait tomber le service.
Cette modération n’est plus active aujourd’hui, mais nous avons toujours cet outil prêt à être utilisé en cas de besoin.

Framalistes, si vous l’utilisez, a besoin de vous pour lutter contre le spam !

Petit rappel : il y a un lien de désinscription en bas de chaque courriel des framalistes. Utilisez ce lien pour vous désinscrire si vous ne souhaitez plus recevoir les messages de la liste.

Rien de plus simple que de déclarer un courriel comme étant du spam, n’est-ce pas ? Un clic dans son client mail et hop !

Eh bien non, pas pour Framalistes.

En effet, en faisant cela, vous déclarez notre serveur comme émettant du spam et non pas le serveur originel : nous risquons d’être complètement bannis et de ne plus pouvoir envoyer de courriels vers votre service de messagerie. De plus, l’apprentissage du spam (si le service de messagerie que vous utilisez fait bien son travail, les messages déclarés manuellement comme étant du spam passent dans une moulinette pour mettre à jour les règles de filtrage anti-spam) ne se fait que sur votre service de messagerie, pas chez nous.

Un chat devant un ordinateur portable, l’air halluciné. Texte : « You has spam. Glorious SPAM »

Si votre liste reçoit des spams, merci de le signaler à nom_de_la_liste-request@framalistes.org (l’adresse pour contacter les propriétaires de votre liste) : les propriétaires de la liste ont la possibilité, sur https://framalistes.org/sympa/arc/nom_de_la_liste, de supprimer un message des archives et de le signaler comme spam non détecté (n’hésitez pas à leur indiquer ce lien).

Le spam sur Framapiaf et Framasphère

Point d’antispam comme Rspamd possible sur Mastodon ou diaspora* (techniquement, il pourrait y avoir moyen de faire quelque chose, mais ça serait très compliqué).

Les serveurs Mastodon (pas que framapiaf.org, celui de Framasoft) font régulièrement l’objet de vagues d’inscription de spammeur·euses. Pour éviter l’épuisement de notre équipe de modération, nous avons décidé de modérer les inscriptions et donc d’accepter les comptes un à un.

Nous nous reposons sur les signalements des utilisateur·ices pour repérer les comptes de spam que nous aurions laissé passer et les supprimer (ce qui est très rare) ou les bloquer s’ils proviennent d’autres serveurs avec lesquels nous sommes fédérés.

Framasphère ne dispose pas, contrairement à Framapiaf de tels outils de modération : pas d’inscriptions modérées, pas de blocage de comptes distants… Nous ne pouvons que nous reposer sur les signalements et bloquer les comptes locaux.
Nous arrivons tout de même à bloquer les comptes distants, mais cela nécessite de modifier un enregistrement directement en base de données.

(parenthèse technique)
Voici comment nous bloquons les comptes distants sur Framasphère :

UPDATE people SET serialized_public_key = 'banned' WHERE guid = 'le_guid_du_compte';

Le spam sur Framaforms

Framaforms a rapidement été victime de son succès : sa fréquentation a presque triplé entre 2019 et 2020 (et l’année n’est pas terminée !), devenant aujourd’hui le service le plus utilisé de notre réseau !

Nous n’avons donc pas remarqué la création de nombreux, trop nombreux formulaires proposant, par exemple, des liens vers des sites de téléchargement illégal de films. C’est d’ailleurs suite à une réclamation d’un ayant droit que nous avons pris conscience du problème (oui, nous avons fait suite à cette réclamation : quoi que nous pensions du droit d’auteur, nous nous devons de respecter la loi).

Pic (x10) de clics provenant de recherches Google, principalement vers des formulaires de spam (warez).

La lutte contre le spam a occupé une bonne partie du temps de Théo qui a temporairement rejoint notre équipe salariée pour prêter main forte sur Framaforms :

  • détection de certains termes dans les formulaires avec mise en quarantaine (dépublication) en cas de suspicion de spam ;
  • quarantaine des formulaires ne contenant aucune question (juste la description, quoi) ;
  • interdiction de certains termes dans le titre des formulaires ;
  • intégration d’Akismet (un service anti-spam en ligne, proposé par Automattic, la société derrière https://wordpress.com/, contributrice à WordPress) ;
  • amélioration du système de CAPTCHA
  • ajout de vues permettant une gestion plus aisée des formulaires par les administrateur·ices.

Les efforts de Theo ont porté leurs fruits : la détection automatique des spams et leur dépublication tout aussi automatique limitent la pollution présente sur Framaforms (ce qui évite les réclamations, donc de monopoliser l’attention d’un salarié pour y répondre) et l’interface de gestion des spams facilite grandement le travail des administrateur·ices.

Un homme avec un lance-flamme. Texte « Kill it! Kill it with fire before it lays eggs! »
Théo s’attaquant au problème des spams sur Framaforms (allégorie)

Le spam sur Framagit

Nous avons beaucoup d’utilisateur⋅ices sur Framagit : nous avons dépassé les 90 000 inscrit⋅es. Mais pour notre malheur, la grande majorité d’entre elleux est constituée de comptes de spam !

Après des mois de ménage, nous sommes redescendus à un peu moins de 34 000 comptes, mais nous ne sommes pas dupes : il y a encore beaucoup de comptes illégitimes.

À noter cependant : ces comptes de spam ne semblent pas être dommageables pour les utilisateur⋅ices de Framagit. En effet, leur nuisance se limite généralement à mettre des liens vers un site de poker en ligne, de rencontres voire… de plombiers à Dubaï (je ne comprends pas non plus 😅).

Ceci explique en partie pourquoi nous n’avons pas lutté très activement contre le spam sur Framagit (l’autre raison étant que nous n’avions tout simplement pas de temps à y consacrer).

Nous avions déjà eu une vague de spams lors de l’ouverture de Framagit et nous avions dû interdire l’accès de notre forge logicielle à l’Inde, à l’Indonésie et au Viêt Nam, restriction active jusqu’à la semaine dernière.
Cela n’est pas dans nos habitudes mais s’il faut choisir entre ça et le risque d’épuisement professionnel d’un membre de l’équipe, Framasoft préfère faire passer l’humain avant tout (🤗).

Une grande vague de nettoyage a eu lieu en juin, où j’ai recherché des critères communs aux comptes de spam afin de les supprimer en masse… ce qui a donné lieu à une vilaine boulette lorsque j’ai choisi des critères bien trop larges, conduisant à la suppression de nombreux comptes légitimes (rétablis depuis).

Depuis, j’ai vérifié manuellement chaque compte remonté par mes recherches… soit plus de 18 000 comptes depuis septembre. Parmi ceux-ci, il devait y en avoir, à la louche (parce que mes souvenirs me trahissent), une ou deux dizaines de comptes légitimes. Heureusement ! Je crois que j’aurais assez mal pris le fait d’avoir vérifié chaque compte pour rien 😅

Nous avons désormais un script qui supprime automatiquement les comptes qui ne se sont jamais connectés dans les 10 jours suivant leur inscription : ce sont visiblement des comptes de spam qui ne reçoivent pas les mails de confirmation et donc ne se sont jamais connectés.
Ce script nous remonte aussi les comptes dont la biographie ou les liens contiennent certains termes usités par les spammeur·euses.

Nous avons recherché une solution de CAPTCHA pour Framagit, mais celui-ci ne supporte que reCaptcha, la solution d’Alphabet/Google… et il était hors de question de faire fuiter les informations (adresse IP, caractéristiques du navigateur…) et permettre le tracking de nos utilisateurs vers les services de l’infâme bête aux multiples têtes que nous combattons !

Hercule et l’hydre de Lernes
Framasoft combattant Google, allégorie

Nous avons alors recherché quelqu’un·e qui saurait développer, contre rémunération, une solution de type honeypot.
Dans le ticket que nous avons, sans aucune honte, squatté pour poser notre petite annonce, on nous a aiguillés vers une fonctionnalité d’honeypot expérimentale et cachée de Gitlab que je me suis empressé d’activer.
Il faut bien le dire : c’est très efficace ! Le nombre de comptes automatiquement supprimés par le script évoqué plus haut est descendu de près de 100 par jour à entre 0 et 2 comptes, ce qui montre bien que les scripts des spammeur·euses pour s’inscrire ne fonctionnent plus aussi bien.

Bien évidemment, il reste encore beaucoup de spam sur Framagit, et de nombreux comptes de spam sont créés chaque jour (10 ? 15 ? 20 ? Ça dépend des jours…), mais nous ne comptons pas en rester là. Le honeypot pourrait être amélioré, ou nous pourrions voir pour une intégration d’Akismet à Gitlab (il y en a déjà une, mais elle n’est pas utilisée pour vérifier les biographies des comptes).
Gitlab permet maintenant de modérer les inscriptions en les acceptant une à une (comme nous le faisons sur Framapiaf) : nous avons récemment activé cette fonctionnalité, pour voir si la charge de modération était acceptable et si cela avait un effet bénéfique.

Mème de Winnie l’ourson : Winnie, habillé normalement, l’air un peu déconfit : « Delete spam one by one ». Winnie en smoking, l’air satisfait « Install a honeypot »

Nous recevons de temps à autre (bien moins ces derniers temps, fort heureusement) des mails indiquant que Framalink est utilisé pour dissimuler des liens de hameçonnage dans des mails.

Lorsque la vague d’utilisation malveillante s’est intensifiée, j’ai développé (et amélioré au fil du temps) quelques fonctionnalités dans Lstu (le logiciel derrière Framalink) : une commande pour supprimer des raccourcis, pour rechercher les raccourcis contenant une chaîne de caractères ou provenant d’une certaine adresse IP, un système de bannissement d’adresse IP, un système de domaines interdits, empêchant le raccourcissement d’URL de tels domaines, une vérification des URL dans la base de données Google Safe Browsing (lien en anglais) avant raccourcissement et même a posteriori (je vous rassure, aucune donnée n’est envoyée à Google, la base de données est copiée et utilisée en local).

Ces efforts n’ont pas été suffisamment efficaces et nous avons été obligés de couper l’accès à l’API de Framalink, ce qui n’est pas une panacée, mais tout cela a fortement réduit nos problèmes de spam (ou pas, mais en tout cas, on a beaucoup moins de mails nous alertant de l’utilisation de Framalink pour du hameçonnage).

Notez que c’est à cause de l’utilisation de Framalink à des fins malveillantes que ce service est souvent persona non grata chez Facebook, Twitter et consorts.

Framasite

Des framasites avec de jeunes filles dénudées qui jouent au poker avec des plombiers de contrées lointaines ? Eh bien non, même pas. Les spammeurs se contentent de créer des comptes dont le nom d’utilisateur·ice est du genre « Best adult dating site, register on… ».

Et tout comme sur Framagit, beaucoup de comptes créés ne sont jamais validés (vous savez, avec l’email qui dit « cliquez sur ce lien pour finaliser votre inscription » ?).

Heureusement que ce n’est que cela, Framasite n’ayant pas d’interface d’administration permettant la suppression propre d’utilisateur·ices (« propre » voulant dire avec suppression des sites créés). Une simple suppression des comptes illégitimes en base de données suffit à faire le ménage.

Mème avec Gru des films « Moi moche et méchant » qui fait une présentation : « Faire de l’éducation populaire », « Proposer un outil pour faire des sites », « Avoir des comptes appelés « Best adult dating site » » Gru se retourne, interloqué par la page de présentation « Avoir des comptes appelés « Best adult dating site » »

Framalibre

Framalibre est aussi sujet aux spams, mais il s’agit généralement là de notices de logiciels non libres. Soit les personnes créant ces notices n’ont pas compris que Framalibre n’était dédié qu’aux logiciels libres, soit elles ont essayé d’améliorer leur référencement en ajoutant leurs logiciels.

Pour une fois, ce n’est pas bien méchant, pas bien violent (cela n’arrive pas souvent) et la vigilance de l’équipe de modération permet de supprimer (manuellement) ces notices indésirables très rapidement.

WordPress (commentaires)

Les spams dans les commentaires d’un blog sont un graaaaand classique ! Nous avons opté, sur nos sites wordpress, pour les extensions Antispam Bee et Spam Honey Pot.

C’est plutôt efficace, il est rare qu’un spam passe à travers ce système.

Drupal (inscriptions)

Nous avons quelques autres installations de Drupal autres que Framaforms et Framalibre. Les spammeurs s’inscrivent, voient qu’ils ne peuvent rien publier facilement : les Drupal en question ont les inscriptions ouvertes pour une bonne raison, mais ne permettent pas de créer des articles comme ça, hop !

Ce n’est donc, à l’heure actuelle, pas gênant.

Notre formulaire de contact

« Un formulaire de contact ? Oh chic ! » se disent les spammeurs. Là aussi, nous recevons un certain nombre de spams, tous les jours, toutes les semaines (une quarantaine par semaine), ou par une ancienne adresse de contact.

Nous nous contentons de répondre « #spam » en commentaire du ticket créé dans notre RequestTracker : cela supprime le message et empêche son expéditeur·ice de nous envoyer d’autres messages (voir sur mon wiki personnel pour commander son RequestTracker par mail).

Les faux positifs

Deux boutons : « Spam », « Pas spam ». Un homme s’essuie le front, angoissé par le choix à faire. L’homme est légendé « L’antispam »
Spam, pas spam… la vie d’un antispam n’est pas facile.

Je n’ai pas encore parlé des faux positifs : des messages légitimes détectés à tort comme étant du spam. Cela arrive forcément, quel que soit le type de plateforme, quels que soient les moyens déployés : statistiquement, il y aura toujours, un jour, une erreur du système ou des humain·es derrière (cf la boulette évoquée dans la partie « Framagit »).

Et dans l’autre sens, on aura toujours des spams qui arriveront à passer. Il est généralement difficile voire impossible de durcir les règles de détection de spam sans augmenter la proportion de faux positifs.

Conclusion

Il n’y en pas vraiment. La lutte contre le spam est un combat sans fin, un jeu du chat et de la souris qui ne se termine jamais. On tente de se protéger du mieux qu’on peut, on trouve des astuces, ça va mieux pendant un temps et ça recommence.

Il faut pas se le cacher : plus un hébergeur « grossit », plus il prend de la renommée sur Internet, plus il y a de chances que des personnes malveillantes repèrent son service et l’utilisent pour leur spam. Il y a donc un paradoxe de l’hébergement : trop petit, on est vite seul·e et débordé·e par la multiplicité des tâches à accomplir pour faire les choses correctement…

Mais trop gros, on centralise les attentions, dont celles des personnes malveillantes qui auront peu de scrupules à parasiter les ressources que vous mettez en commun. Ce qui induit encore plus de travail pour se protéger des spams et les nettoyer.

Ça vous paraît pessimiste ? Ça l’est un peu, sans doute ¯\_(ツ)_/¯

Sisyphe poussant son rocher
La lutte contre le spam (allégorie)




Demain, les développeurs… ?

En quelques années à peine s’est élevée dans une grande partie de la population la conscience diffuse des menaces que font peser la surveillance et le pistage sur la vie privée.

Mais une fois identifiée avec toujours plus de précision la nature de ces menaces, nous sommes bien en peine le plus souvent pour y échapper. Nous avons tendance surtout à chercher qui accuser… Certes les coupables sont clairement identifiables : les GAFAM et leur hégémonie bien sûr, mais aussi les gouvernements qui abdiquent leur pouvoir politique et se gardent bien de réguler ce qui satisfait leur pulsion sécuritaire. Trop souvent aussi, nous avons tendance à culpabiliser les Dupuis-Morizeau en les accusant d’imprudence et de manque d’hygiène numérique. C’est sur les utilisateurs finaux que l’on fait porter la responsabilité : « problème entre la chaise et le clavier », « si au moins ils utilisaient des mots de passe compliqués ! », « ils ont qu’à chiffrer leur mails », etc. et d’enchaîner sur les 12 mesures qu’ils doivent prendre pour assurer leur sécurité, etc.

L’originalité du billet qui suit consiste à impliquer une autre cible : les développeurs. Par leurs compétences et leur position privilégiée dans le grand bain numérique, ils sont à même selon l’auteur de changer le cours de choses et doivent y œuvrer.
Les pistes qu’expose Mo Bitar, lui-même développeur (il travaille sur StandardNotes, une application open source de notes qui met l’accent sur la longévité et la vie privée) paraîtront peut-être un peu vagues et idéalistes. Il n’en pointe pas moins une question intéressante : la communauté des codeurs est-elle consciente de ses responsabilités ?

Qu’en pensent les spécialistes de la cybersécurité, les adminsys, la communauté du développement ? — les commentaires sont ouverts, comme d’habitude.

Article original : The Privacy Revolution that never came
Traduction Framalang : tripou, david, goofy, audionuma, MO, lyn., Luc et un anonyme.

La révolution de la vie privée n’a jamais eu lieu

Voici pourquoi les développeurs de logiciels détiennent la clef d’un nouveau monde

par Mo Bitar


Actuellement, c’est la guerre sur les réseaux, et ça tire de tous les côtés. Vous remportez une bataille, ils en gagnent d’autres. Qui l’emporte ? Ceux qui se donnent le plus de mal, forcément. Dans cette campagne guerrière qui oppose des méga-structures surdimensionnées et des technophiles, nous sommes nettement moins armés.

Des informations. C’est ce que tout le monde a toujours voulu. Pour un gouvernement, c’est un fluide vital. Autrefois, les informations étaient relativement faciles à contrôler et à vérifier. Aujourd’hui, les informations sont totalement incontrôlables.

Les informations circulent à la vitesse de la lumière, la vitesse la plus rapide de l’univers. Comment pourrait-on arrêter une chose pareille ? Impossible. Nos problèmes commencent quand une structure trop avide pense qu’elle peut le faire.

Telle est la partie d’échecs pour la confidentialité que nous jouons tous aujourd’hui. Depuis le contrôle de l’accès à nos profils jusqu’au chiffrement de nos données en passant par un VPN (réseau privé virtuel) pour les rediriger, nous ne sommes que des joueurs de deuxième zone sur le grand échiquier des informations. Quel est l’enjeu ? Notre avenir. Le contrôle de la vie privée c’est le pouvoir, et les actions que nous menons aujourd’hui déterminent l’équilibre des pouvoirs pour les générations et sociétés à venir. Quand ce pouvoir est entre les mains de ceux qui ont le monopole de la police et des forces armées, les massacres de masse en sont le résultat inévitable.

Alors, où se trouve la révolution sur la confidentialité de nos informations que nous attendons tous ? Ce jour d’apothéose où nous déciderons tous de vraiment prendre au sérieux la question de la confidentialité ? Nous disons : « Je garde un œil dessus, mais pour le moment je ne vais pas non plus me déranger outre mesure pour la confidentialité. Quand il le faudra vraiment, je m’y mettrai ». Ce jour, soit n’arrivera  jamais, soit sous une forme qui emportera notre pays avec lui. Je parle des États-Unis, mais ceci est valable pour tout pays qui a été construit sur des principes solides et de bonnes intentions. Bâtir un nouveau pays n’est pas facile : des vies sont perdues et du sang est inutilement versé dans le processus. Gardons plutôt notre pays et agissons pour l’améliorer.

Les gouvernements peuvent être envahissants, mais ni eux ni les gens ne sont mauvais par nature : c’est l’échelle qui est problématique. Plus une chose grandit, moins on distingue les actions et les individus qui la composent, jusqu’à ce qu’elle devienne d’elle-même une entité autonome, capable de définir sa propre direction par la seule force de son envergure.

Alors, où est notre révolution ?
Du côté des développeurs de logiciels.

Les développeurs de logiciels et ceux qui sont profondément immergés dans la technologie numérique sont les seuls actuellement aptes à déjouer les manœuvres des sur-puissants, des sans-limites. Il est devenu trop difficile, ou n’a jamais vraiment été assez facile pour le consommateur moyen de suivre l’évolution des meilleurs moyens de garder le contrôle sur ses informations et sa vie privée. La partie a été facile pour le Joueur 1 à tel point que le recueil des données s’est effectué à l’échelle de milliards d’enregistrements par jour. Ensuite sont arrivés les technophiles, des adversaires à la hauteur, qui sont entrés dans la danse et sont devenus de véritables entraves pour le Joueur 1. Des technologies telles que Tor, les VPN, le protocole Torrent et les crypto-monnaies rendent la tâche extrêmement difficile pour les sur-puissants, les sans-limites. Mais comme dans tous les bons jeux, chaque joueur riposte plus violemment à chaque tour. Et notre équipe perd douloureusement.

Même moi qui suis développeur de logiciels, je dois admettre qu’il n’est pas facile de suivre la cadence des dernières technologies sur la confidentialité. Et si ce n’est pas facile pour nous, ce ne sera jamais facile pour l’utilisateur lambda des technologies informatiques. Alors, quand la révolution des données aura-t-elle lieu ? Jamais, à ce rythme.

Tandis que nous jouissons du luxe procuré par la société moderne, sans cesse lubrifiée par des technologies qui nous libèrent de toutes les corvées et satisfont tous les besoins, nous ne devons pas oublier d’où nous venons. Les révolutions de l’histoire n’ont pas eu lieu en 140 caractères ; elles se sont passées dans le sang, de la sueur et des larmes, et un désir cannibale pour un nouveau monde. Notre guerre est moins tangible, n’existant que dans les impulsions électriques qui voyagent par câble. « Où se trouve l’urgence si je ne peux pas la voir ? » s’exclame aujourd’hui l’être humain imprudent, qui fonctionne avec un système d’exploitation biologique dépassé, incapable de pleinement comprendre le monde numérique.

Mais pour beaucoup d’entre nous, nos vies  numériques sont plus réelles que nos vies biologiques. Dans ce cas, quel est l’enjeu ? La manière dont nous parcourons le monde dans nos vies numériques. Imaginez que vous viviez dans un monde où, dès que vous sortez de chez vous pour aller faire des courses, des hommes en costume noir, avec des lunettes de soleil et une oreillette, surveillent votre comportement, notent chacun de vos mouvements et autres détails, la couleur de vos chaussures ce jour-là, votre humeur, le temps que vous passez dans le magasin, ce que vous avez acheté, à quelle vitesse vous êtes rentré·e chez vous, avec qui vous vous déplaciez ou parliez au téléphone – toutes ces métadonnées. Comment vous sentiriez-vous si ces informations étaient recueillies sur votre vie, dans la vraie vie ? Menacé·e, certainement. Biologiquement menacé·e.

Nos vies sont numériques. Bienvenue à l’évolution. Parcourons un peu notre nouveau monde. Il n’est pas encore familier, et ne le sera probablement jamais. Comment devrions-nous entamer nos nouvelles vies dans notre nouveau pays, notre nouveau monde ? Dans un monde où règnent contrôle secret et surveillance de nos mouvements comme de nos métadonnées ? Ou comme dans une nouvelle vieille Amérique, un lieu où être libre, un lieu  où  on peut voyager sur des milliers de kilomètres : la terre promise.

Construisons notre nouveau monde sur de bonnes bases. Il existe actuellement des applications iPad qui apprennent aux enfants à coder – pensez-vous que cela restera sans conséquences ? Ce qui est aujourd’hui à la pointe de la technologie, compréhensible seulement par quelques rares initiés, sera connu et assimilé demain par des enfants avant leurs dix ans. Nous prétendons que la confidentialité ne sera jamais généralisée parce qu’elle est trop difficile à cerner. C’est vrai. Mais où commence-t-elle ?

Elle commence lorsque ceux qui ont le pouvoir de changer les choses se lèvent et remplissent leur rôle. Heureusement pour nous, cela n’implique pas de se lancer dans une bataille sanglante. Mais cela implique de sortir de notre zone de confort pour faire ce qui est juste, afin de protéger le monde pour nous-mêmes et les générations futures. Nous devons accomplir aujourd’hui ce qui est difficile pour le rendre facile aux autres demain.

Jeune nerd à qui on vient de demander de sauver le monde, dessin de Simon « Dr Gee » Giraudot, Licence Creative Commons BY SA

Développeur ou développeuse, technophile… vous êtes le personnage principal de ce jeu et tout dépend de vos décisions et actions présentes. Il est trop fastidieux de gérer un petit serveur personnel ? Les générations futures ne seront jamais propriétaires de leurs données. Il est trop gênant d’utiliser une application de messagerie instantanée chiffrée, parce qu’elle est légèrement moins belle ? Les générations futures ne connaîtront jamais la confidentialité de leurs données. Vous trouvez qu’il est trop pénible d’installer une application open source sur votre propre serveur ? Alors les générations à venir ne profiteront jamais de la maîtrise libre de leurs données.

C’est à nous de nous lever et de faire ce qui est difficile pour le bien commun. Ce ne sera pas toujours aussi dur. C’est dur parce que c’est nouveau. Mais lorsque vous et vos ami⋅e⋅s, vos collègues et des dizaines de millions de développeurs et développeuses auront tous ensemble fait ce qui est difficile, cela restera difficile pendant combien de temps, à votre avis ? Pas bien longtemps. Car comme c’est le cas avec les économies de marché, ces dizaines de millions de développeurs et développeuses deviendront un marché, aux besoins desquels il faudra répondre et à qui on vendra des produits. Ainsi pourra s’étendre et s’intensifier dans les consciences le combat pour la confidentialité.

Pas besoin d’attendre 10 ans pour que ça se produise. Pas besoin d’avoir dix millions de développeurs. C’est de vous qu’on a besoin.

 

  • Vous pouvez faire un premier pas en utilisant et soutenant les services  qui assurent la confidentialité et la propriété des données par défaut. Vous pouvez aussi en faire profiter tout le monde : rendez-vous sur Framalibre, et ajoutez les outils libres et respectueux que vous connaissez, avec une brève notice informative.



Plus rien ne marche, qu’est-ce qu’on fait ?

Désormais conscients et informés que nos actions et nos données en ligne sont faciles à espionner et l’enjeu de monétisation en coulisses, il nous restait l’espoir que quelques pans des technologies de sécurité pouvaient encore faire échec à la surveillance de masse et au profilage commercial. Pas facile pour les utilisateurs moyens d’adopter des outils et des pratiques de chiffrement, par exemple, cependant de toutes parts émergent des projets qui proposent de nous aider à y accéder sans peine.

Mais quand les experts en sécurité, quittant un moment leur regard hautain sur le commun des mortels à peine capables de choisir un mot de passe autre que 123AZERTY, avouent qu’ils savent depuis longtemps que tout est corrompu directement ou indirectement, jusqu’aux services soi-disant sécurisés et chiffrés, le constat est un peu accablant parce qu’il nous reste tout à reconstruire…

Plus rien ne fonctionne

article original : Everything is broken par Quinn Norton

Traduction Framalang : Diab, rafiot, Omegax, Scailyna, Amine Brikci-N, EDGE, r0u, fwix, dwarfpower, sinma, Wan, Manu, Asta, goofy, Solarus, Lumi, mrtino, skhaen

Un beau jour un de mes amis a pris par hasard le contrôle de plusieurs milliers d’ordinateurs. Il avait trouvé une faille dans un bout de code et s’était mis à jouer avec. Ce faisant, il a trouvé comment obtenir les droits d’administration sur un réseau. Il a écrit un script, et l’a fait tourner pour voir ce que ça donnerait. Il est allé se coucher et il a dormi environ quatre heures. Le matin suivant, en allant au boulot, il a jeté un coup d’œil et s’est aperçu qu’il contrôlait désormais près de 50 000 ordinateurs. Après en avoir pratiquement vomi de trouille, il a tout arrêté et supprimé tous les fichiers associés. Il m’a dit que finalement il avait jeté le disque dur au feu. Je ne peux pas vous révéler de qui il s’agit, parce qu’il ne veut pas finir dans une prison fédérale ; et c’est ce qui pourrait lui arriver s’il décrivait à qui que ce soit la faille qu’il a découverte. Cette faille a-t-elle été corrigée ? Sans doute… mais pas par lui. Cette histoire n’est en rien exceptionnelle. Passez quelque temps dans le monde des hackers et de la sécurité informatique, et vous entendrez pas mal d’histoires dans ce genre et même pires que celle-là.

Il est difficile d’expliquer au grand public à quel point la technologie est chancelante, à quel point l’infrastructure de nos vies ne tient qu’avec l’équivalent informatique de bouts de ficelle. Les ordinateurs et l’informatique en général sont détraqués.

Quand c’est codé avec les pieds, bonjour les vautours

Pour un bon nombre d’entre nous, en particulier ceux qui ont suivi l’actualité en matière de sécurité et les questions d’écoutes sauvages, rien de surprenant dans toutes les dernières révélations. Si nous ne connaissions pas les détails, nous savions tous, dans le monde de la sécurité, que la technologie est vacillante et malade. Depuis des années nous voyons tourner les vautours qui veulent profiter de cet état de fait. La NSA n’est pas et n’a jamais été le grand prédateur unique fondant sur Internet. C’est simplement le plus gros de ces charognards. S’ils arrivent à aller aussi loin, ce n’est pas parce que leurs employés sont des dieux des maths.

Si la NSA s’en sort si bien, c’est parce que les logiciels en général sont merdiques.

Huit mois avant que Snowden ne fasse ses révélations, j’ai twitté ça :

tweetQuinnNorton.png

« alerte de sécu : tout a une faille 0 day, tout le monde est suivi à la trace, toutes les données fuitent, tout est vulnérable, tout est compromis jusqu’à l’os. »

J’en étais arrivée à cette conclusion un peu désespérée : chercher des logiciels de qualité est un combat perdu d’avance. Comme ils sont écrits par des gens n’ayant ni le temps ni l’argent nécessaires, la plupart des logiciels sont publiés dès qu’ils fonctionnent assez bien pour laisser leurs auteurs rentrer chez eux et retrouver leur famille. Pour nous le résultat est épouvantable.

Si les logiciels sont aussi mauvais, c’est parce qu’ils sont très complexes, et qu’il cherchent à parler à d’autres logiciels, soit sur le même ordinateur, soit au travers du réseau. Même votre ordinateur ne peut plus être considéré comme unique : c’est une poupée russe, et chaque niveau est fait de quantité d’éléments qui essaient de se synchroniser et de parler les uns avec les autres. L’informatique est devenue incroyablement complexe, alors que dans le même temps les gens sont restés les mêmes, pétris de la même boue grise originelle pleine d’une prétention à l’étincelle divine.

Le merdier qu’est votre ordinateur sous Windows est tellement complexe que personne sur Terre ne sait tout ce qu’il fait vraiment, ni comment.

Maintenant imaginez des milliards de petites boites opaques qui essaient en permanence de discuter les unes avec les autres, de se synchroniser, de travailler ensemble, partageant des bouts de données, se passant des commandes… des tous petits bouts de programmes aux plus gros logiciels, comme les navigateurs – c’est ça, Internet. Et tout ça doit se passer quasi-simultanément et sans accrocs. Sinon vous montez sur vos grand chevaux parce que le panier de la boutique en ligne a oublié vos tickets de cinéma.

On n’arrête pas de vous rappeler que le téléphone avec lequel vous jouez à des jeux stupides et que vous laissez tomber dans les toilettes au troquet du coin est plus puissant que les ordinateurs utilisés pour la conquête de l’espace il y a de cela quelques décennies à peine. La NASA dispose d’une armée de génies pour comprendre et maintenir ses logiciels. Votre téléphone n’a que vous. Ajoutez à cela un mécanisme de mises à jour automatiques que vous désactivez pour qu’il ne vous interrompe pas au beau milieu d’une séance de Candy Crush…

À cause de tout ça, la sécurité est dans un état effrayant. En plus d’être truffés de bugs ennuyeux et de boîtes de dialogue improbables, les programmes ont souvent un type de faille piratable appelée 0 day (« zéro jour ») dans le monde de la sécurité informatique. Personne ne peut se protéger des 0 days. C’est justement ce qui les caractérise : 0 représente le nombre de jours dont vous disposez pour réagir à ce type d’attaque. Il y a des 0 days qui sont anodins et vraiment pas gênants, il y a des 0 days très dangereux, et il y a des 0 days catastrophiques, qui tendent les clés de la maison à toute personne qui se promène dans le coin. Je vous assure qu’en ce moment même, vous lisez ceci sur une machine qui a les trois types de 0days. Je vous entends d’ici me dire : « Mais, Quinn, si personne ne les connaît comment peux-tu savoir que je les ai ? » C’est parce que même un logiciel potable doit avoir affaire avec du code affreux. Le nombre de gens dont le travail est de rendre le logiciel sûr peut pratiquement tenir dans un grand bar, et je les ai regardé boire. Ce n’est pas rassurant. La question n’est pas : « est-ce que vous allez être attaqué ? » mais : « quand serez-vous attaqué ? »

Considérez les choses ainsi : à chaque fois que vous recevez une mise à jour de sécurité (apparemment tous les jours avec mon ordi sous Linux), tout ce qui est mis à jour a été cassé, rendu vulnérable depuis on ne sait combien de temps. Parfois des jours, parfois des années. Personne n’annonce vraiment cet aspect des mises à jour. On vous dit « Vous devriez installer cela, c’est un patch critique ! » et on passe sous silence le côté « …parce que les développeurs ont tellement merdé que l’identité de vos enfants est probablement vendue en ce moment même à la mafia estonienne par des script kiddies accrocs à l’héro ».

Les bogues vraiment dangereux (et qui peut savoir si on a affaire à eux lorsqu’on clique sur le bouton « Redémarrer ultérieurement » ?) peuvent être utilisés par des hackers, gouvernements, et d’autres horreurs du net qui fouillent à la recherche de versions de logiciels qu’ils savent exploiter. N’importe quel ordinateur qui apparaît lors de la recherche en disant « Hé ! Moi ! Je suis vulnérable ! » peut faire partie d’un botnet, en même temps que des milliers, ou des centaines de milliers d’autres ordinateurs. Souvent les ordinateurs zombies sont possédés à nouveau pour faire partie d’un autre botnet encore. Certains botnets patchent les ordinateurs afin qu’ils se débarrassent des autres botnets, pour qu’ils n’aient pas à vous partager avec d’autres hackers. Comment s’en rendre compte si ça arrive ? Vous ne pouvez pas ! Amusez-vous à vous demander si votre vie en ligne va être vendue dans l’heure qui suit ! La prochaine fois que vous penserez que votre grand-mère n’est pas cool, pensez au temps qu’elle a passé à aider de dangereux criminels russes à extorquer de l’argent à des casinos offshore avec des attaques DDoS.

Récemment un hacker anonyme a écrit un script qui prenait le contrôle d’appareils embarqués Linux. Ces ordinateurs possédés scannaient tout le reste d’Internet et ont créé un rapport qui nous en a appris beaucoup plus que ce que nous savions sur l’architecture d’Internet. Ces petites boîtes hackées ont rapporté toutes leurs données (un disque entier de 10 To) et ont silencieusement désactivé le hack. C’était un exemple délicieux et utile d’un individu qui a hacké la planète entière. Si ce malware avait été véritablement malveillant, nous aurions été dans la merde.

Et ceci parce que les ordinateurs sont tous aussi inévitablement défectueux : ceux des hôpitaux et des gouvernements et des banques, ceux de votre téléphone, ceux qui contrôlent les feux de signalisation et les capteurs et les systèmes de contrôle du trafic aérien. Chez les industriels, les ordinateurs destinés à maintenir l’infrastructure et la chaîne de fabrication sont encore pires. Je ne connais pas tous les détails, mais ceux qui sont les plus au courant sont les personnes les plus alcooliques et nihilistes de toute la sécurité informatique. Un autre de mes amis a accidentellement éteint une usine avec un ‘“ping”’ malformé au début d’un test d’intrusion. Pour ceux qui ne savent pas, un ‘“ping”’ est seulement la plus petite requête que vous pouvez envoyer à un autre ordinateur sur le réseau. Il leur a fallu une journée entière tout faire revenir à la normale.

Les experts en informatique aiment prétendre qu’ils utilisent des logiciels d’un genre complètement différent, encore plus géniaux, qu’eux seuls comprennent, des logiciels faits de perfection mathématique et dont les interfaces semblent sortir du cul d’un âne colérique. C’est un mensonge. La forme principale de sécurité qu’ils offrent est celle que donne l’obscurité – il y a si peu de gens qui peuvent utiliser ces logiciels que personne n’a le moindre intérêt à concevoir des outils pour les attaquer. Sauf si, comme la NSA, vous voulez prendre le contrôle sur les administrateurs systèmes.

Une messagerie chiffrée et bien codée, il ne peut rien nous arriver, hein ?

Prenons un exemple que les experts aiment mettre sous le nez des gens normaux qui ne l’utilisent pas : OTR. OTR, ou Off The Record messaging, ajoute une couche de chiffrement aux échanges via messagerie instantanée. C’est comme si vous utilisiez AIM ou Jabber et que vous parliez en code sauf que c’est votre ordinateur qui fait le code pour vous. OTR est bien conçu et robuste, il a été audité avec attention et nous sommes bien sûrs qu’il ne contient aucune de ces saloperies de vulnérabilités zéro jour.

Sauf que OTR n’est pas vraiment un programme que vous utilisez tel quel.

Il existe un standard pour le logiciel OTR, et une bibliothèque, mais elle ne fait rien par elle-même. OTR est implémentée dans des logiciels pour des neuneus par d’autres neuneus. À ce stade, vous savez que ça va se terminer dans les pleurs et les grincements de dents.

La partie principale qu’utilise OTR est un autre programme qui utilise une bibliothèque appelée ‘“libpurple”’. Si vous voulez voir des snobs de la sécurité aussi consternés que les ânes qui ont pondu leur interface, apportez-leur ‘“libpurple”’. ‘“Libpurple”’ a été écrit dans un langage de programmation appelé C.

Le C est efficace dans deux domaines : l’élégance, et la création de vulnérabilités jour zéro critiques en rapport avec la gestion de la mémoire.

Heartbleed, le bogue qui a affecté le monde entier, permettant la fuite de mots de passe et de clés de chiffrement et qui sait quoi encore ? – Du classique et superbe C.

La ‘“libpurple”’ a été écrite par des gens qui voulaient que leur client de discussion open source parle à tous les systèmes de messagerie instantanée du monde, et se foutaient complètement de la sécurité ou du chiffrement. Des gens du milieu de la sécurité qui en ont examiné le code ont conclu qu’il y avait tellement de façons d’exploiter la ‘“libpurple”’ que ça n’était probablement pas la peine de la patcher. Elle doit être jetée et réécrite de zéro. Ce ne sont pas des bugs qui permettent à quelqu’un de lire vos messages chiffrés, ce sont des bugs qui permettent à n’importe qui de prendre le contrôle total de votre ordinateur, regarder tout ce que vous tapez ou lisez et même probablement vous regarder vous mettre les doigts dans le nez devant la webcam.

Ce magnifique outil qu’est OTR repose sur la ‘“libpurple”’ dans la plupart des systèmes où il est utilisé. Je dois éclaircir un point, car même certains geeks n’en ont pas conscience : peu importe la force de votre chiffrement si celui qui vous attaque peut lire vos données par-dessus votre épaule, et je vous promets que c’est possible. Qu’il sache le faire ou pas encore, cela reste néanmoins possible. Il y a des centaines de bibliothèques comme ‘“libpurple”’ sur votre ordinateur : des petits bouts de logiciels conçus avec des budgets serrés aux délais irréalistes, par des personnes ne sachant pas ou ne se souciant pas de préserver la sécurité de votre système.

Chacun de ces petits bugs fera l’affaire quand il s’agit de prendre le contrôle de tout le reste de votre ordinateur. Alors on met à jour, on remet à jour, et peut-être que ça mettra les intrus dehors, ou peut-être pas. On n’en sait rien ! Quand on vous dit d’appliquer les mises à jour, on ne vous dit pas de réparer votre navire. On vous dit de continuer à écoper avant que l’eau n’atteigne votre cou.

oldSchoolSecurity.jpg (Crédit image : sridgway, licence CC BY 2.0)

Pour prendre un peu de recul par rapport à cette scène d’horreur et de désolation, je dois vous dire que la situation est tout de même meilleure que par le passé. Nous disposons aujourd’hui d’outils qui n’existaient pas dans les années 90, comme le ‘“sandboxing”’, qui permet de confiner des programmes écrits stupidement là où ils ne peuvent pas faire beaucoup de dégâts. (Le « sandboxing » consiste à isoler un programme dans une petite partie virtuelle de l’ordinateur, le coupant ainsi de tous les autres petits programmes, ou nettoyant tout ce que ce programme essaie de faire avant que d’autres puissent y accéder).

Des catégories entières de bugs horribles ont été éradiqués comme la variole. La sécurité est prise plus au sérieux que jamais, et il y a tout un réseau de personnes pour contrer les logiciels malveillants 24h sur 24. Mais ils ne peuvent pas vraiment garder la main. L’écosystème de ces problèmes est tellement plus vaste qu’il ne l’était ne serait-ce qu’il y a dix ans, qu’on ne peut pas vraiment dire que l’on fait des progrès.

Les gens, eux aussi, sont cassés

« Je vous fais confiance… » est ce que j’aime le moins entendre de la part des mes sources Anonymous. C’est invariablement suivi de bribes d’informations qu’ils n’auraient jamais dû me confier. Il est naturel de partager quelque chose de personnel avec quelqu’un en qui on a confiance. Mais c’est avec exaspération que je dois rappeler aux Anons qu’avant d’être connectés à un autre être humain ils sont d’abord connectés à un ordinateur, relayé à travers un nombre indéterminé de serveurs, switches, routeurs, câbles, liaisons sans fil, et en bout de chaîne, mon ordinateur parfaitement ciblé par les attaques. Tout ceci se déroule le temps d’une longue inspiration. Cela semble une évidence, mais il est bon de le rappeler : les humains ne sont pas conçus pour penser de cette manière.

Personne n’arrive à utiliser les logiciels correctement. Absolument tout le monde se plante. OTR ne chiffre pas avant le premier message, un fait que des éminents professionnels de la sécurité et des hackers qui subissent une chasse à l’homme dans une vingtaine de pays oublient en permanence. Gérer toutes les clés de chiffrement et de déchiffrement dont vous avez besoin pour garder vos données en sûreté sur plusieurs appareils, sites, et comptes est théoriquement possible, de la même façon que réaliser une appendicectomie sur soi-même est théoriquement possible. Il y a un gars qui a réussi à le faire en Antarctique, pourquoi pas moi, hein ?

Tous les experts en programmes malveillants que je connais ont un jour oublié ce que faisait là un certain fichier, ont cliqué dessus pour le voir et ensuite compris qu’ils avaient exécuté un quelconque logiciel malveillant qu’ils étaient censés examiner. Je sais cela parce que ça m’est arrivé une fois avec un PDF dans lequel je savais qu’il y avait quelque chose de mauvais. Mes amis se sont moqués de moi, puis m’ont tous confessé discrètement qu’ils avaient déjà fait la même chose. Si quelques-uns des meilleurs spécialiste de rétro-ingénierie de logiciels malveillants ne peuvent surveiller leurs fichiers malveillants, qu’espérer de vos parents avec cette carte postale électronique qui est prétendument de vous ?

Les pièces jointes exécutables (ce qui inclut les documents Word, Excel, et les PDF) des emails que vous recevez chaque jour peuvent provenir de n’importe qui (on peut écrire à peu près ce que l’on veut dans le champ « De : » d’un email) et n’importe laquelle de ces pièces jointes pourrait prendre le contrôle de votre ordinateur aussi facilement qu’une vulnérabilité jour zéro. C’est certainement de cette façon que votre grand-mère s’est retrouvée à travailler pour des criminels russes, ou que vos concurrents anticipent tous vos plans produits. Mais dans le monde d’aujourd’hui, vous ne pourrez sûrement pas conserver un emploi de bureau si vous refusez d’ouvrir des pièces jointes. Voilà le choix qui s’offre à vous : prendre en permanence le risque de cliquer sur un dangereux programme malveillant, ou vivre sous un pont, laissant sur la pelouse de votre ancienne maison des messages pour dire à vos enfants combien vous les aimez et combien ils vous manquent.

Les experts de la sécurité et de la vie privée sermonnent le public à propos des métadonnées et des réseaux d’échange de données, mais prendre en compte ces choses est aussi naturel que de se faire une batterie de tests sanguins tous les matins, et à peu près aussi facile. Les risques sur le plan sociétal de renoncer à notre vie privée sont énormes. Et pourtant, les conséquences pour chacun de ne pas y renoncer sont immédiatement handicapantes. Il s’agit au final d’un combat d’usure entre ce que l’on veut pour nous-mêmes et nos familles, et ce que l’on doit faire pour vivre dans notre communauté en tant qu’humains – un champ de mines monétisé par les entreprises et monitoré par les gouvernements.

Je travaille en plein là-dedans, et je ne m’en sors pas mieux. J’ai dû une fois suivre un processus pour vérifier mon identité auprès d’un informateur méfiant. J’ai dû prendre une série de photos montrant où je me trouvais ainsi que la date. Je les ai mises en ligne, et on m’a permis de procéder à l’interview. Au final, il se trouve qu’aucune de ces vérifications n’avait été envoyées, parce que j’avais oublié d’attendre la fin du chargement avant d’éteindre nerveusement mon ordinateur. « Pourquoi m’avez-vous quand même permis de vous voir ? » demandais-je à ma source. « Parce qu’il n’y a que vous qui pourrait faire une chose aussi stupide », m’a-t-il répondu.

Touché.

Mais si cela m’arrive à moi, une adulte relativement bien entraînée qui fait attention à ce genre de sujets systématiquement, quelle chance ont les gens avec de vrais boulots et de vraies vies ?

Finalement, c’est la culture qui est cassée.

Il y a quelques années, j’ai rencontré plusieurs personnes respectées qui travaillent dans la confidentialité et la sécurité logicielle et je leur ai posé une question. Mais d’abord j’ai dû expliquer quelque chose : « La plupart des gens n’ont pas de droits d’administration sur les ordinateurs qu’ils utilisent. »

computerClassBolts.jpg (Crédit image : amelungc, licence CC BY 2.0)

C’est-à-dire que la plupart des gens qui utilisent un ordinateur dans le monde n’en sont pas propriétaires… Que ce soit dans un café, à l’école, au travail, installer une application bureautique n’est pas directement à la portée d’une grande partie du monde. Toute les semaines ou toutes les deux semaines, j’étais contacté par des gens prêts à tout pour améliorer la sécurité et les options de confidentialité, et j’ai essayé de leur apporter mon aide. Je commençais par « Téléchargez le… » et on s’arrêtait là. Les gens me signalaient ensuite qu’ils ne pouvaient pas installer le logiciel sur leur ordinateur. En général parce que le département informatique limitait leurs droits dans le cadre de la gestion du réseau. Ces gens avaient besoin d’outils qui marchaient sur ce à quoi ils avaient accès, principalement un navigateur.

Donc la question que j’ai posée aux hackers, cryptographes, experts en sécurité, programmeurs, etc. fut la suivante : quelle est la meilleure solution pour les gens qui ne peuvent pas télécharger de nouveau logiciel sur leurs machines ? La réponse a été unanime : aucune. Il n’y a pas d’alternative. On me disait qu’ils feraient mieux de discuter en texte brut, « comme ça ils n’ont pas un faux sentiment de sécurité ». À partir du moment où ils n’ont pas accès à de meilleurs logiciels, ils ne devraient pas faire quoi que ce soit qui puisse déranger les gens qui les surveillent. Mais, expliquais-je, il s’agit d’activistes, d’organisateurs, de journalistes du monde entier qui ont affaire à des gouvernements et des sociétés et des criminels qui peuvent vraiment leur faire du mal, ces gens sont vraiment en danger. On me répondait alors que dans ce cas, ils devraient s’acheter leurs propres ordinateurs.

Et voilà, c’était ça la réponse : être assez riche pour acheter son propre ordinateur, ou bien littéralement tout laisser tomber. J’ai expliqué à tout le monde que ce n’était pas suffisant, j’ai été dénigrée lors de quelques joutes verbales sans conséquences sur Twitter, et je suis passée à autre chose. Peu de temps après, j’ai compris d’où venait l’incompréhension. Je suis retourné voir les mêmes experts et j’ai expliqué : dans la nature, dans des situations vraiment dangereuses – même quand les gens sont traqués par des hommes avec des armes – quand le chiffrement et la sécurité échouent, personne n’arrête de parler. Ils espèrent seulement ne pas se faire prendre.

La même impulsion humaine qui nous pousse vers le hasard et les loteries depuis des milliers d’années soutient ceux qui luttent même quand les chances sont contre eux. « Peut-être bien que je m’en sortirai, autant essayer ! » Pour ce qui est de l’auto-censure des conversations dans une infrastructure hostile, les activistes non techniques s’en sortent de la même manière que les Anons, ou que les gens à qui l’on dit de se méfier des métadonnées, ou des réseaux d’échanges de données, ou de ce premier message avant que l’encodage OTR ne s’active. Ils foirent.

Cette conversation a été un signal d’alerte pour quelques personnes de la sécurité qui n’avaient pas compris que les personnes qui devenaient activistes et journalistes faisaient systématiquement des choses risquées. Certains ont rallié mon camp, celui où on perd son temps à des combats futiles sur Twitter et ils ont pris conscience que quelque chose, même quelque chose d’imparfait, pouvait être mieux que rien. Mais beaucoup dans le domaine de la sécurité sont toujours dans l’attente d’un monde parfait dans lequel déployer leur code parfait.

Alors apparaît l’Intelligence Community (Communauté du renseignement), ils s’appellent entre eux le IC. Nous pourrions trouver ça sympathique s’ils arrêtaient d’espionner tout le monde en permanence, et eux aimeraient bien que l’on cesse de s’en plaindre. Après avoir passé un peu de temps avec eux, je pense savoir pourquoi ils ne se préoccupent pas de ceux qui se plaignent. Les IC font partie des humains les plus surveillés de l’histoire. Ils savent que tout ce qu’ils font est passé au peigne fin par leurs pairs, leurs patrons, leurs avocats, d’autres agences, le président, et parfois le Congrès. Ils vivent surveillés, et ne s’en plaignent pas.

Dans tous les appels pour augmenter la surveillance, les fondamentaux de la nature humaine sont négligés. Vous n’allez pas apprendre aux espions que ce n’est pas bien en faisant encore plus qu’eux. Il y aura toujours des failles, et tant qu’elles existeront ou pourront être utilisées ou interprétées, la surveillance sera aussi répandue que possible. Les humains sont des créatures généralement égocentriques. Les espions, qui sont humains, ne comprendront jamais pourquoi vivre sans vie privée est mal aussi longtemps qu’ils le feront.

Et pourtant ce n’est pas cela le pire. La catastrophe culturelle qu’ils provoquent rend plus facile leur boulot d’épier le monde. Les aspects les plus dérangeants des révélations, ce sont le marché des failles 0 day, l’accumulation des moyens de les exploiter, l’affaiblissement des standards. La question est de savoir qui a le droit de faire partie de ce « nous » qui est censé être préservé de ces attaques, écoutes et décryptages et profilages. Quand ils ont attaqué Natanz avec Stuxnet et laissé tous les autres centres nucléaires vulnérables, nous avons été tranquillement avertis que le « nous » en question commençait et finissait avec l’IC lui-même. Voilà le plus grand danger.

Quand le IC ou le DOD ou le pouvoir exécutif sont les seuls vrais Américains, et que le reste d’entre nous ne sommes que des Américains de deuxième classe, ou pire les non-personnes qui ne sont pas associées aux États-Unis, alors nous ne pouvons que perdre toujours plus d’importance avec le temps. À mesure que nos désirs entrent en conflit avec le IC, nous devenons de moins en moins dignes de droits et de considération aux yeux du IC. Quand la NSA accumule des moyens d’exploiter les failles, et que cela interfère avec la protection cryptographique de notre infrastructure, cela veut dire qu’exploiter des failles contre des gens qui ne sont pas de la NSA ne compte pas tellement. Nous sécuriser passe après se sécuriser eux-mêmes.

En théorie, la raison pour laquelle nous sommes si gentils avec les soldats, que nous avons pour habitude d’honorer et de remercier, c’est qu’ils sont supposés se sacrifier pour le bien des gens. Dans le cas de la NSA, l’inverse s’est produit. Notre bien-être est sacrifié afin de rendre plus aisé leur boulot de surveillance du monde. Lorsque cela fait partie de la culture du pouvoir, on est en bonne voie pour que cela débouche sur n’importe quel abus.

Mais le plus gros de tous les problèmes culturels repose toujours sur les épaules du seul groupe que je n’aie pas encore pris à partie – les gens normaux, qui vivent leurs vies dans cette situation démentielle. Le problème des gens normaux avec la technologie est le même qu’avec la politique, ou la société en général. Les gens pensent être isolés et sans pouvoir, mais la seule chose qui maintient les gens seuls et sans pouvoir est cette même croyance. Ceux qui travaillent ensemble ont un énorme et terrible pouvoir. Il existe certainement une limite à ce que peut faire un mouvement organisé de personnes qui partagent un rêve commun, mais nous ne l’avons pas encore trouvée.

Facebook et Google semblent très puissants, mais ils vivent à peu près à une semaine de la ruine en permanence. Ils savent que le coût de départ des réseaux sociaux pris individuellement est élevé, mais sur la masse, c’est une quantité négligeable. Windows pourrait être remplacé par quelque chose de mieux écrit. Le gouvernement des États-Unis tomberait en quelques jours devant une révolte générale. Il n’y aurait pas besoin d’une désertion totale ou d’une révolte générale pour tout changer, car les sociétés et le gouvernement préfèreraient se plier aux exigences plutôt que de mourir. Ces entités font tout ce qu’elles peuvent pour s’en sortir en toute impunité – mais nous avons oublié que nous sommes ceux qui les laissons s’en sortir avec ces choses.

Si les ordinateurs ne satisfont pas nos besoins de confidentialité et de communication, ce n’est pas en raison d’une quelconque impossibilité mathématique. Il existe un grand nombre de systèmes qui pourraient chiffrer nos données de façon sécurisée et fédérée, nous disposons de nombreuses façons de retrouver la confidentialité et d’améliorer le fonctionnement par défaut des ordinateurs. Si ce n’est pas ainsi que les choses se passent en ce moment c’est parce que nous n’avons pas exigé qu’il en soit ainsi, et non pas parce que personne n’est assez malin pour que ça arrive.

C’est vrai, les geeks et les PDG et les agents et les militaires ont bousillé le monde. Mais en fin de compte, c’est l’affaire de tous, en travaillant ensemble, de réparer le monde.




Sauvegardes et garde-fous (Libres conseils 9/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sky, LIAR, lerouge, yann, Goofy, peupleLaKoS, Nys, Julius22, okram, 4nti7rust, zn01wr, lamessen

Des sauvegardes pour votre santé mentale

Austin Appel

Austin Appel, alias « scorche », est un professionnel de la sécurité informatique qui passe son temps à casser (il est dûment autorisé, évidemment) des choses précédemment réputées sécurisées. On le croise souvent enseignant le crochetage de serrure durant des conférences de sécurité et de hacking. Dans le monde de l’open source, il fait une foule de choses pour le projet Rockbox et a œuvré bénévolement pour le projet One Laptop Per Child (un ordinateur portable par enfant).

Les sauvegardes c’est bien. Les sauvegardes c’est super. Un administrateur compétent fait toujours des sauvegardes régulières. On apprend ça dans n’importe quel manuel traitant de l’administration des serveurs. Le problème c’est que les sauvegardes ne sont vraiment utiles qu’en cas d’absolue nécessité. Lorsque quelque chose de grave arrive au serveur ou à ses données et qu’on est forcé de se replier sur autre chose, les sauvegardes viendront à point nommé. Cependant, cela ne devrait jamais arriver, n’est-ce pas ? À n’importe quel autre moment, à quoi cela sert-il pour vous et votre environnement serveur d’avoir des sauvegardes ?

Avant d’aller plus loin, il est important de noter que ce conseil vaut pour les administrateurs serveurs des plus petits projets open source — la majorité silencieuse. Si vous maintenez des services qui vont engendrer une grande frustration, et même peut-être faire du tort s’ils sont indisponibles, vous devriez considérer ceci avec la plus grande circonspection.

Pour le reste d’entre nous qui travaillons sur d’innombrables petits projets ayant des ressources limitées, nous avons rarement deux serveurs séparés pour la production et les tests. En vérité, avec tous les services qu’un projet open source doit maintenir (système de gestion de version, services web, listes de diffusion, forums, ferme de compilation, bases de données, traceurs de bogues ou de fonctionnalités, etc.), des environnements de test séparés sont souvent de l’ordre du rêve. Malheureusement, l’approche courante de l’administration systèmes est d’avancer avec précaution et mettre les systèmes à jour uniquement en cas de nécessité absolue, afin d’éviter tout problème de dépendance, de code cassé, ou n’importe laquelle des millions de choses qui pourraient mal se dérouler. La raison pour laquelle vous êtes nerveux n’est pas que vous pourriez manquer d’expérience. Il est important de savoir que vous n’êtes pas seul dans ce cas. Que nous l’admettions ou non, beaucoup d’entre nous ont été (et sont probablement encore) dans cette situation. Il est triste que cette inaction — découlant de la peur de détruire un système fonctionnel — conduise souvent à des services en fonctionnement qui ont souvent plusieurs versions de retard, ce qui implique de nombreuses failles de sécurité potentiellement sérieuses. Cependant, soyez assuré que ce n’est pas la seule manière de jouer le jeu.

Les gens ont tendance à jouer un jeu différent selon qu’ils aient une infinité de vies ou qu’ils doivent recommencer depuis le début dès lors qu’une seule erreur a été commise. Pourquoi devrait-il en être autrement pour de l’administration systèmes ? Aborder le concept de sauvegardes avec un état d’esprit offensif peut complétement changer votre conception de l’administration systèmes. Au lieu de vivre dans la peur d’une dist-upgrade complète (ou de son équivalent pour yum, pacman, etc.), celui qui est armé de sauvegardes est libre de mettre à jour les paquets d’un serveur, confiant dans le fait que ces changements pourront être annulés si les choses tournent au vinaigre. La clé du succès réside tout entière dans l’état d’esprit. Il n’y a aucune raison d’avoir peur tant que vous avez vos données sauvegardées sous la main comme filet de sécurité lorsque vous sautez le pas. Après tout, l’administration système est une expérience d’apprentissage permanente.

Bien sûr, si vous ne validez pas vos sauvegardes, vous reposer sur elles devient un jeu très dangereux. Heureusement, les administrateurs systèmes expérimentés savent que le commandement « Garde des sauvegardes à jour » est toujours suivi par « Valide tes sauvegardes ». À nouveau, c’est un mantra que les gens aiment réciter. Ce qui, en revanche, ne tient pas de façon élégante dans un mantra entraînant est la manière de valider rapidement et simplement ses sauvegardes. La meilleure manière de dire qu’une sauvegarde est fonctionnelle est, bien sûr, de la restaurer (de préférence sur un système identique qui n’est pas en cours d’utilisation). Mais, une fois encore, en l’absence d’un tel luxe, on doit faire preuve d’un peu plus de créativité. C’est là (tout du moins pour les fichiers) que les sommes de contrôle peuvent vous aider à vérifier l’intégrité de vos fichiers sauvegardés. Dans rsync, par exemple, la méthode utilisée par défaut pour déterminer quels fichiers ont été modifiés consiste à regarder la date et l’heure de la dernière modification, ainsi que la taille du fichier. Cependant, en utilisant l’option ‘-c’, rsync utilisera une somme de contrôle MD4 de 128 bits pour déterminer si les fichiers ont changé ou non. Bien que ce ne soit pas toujours la meilleure idée à mettre en œuvre à chaque fois en toute occasion — à cause d’un temps d’exécution beaucoup plus long qu’un rsync normal et d’une utilisation accrue des accès disques — cette méthode permet de s’assurer que les fichiers sont intègres.

Le rôle d’un administrateur systèmes peut être éprouvant par moments. Il n’est cependant pas nécessaire de le rendre plus stressant que nécessaire. Avec le bon état d’esprit, certaines commandes de précaution apparemment à but unique et limité peuvent être utilisées comme des outils précieux qui vous permettent de progresser de façon agile, tout en gardant votre santé mentale intacte et la vitesse tant appréciée dans les projets open source.




Être administrateur systèmes : ne pas s’enfermer dans une spécialité ? (Libres conseils 8/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang :lerouge, lamessen, CoudCoud, Kev, peupleLa (relectures),Goofy, JejJulius22, kalupa, 4nti7rust, ga3ligTsigorf, maat

Aimer l’inconnu

Jeff Mitchell

Jeff Mitchell passe ses journées de travail à s’activer sur tout ce qui touche aux ordinateurs et aux réseaux et son temps libre à barboter dans toutes sortes de projets de logiciels libres et open source. Ce qu’il préfère c’est la convergence des deux. Après avoir travaillé en tant qu’administrateur systèmes professionnel de 1999 à 2005, il maintient son niveau de compétences en les mettant bénévolement au service de projets libres en divers lieux. Ces temps-ci, son activité pour le Libre est dédiée à l’administration systèmes pour KDE1 et c’est l’un des développeurs principaux du lecteur Tomahawk2. Jeff vit actuellement à Boston, aux États-Unis.

Récemment, à mon travail, j’ai fait partie d’une équipe qui faisait passer les entretiens d’embauche pour un poste d’administrateur systèmes. Après avoir parcouru quelques dizaines de curriculum vitae nous avons finalement convoqué notre premier candidat. Celui-ci — appelons-le John — avait aussi bien l’expérience de petites structures, style laboratoire informatique, que de plus vastes opérations dans des centres de données. À première vue, les choses se présentaient bien, si ce n’est qu’il avait eu cette réponse bizarre à quelques-unes de nos questions : « je suis administrateur systèmes ». Le sens de cette phrase n’a pas été immédiatement clair pour nous, jusqu’à ce que l’échange suivant ait lieu :

Moi : Donc, vous avez dit que vous n’avez pas d’expérience avec Cisco IOS, mais qu’en est-il des réseaux en général ?

John : Eh bien, je suis administrateur systèmes.

Moi : Oui, mais que diriez-vous sur les concepts de réseau ? Les protocoles de routage comme BGP ou OSPF, les VLANs, les ponts réseaux…    

John, exaspéré : Je suis administrateur systèmes.

C’est à ce moment-là que nous avons compris ce qu’il voulait dire. John ne nous disait pas qu’il connaissait toutes ces choses que nous lui demandions puisqu’il était administrateur systèmes ; il nous expliquait que parce qu‘il était administrateur systèmes, il n’en savait rien. John était administrateur systèmes et cela signifiait pour lui que ces tâches étaient celles d’un administrateur réseau. Sans surprise, John n’a pas obtenu le poste.

Dans bien des projets open source, la spécialisation est une malédiction et non une bénédiction. Qu’un projet relève d’une catégorie ou l’autre dépend souvent de la taille de l’équipe de développement ; la spécialisation à l’extrême peut entraîner de graves perturbations dans un projet en cas de départ d’un développeur, que ce soit en bons ou mauvais termes, qu’on le regrette ou non. Il en va de même pour les administrateurs systèmes de projets open source, bien que la pénurie générale de ces derniers semble autoriser aux projets une marge de tolérance parfois dangereuse.

L’exemple le plus flagrant qui me vienne à l’esprit impliquait un projet spécifique dont le site de documentation (y compris toute celle de l’installation et de la configuration) était indisponible depuis plus d’un mois. La raison : le serveur était en panne et la seule personne qui en avait l’accès naviguait sur un « bateau pirate » avec les membres du parti pirate suédois. C’est une histoire vraie.

Cependant, tous les points de défaillance ne sont pas dus à l’absence des administrateurs systèmes ; certains sont artificiels. Sur un gros projet, les décisions des droits d’accès à l’administration systèmes étaient assumées par un seul administrateur. Il ne s’était pas seulement réservé certains droits d’accès uniquement pour lui-même (vous l’avez deviné : oui, il a disparu pendant un certain temps, et oui, cela a causé des problèmes) ; il avait aussi décidé de la façon dont les droits d’accès devaient être accordés, en fonction de la confiance qu’il portait personnellement au candidat. La « confiance », dans ce cas, se fondait sur une seule chose : non pas le nombre de membres de la communauté qui se portait garant pour cette personne, ni depuis combien de temps cette personne était un contributeur actif et de confiance pour le projet, ni même depuis combien de temps il connaissait lui-même cette personne dans le cadre de ce projet. Au lieu de cela, elle reposait sur la façon dont il connaissait personnellement quelqu’un, ce par quoi il entendait la façon dont il connaissait cet individu en personne. Vous imaginez bien à quel point cela est adapté à une équipe d’administrateurs systèmes disséminée sur toute la planète…

Bien sûr, cet exemple ne fait qu’illustrer la grande difficulté pour un administrateur systèmes open source de trouver le juste milieu entre sécurité et capacité. Les grandes entreprises peuvent se permettre d’avoir du personnel redondant, et ce, même si le travail se répartit selon différentes responsabilités ou domaines de sécurité. La redondance est importante. Mais qu’en est-il si la seule possibilité d’avoir une redondance pour l’administrateur systèmes est de prendre la première personne se présentant au hasard sur votre canal IRC ou une personne quelconque proposant son aide ? Comment pouvez-vous raisonnablement avoir confiance en cette personne, ses capacités et sa motivation ? Malheureusement, seuls les contributeurs principaux du projet ou une petite partie d’entre eux peuvent savoir quand la bonne personne se présente en utilisant le même modèle de toile de confiance3 qui sous-tend une grande partie du reste du monde open source. L’univers des projets open source, leurs besoins et les personnes qui veulent contribuer à un projet particulier forment une extraordinaire diversité ; par conséquent, la dynamique humaine, la confiance, l’intuition et la manière d’appliquer ces concepts à un projet open source sont de vastes sujets, bien au-delà de la thématique de ce court article.

Une chose importante a cependant facilité la découverte de cette ligne d’équilibre sécurité/capacité : l’essor des systèmes de gestion de versions distribués, ou DVCS (NdT : Distributed Version Control System, système de gestion de version distribué). Auparavant, les contrôles d’accès étaient primordiaux car le cœur de tout projet open source — son code source — était centralisé. Je me rends bien compte que beaucoup doivent penser : « Jeff, tu devrais pourtant le savoir, le cœur d’un projet, c’est sa communauté, pas son code ! ». Ma réponse est simple : les membres de la communauté vont et viennent, mais, si quelqu’un fait accidentellement un « rm -rf » sur tout l’arbre du système de gestion de versions de votre projet et que vous manquez de sauvegardes, combien de ces membres de la communauté vont continuer à s’investir dans le projet et aider à tout recommencer à zéro ? (Mes propos se basent sur une histoire vraie dans laquelle un membre de la communauté saoul qui s’énervait à déboguer un bout de code, lança un « rm -rf » sur toute sa contribution, avec l’intention de supprimer tout le code du projet. Par chance, il n’était pas administrateur systèmes et n’avait donc pas accès au dépôt central, et il était trop saoul pour se rappeler qu’il travaillait seulement sur une copie du projet.)

Le code du projet est son cœur ; les membres de sa communauté en sont l’énergie vitale. Privé de l’un ou de l’autre, vous aurez du mal à garder un projet vivant. Avec un logiciel de gestion de version (NdT : VCS pour version control system) centralisé, si vous n’avez pas eu la présence d’esprit de mettre en place un système de sauvegarde régulier, vous pourriez, avec de la chance, ré-assembler l’arborescence complète du code source à partir des différents éléments contribués qu’auront gardés les autres personnes. Mais pour la majorité des projets, l’historique du code est aussi important que le code lui-même et cela, vous l’aurez tout de même entièrement perdu.

Ce n’est plus le cas désormais. Quand tous les clones locaux ont tout l’historique du projet et que des sauvegardes de secours peuvent être effectuées chaque nuit, en lançant une tâche planifiée aussi simple que « git pull », les dépôts centralisés ne sont plus que des outils de coordination. Cela en diminue l’importance de quelques degrés. Le projet doit toujours être protégé contre les menaces aussi bien internes qu’externes : les systèmes non corrigés sont toujours vulnérables à des exploits bien connus. Un administrateur systèmes malveillant peut tout mettre sans dessus dessous, un système d’authentification déficient peut permettre l’entrée de codes malveillants dans la base, et un « rm -rf » accidentel sur le dépôt central peut toujours coûter cher en temps de développement. Mais ces défis peuvent être surmontés, et à l’ère des serveurs privés virtuels (VPS) abordables et des centres d’hébergement de données, les absences des administrateurs systèmes peuvent également être compensées. (Il vaut mieux cependant s’assurer d’avoir un accès redondant au DNS ! Oh et mettez aussi vos sites internet sur un dépôt vérifié et certifié [DVCS] , et faites des branches pour les modifications locales. Vous me remercierez plus tard.)

Les DVCS permettent la redondance du cœur de votre projet pour trois fois rien, ce qui est une bonne façon d’aider les administrateurs systèmes à dormir la nuit et nous donne l’impression d’être un peu des maîtres du temps. Cela veut aussi dire que si vous n’êtes pas sur un DVCS, arrêtez de lire immédiatement et passez sur l’un d’eux. Ce n’est pas qu’une question d’espace de travail et d’outils. Si vous vous souciez de la sécurité de votre code et de votre projet, vous migrerez.

La redondance du code source est une nécessité, et en général plus vous avez de redondances, plus vos systèmes sont robustes. Il semble aussi évident que vous voulez une redondance de vos administrateurs systèmes ; ce qui vous semblera peut-être moins évident, c’est que l’importance de la redondance ne se joue pas tant en termes de personnes qu’en termes de niveau des compétences. John, l’administrateur systèmes, a travaillé dans des centre de stockage des données et au sein d’entreprises qui avaient des systèmes d’administration redondants mais des niveaux de compétences rigides, définis. Cela fonctionne dans de grandes entreprises qui peuvent payer pour embaucher de nouveaux administrateurs systèmes avec des compétences à la carte. Mais la plupart des projets open source n’ont pas ce luxe. Vous devez faire avec ce que vous avez. Cela veut dire bien sûr que, pour que l’administration systèmes soit redondante, une solution — et c’est parfois la seule — consiste à répartir la charge : d’autres membres du projet prenne chacun  une ou deux compétences jusqu’à ce qu’il y ait redondance.

Il n’y a guère de différence entre le côté développement et le côté créatif d’un projet ; si la moitié de votre programme est écrite en C++, l’autre moitié en Python, et qu’un seul développeur sait programmer en Python, son départ du projet provoquera de gros problèmes à court terme et pourrait aussi causer de sérieux problèmes à plus long terme. Encourager les développeurs à se diversifier et à se familiariser avec d’autres langages, paradigmes, bibliothèques, etc. entraîne que chacun de vos développeurs gagne en valeur ; cela ne devrait pas choquer : l’acquisition de nouvelles compétences est le résultat d’un apprentissage qui se poursuit tout au long de la vie, et un personnel mieux formé a aussi plus de valeur. (Cela rend aussi le curriculum vitae de chacun plus attractif, ce qui devrait être une bonne motivation.)

La plupart des développeurs open source que je connais considèrent comme un défi et un plaisir de s’aventurer sur de nouveaux territoires : c’est justement ce genre d’état d’esprit qui les a menés à développer de l’open source au départ. De même, les administrateurs de systèmes open source sont une denrée rare, et ne peuvent se permettre de s’enliser dans une routine. De nouvelles technologies intéressantes pour les administrateurs systèmes apparaissent constamment et il existe souvent de nouvelles façons d’utiliser des technologies actuelles ou anciennes afin de renforcer l’infrastructure ou d’améliorer leur efficacité.

John n’était pas un bon candidat parce qu’il apportait peu de valeur ajoutée ; et il apportait peu de valeur car il n’était jamais allé au-delà des limites du rôle qui lui était attribué. Les administrateurs systèmes open source qui tombent dans ce piège ne nuisent pas seulement  au projet dans lequel ils sont impliqués sur le moment, ils réduisent  leur valeur pour d’autres projets utilisant des technologies d’infrastructure différentes et qui auraient vraiment besoin d’un coup de main ; cela diminue les capacités globales de la communauté open source. Pour un administrateur de logiciel libre efficace, il n’existe pas de zone de confort.

  1. http://www.kde.org/ ^
  2. http://www.tomahawk-player.org/ ^
  3. http://fr.wikipedia.org/wiki/Toile_de_confiance ^