Auto-hébergement, fausse bonne idée - aeris

aeris

Titre : Auto-hébergement : la fausse bonne idée ?
Intervenant : aeris
Lieu : Hack2g2 - Vannes
Date : Mai 2017
Durée : 42 min 40
Visionner la vidéo
Support de la présentation : format PDF ou en ligne
Licence de la transcription : Verbatim
NB : Transcription réalisée par nos soins.
Les positions exprimées sont celles des intervenants et ne rejoignent pas forcément celles de l'April.

Description

L'auto-hébergement, ou pourquoi ça n'est pas si bon qu'on ne le pense.
Face aux GAFAM, l'auto-hébergement paraît être la solution idéale pour reprendre le contrôle de ses données personnelles et sa vie privée en ligne. Les initiatives dans le monde du Libre se multiplient et on peut citer des projets tels que La Brique Internet, YunoHost, et bien d'autres qui se sont développés au fil des années. Malgré cela, l'expérience peut aussi avoir de mauvais côtés.

Transcription

Bonjour à tous. On est partis pour une heure de conférence. J’ai essayé de garder un peu de temps sur la fin parce que je pense qu’il y aura pas mal de questions, histoire qu’on puisse un peu interagir.

Pour me présenter rapidement, je suis aeris, je me définis moi-même – et les agences de renseignement me définissent comme ça – le groupe cyberterroriste individuel auto-radicalisé sur Internet.

Vous pouvez me contacter par mail, mon Mastodon et mon blog, mon site qui référencera la conférence-là qui sera publiée. Si ça ne répond pas pour le moment, ne vous inquiétez pas, mes serveurs sont juste en train d’être saisis par l’ANSSI [Agence nationale de la sécurité des systèmes d'information], pour le moment. Ça reviendra petit à petit, mais voilà ! Il y a un peu de boulot!

Sinon, je milite pas mal autour de Café Vie Privée1, autour du Tor Project2et, ma vie en vrai, je suis développeur chez Cozy Cloud3 ; on en parlera un peu plus tard d'ailleurs. Je vais aussi taper dessus, je ne vais pas taper que sur les autres !

On est là aujourd'hui pour voir l’auto-hébergement. C'est quelque chose qui a un peu le vent en poupe. On en entend parler beaucoup, il y a beaucoup de solutions qui sortent dans le commerce, un peu partout. Il y a aussi des solutions associatives, on va parler de YunoHost4, La Brique Internet5 et d’autres de ce type-là.

Je me suis posé la question de « pourquoi ça marche, pourquoi ça ne marcherait pas, quels sont les problèmes que l’auto-hébergement va amener chez vous ? », surtout dans le contexte actuel de toutes les saloperies qu’il va y avoir dans le réseau.

On va commencer par définir ce que c’est l’auto-hébergement exactement, parce qu’il y en a de toutes sortes ; qu'est-ce que c'est, qu'est-ce que ce n'est pas ; les problématiques qu’il peut y avoir derrière et les solutions potentielles pour les éviter et puis la séance de questions.

D’abord, qu’est-ce que c'est l’auto-hébergement ? Moi je vais cataloguer ça en trois catégories. Il y a ce que je vais appeler le vrai auto-hébergement, mais ce n’est pas péjoratif, vrai ou faux, c’est juste que le vrai auto-hébergement c’est quand tout le matériel est chez nous, à la maison, au pied de notre lit, sur une Raspberry Pi, sur un PC allumé.

Il y a le faux auto-hébergement. On va faire la même chose, mais ça va plutôt être dans des datacenters, un serveur qu’on va louer en mutualisé, en serveur dédié ou autre, mais du coup c’est nous qui l’administrons.

Il y a aussi quelque chose qu’on oublie assez souvent, c’est l’Internet des objets, Internet of things, où on va avoir plein de matériel aussi connecté chez nous : la porte de frigo, le vibromasseur, la fontaine à chat, etc. et, du coup, ce sont aussi des choses qui vont être dans votre réseau, chez vous, et donc on le pourrait voir d’une certaine manière comme un auto-hébergement, mais avec des trucs un peu particuliers, d'ailleurs, à gérer.

Ce qui n’est du coup pas vraiment de l'auto-hébergement, enfin pas du tout de l’auto-hébergement, c’est tout ce qui va être de l’infogérance : vous avez des machines qui sont gérées par d’autres administrateurs systèmes, mais pour faire tourner vos services à vous. Et puis le fameux cloud, dont on ne sait pas trop ce que ça veut dire. Vous consommez du service ; vous ne savez pas qui le gère, comment, pourquoi, où. Ces deux-là ne sont pas de l’auto-hébergement, du coup on ne va pas en parler aujourd’hui.

Je vais commencer par le plus fun, le plus marrant, c’est l’Internet of things. Tous les trucs, aujourd’hui, qui vont être connectés à votre réseau chez vous ; ça va être vos frigos, vos montres, les ours en peluche aussi qui commencent à arriver, les sextoys ; il y en a des paquets dans tous les coins. Le problème de ces trucs-là c'est que la sécurité, aujourd’hui, est proche de zéro. Les mises à jour, il n’y en a quasiment jamais ; il y a des mauvaises pratiques qui sont en œuvre, des réseaux wifis qui sont publics pour que les machins puissent communiquer entre eux ; il n’y a pas de mots de passe ; les mots de passe par défaut sont trop faibles et sont toujours les mêmes : admin/admin, root/root, généralement ça passe sans trop de soucis. C’est un peu l’infection aujourd’hui. On en a dans la presse, en permanence, de trucs qui ne sont pas mis à jour, complètement vérolés, qui leak votre vie privée. On a eu, par exemple, la caméra du vibromasseur qui a été exposée sur un réseau wifi sans mot de passe et qui diffusait à 30 mètres de portée. Si, en plus, vous aviez une petite caméra de vidéo surveillance chez vous qui diffusait aussi votre vidéo, vous aviez l’intérieur et l’extérieur, ce qui peut donner des trucs fun sur PornHub, par exemple derrière ; mais c’est le bordel infâme !

Le problème c'est qu'on a aussi des pertes de contrôle. On a eu le cas récemment. Quelqu’un a acheté une porte de garage soi-disant connectée, et puis il n’en était pas content. Il l’a montée chez lui, ça ne marchait pas vraiment et il a posté un commentaire un peu incendiaire en disant « voilà, ma porte de garage ne marche pas ; c’est pas ce qu’on m’avait promis. » Le constructeur a dit : « Tu nous critiques, je te bloque ta porte de garage ! » Il est arrivé chez lui, il était content, la porte de garage ne s’ouvrait plus ! Effectivement, le fabricant a bien dit : « Je bloque ta porte et tu n’as plus le droit de te connecter, ton téléphone est blacklisté et donc tu ne peux plus ouvrir ta porte. » Là c’était une porte de garage, donc ce n’est pas forcément gênant, mais on imagine que ça pourrait être la porte d’entrée de chez vous. Il y a beaucoup aujourd’hui de solutions où tout est connecté et si le fabricant disparaît ou décide de vous blacklister, vous vous retrouvez dans des situations qui peuvent être un peu bordéliques.

Tous ces défauts viennent, pour moi, d’une seule chose. C’est qu'en fait, on va résumer ça simplement, Internet c’est compliqué. Quand on veut faire de l’hébergement à la maison, on a beaucoup de choses qui vont entrer en ligne de compte. On va avoir la topologie du réseau ; eh bien on ne connaît pas ! On a un matériel qui vient de l’extérieur, qui est fait par un fabricant tiers, eh bien je ne sais pas comment est configuré le réseau, quelle est son adresse de réseau local, quelle est la machine d’administration chez lui ; qu’est-ce que c'est ce machin, là, qui est en train de communiquer sur le réseau ? C’est juste un frigo qui est aussi en train de passer sa commande sur Amazon ou de télécharger des vidéos YouPorn, puisqu'il y a eu un fabricant qui s’est fait infecter comme ça : le frigo affichait des vidéos pornos dans le magasin. Donc on a un truc qui va être connecté dans un réseau et on ne sait absolument pas ce qui va graviter autour de ça.

Quand on est administrateur système, normalement vous avez dû apprendre que quand on fait la cartographie réseau, on dit qui a le droit de communiquer avec quoi ; on connaît les adresses de ports, on sait dans quoi on va atterrir. Quand le fabricant de la caméra de la porte de garage ou autre, va lancer son truc, il ne sait pas où il va finir. Donc du coup, il est obligé de faire des règles qui vont marcher partout. Des règles qui vont marcher partout, ça veut dire des règles qui ne font rien du tout. On ne peut pas blacklister, par exemple, le port SSH de la box, enfin du bidule qu'on va connecter, on ne peut pas le blacklister pour le limiter uniquement à l’adresse IP de la machine d’administration qui est vraiment celle de l’administrateur chez soi. C’est compliqué à faire.

En plus on a toutes les problématiques genre adresses IP dynamiques, parce que le grand public est chez Orange, SFR, Bouygues, Numericable, et donc a des IP qui bougent en permanence, des ports qui sont bloqués. Pareil, comment on va faire pour gérer ces cas-là ? À chaque fois on a un matériel qui va changer d’IP en permanence, c’est difficile, en tant que constructeur tiers, de dire ça va fonctionner, je vais le sécuriser pour que ça fonctionne dans le réseau.

En plus on a les problèmes de NAT [network address translation] par exemple. Si vous avez un matériel derrière votre box ADSL, il va falloir ouvrir un port sur le NAT pour faire rentrer le trafic, pour qu'on puisse communiquer de l’extérieur vers le bidule connecté. Et puis il y a des petites particularités, par exemple le hairpinning niveau NAT qui fait que, depuis l’extérieur votre bidule box va bien répondre ; par contre, depuis l’intérieur du réseau, le machin se mord la queue et vous allez tomber sur l’interface d’administration du routeur ou de votre box ADSL et pas de votre machin box, enfin de votre objet connecté.

Un enfer ! J’ai un peu bossé là-dedans dans mon ancienne SS2I. On arrive avec des bonnes préconisations réseau et bonnes préconisations de sécurité ou autres et derrière on se rend compte que quand on est dans un réseau qu’on ne connaît pas, qui n’est pas maîtrisé, on ne sait pas faire. En plus de ça, le marketing derrière, eux vendent des trucs comme ce sont des briques plug and forget, « vous branchez, vous oubliez », vous n’avez rien à configurer, ça se démerde tout seul comme un grand ! Ce qu’ils appellent dumb-proof c’est, en gros, même un neuneu doit pouvoir s’en servir. Ils ne veulent pas avoir une doc de deux mille pages, ils ne veulent pas que les personnes aient besoin de compétences réseau pour configurer tout ça. Parce que si la première fois que vous branchez par exemple votre porte de garage et qu’on vous demande d’aller sur l’interface administrateur de la porte et que la première question qu’on vous pose est quelle est votre adresse de réseau et votre masque de sous-réseau, vous allez perdre 99 % de la planète. Et pourtant vous en avez besoin si vous voulez sécuriser, genre faire un firewall qui tienne la route.

En plus, ils veulent des choses qui ne coûtent pas cher. Forcément, si vous prenez une ampoule connectée, ils veulent vendre ça plutôt aux alentours de 20 euros ; ils n’ont pas envie de vendre ça 2000 euros, parce que personne ne va acheter dix ampoules à 2000 euros. Le problème c'est que si on veut faire de la sécurité, ça coûte vite très cher. Un très bon exemple que j’ai eu, c’était sur des espèces de tablettes numériques connectées. Le jour où on leur a dit il faut mettre un mot de passe différent pour chacune des boîtes que vous allez vendre ! Ça voulait dire qu’il fallait changer la chaîne de production. parce que les Chinois sont très forts pour faire des clones de 5000 machines, y compris l’adresse MAC qui est la même sur toutes les machines, quand il faut leur dire que chaque image que vous allez flasher, il faut la refaire, la re-générer pour changer l’adresse MAC, pour changer le mot de passe par défaut ou autre, la chaîne de production ce n’est pas du tout la même ! En plus de ça, le mot de passe par défaut n’est pas le même, donc on arrête d'imprimer les livrets à la chaîne. Il faut imprimer les livrets un par un, en mettant le mot de passe qui correspond à la box, c’est-à-dire, qu’il faut faire des associations entre la box et le livret qui est imprimé. Donc en termes de logistique, vous passez d'un truc chaîne de production massive, avec 5000 box en une fois, à des trucs unitaires qui vous demandent des processus de logistique très compliqués ; et oui, vous arrivez vite à des systèmes qui coûtent 200, 300, 400, 500 euros, juste pour gérer les bonnes pratiques de changer un mot de passe, de ne pas avoir le même par défaut, et en plus qui ne soit pas admin/admin. Et vous allez aussi vous taper le support, parce que les mots de passe compliqués, les utilisateurs vont avoir du mal à les taper. Les I et les l ; les 1 et les i ; les O et les 0… Vous êtes sûrs que vous allez avoir une térachiée de support, parce que admin/admin c’est très bien quand on veut se connecter, mais vous êtes sûrs que vous n’avez pas de support dedans. Donc le marketing vend des trucs comme ça ; c'est juste pas compatible avec du réseau, avec de la sécurité, avec faire les choses proprement.

Parce que la sécurité c’est aussi compliqué. TLS [Transport Layer Security] je n’en parle pas, mais je fais des conférences ; ça peut durer quatre heures pour expliquer comment on doit gérer correctement TLS. Ça veut dire qu’il faut se taper les anciens navigateurs Internet Explorer 6, XP, tous ces trucs-là. TLS est aussi très coûteux ; c’est-à-dire que les fabricants, aujourd'hui, vont faire des petites cartes TLS hardware qui vont coûter 20 balles, sauf que ça n’a pas de mémoire. Donc la liste des autorités de certification qui font quelques mégaoctets à stocker sur la carte, vous oubliez ! Donc on vous dit : « On fait du TLS », par contre on ne vérifie rien, vous n'avez pas de certificat de vérifié, donc tout va passer comme il faut, man-in-the-middle ça va passer, etc. Pareil : la petite carte qui a 60 octets de mémoire, ça va coûter 20 euros, la carte avec dix méga de mémoire vous allez en avoir pour 200 balles.

Les firewalls, ça devient le bordel. Il y a cinq ans de ça, on disait : « Vous bloquez tout le trafic externe et ça devrait suffire ; vous allez déjà vous mettre à l’abri des merdes ! » Sauf que maintenant l’ennemi est dans le réseau ; il est chez vous ! C’est votre frigo, c’est votre montre connectée, c’est votre téléphone, c’est votre sextoy, c’est votre porte de garage, c’est whatmille trucs qui sont dans le réseau et qu’il faut aussi prendre en compte. On a eu des cas, par exemple, de frigos connectés qui étaient infectés, qui se mettaient à brute forcer les ports SSH [Secure Shell] des machines du réseau local. Bon courage quoi ! Pareil pour une personne lambda, connaître l’adresse IP de son frigo qui est généralement, en plus, en dynamique, en DHCP [Dynamic Host Configuration Protocol], qui peut changer quand il y a une panne de courant, enfin le bordel, eh bien faire un firewall qui tienne la route, c’est le merdier !

Les mises à jour. Comment vous faites pour aller flasher, pousser les mises à jour sur 5000 lampes connectées, sachant que vous allez avoir, même à 1 % de taux de panne, vous allez avoir un support qui explose à chaque mise à jour ? Des ampoules ne vont plus redémarrer ; ça fait drôle de le dire, mais c’est ça. Il faut gérer deux systèmes d’exploitation, en général, en parallèle, on met à jour le système numéro 2, on boot dessus et, si ça ne marche pas, on revient sur le numéro 1. Mais il ne faut pas qu'on plante, il ne faut pas qu'on bricke notre ampoule connectée ; donc il faut tout dupliquer, ça demande plus de mémoire, du développement en plus, etc. C’est compliqué !

Et puis les problèmes de logistique dont je parlais tout à l’heure, les flashs unitaires, les impressions de livrets, c’est vraiment la galère à gérer.

En fait, l’Internet des objets, si aujourd’hui ce n’est pas vraiment sécurisé, c’est parce qu’Internet c’est compliqué pour plein de raisons, DNS, noms de domaine, les adresses IP, le NAT, etc. Le marketing vend ça comme étant très simple et accessible à tous, « vous achetez, vous pluggez, vous oubliez. » Et la sécurité. La sécurité c’est un processus et on est censés le faire évoluer régulièrement, se tenir informés, faire les correctifs qui vont bien. Et donc on a ces trois trucs-là, qui vont collisionner en permanence entre « ça coûte cher, c’est compliqué, on veut du simple, on veut du pas cher ». Donc ça donne aujourd'hui l’Internet des objets tel qu’on le connaît.

Là on va attaquer le morceau qui nous intéresse : c'est l’auto-hébergement. Pourquoi est-ce que j’ai parlé de tout ça quand on va parler de l’auto-hébergement derrière ?

Aujourd’hui, il y a des solutions qui existent, YunoHost, Cozy Cloud, NextCloud, et on vous vend ça comme étant relativement accessible. N’importe qui, aujourd'hui, va pouvoir installer un YunoHost, un Cozy Cloud, un NextCloud. Vous avez même des images Raspi qui vont exister : vous prenez l’image, vous flashez, ça va marcher. On vous demande un peu de compétences en administration système, on ne va pas vous cacher que c’est compliqué — vous êtes accompagné dans l’association d'ailleurs, pour vous aider à comprendre comment ça marche et à faire les choses proprement — mais au final, on a toujours les problèmes de sécurité précédents, parce que les bonnes pratiques, c’est compliqué, c’est chiant, c’est énervant, même pour les utilisateurs ! Comme je vous dis, quand vous lancez un système, vous n’avez pas envie qu’on vous demande votre adresse de réseau et votre masque de sous-réseau, il y en a qui beaucoup ne savent pas répondre, et surtout, sur le long terme car, comme disait Bruce Schneier, « Security is a process, not a product ». D donc votre image Raspi qui était vraie il y a deux mois, comment vous faites quand vous vous tapez une faille TLS et qu’il faut reconfigurer votre Nginx6, il faut reconfigurer tout votre bordel pour tenir compte de ça et re-flasher les images ? Il y a certainement des personnes qui vont le faire, mais il y en a d’autres qui ne vont pas le faire, parce que la machine va rester comme ça, sans faire de mises à jour, oubliée dans un coin, au pied du lit, etc.

Et c’est un peu, entre guillemets, la « critique » que je fais et on verra tout à l’heure qu’il n’y a pas vraiment le choix. Les solutions sont ce que j’appelle « solutions centriques », c’est-à-dire qui vont gérer leur sécurité uniquement du point de vue de leur logiciel, c’est-à-dire que leur logiciel va effectivement être sécurisé. Par exemple, on va s’assurer que YunoHost en lui-même n’a pas de faille, n'a pas de problématique particulière, qu’on va faire les mises à jour régulières. Par contre, l’écosystème global d’où va tourner ce machin-là, on s’en fout un peu ! Ce que ça donne, c'est ça par exemple [diapo 13, Lukas Martini sur Mastodon].

Quand Mastodon a été publié récemment, beaucoup de monde s’est dit on va monter nos instances. Mastodon est sécurisé, les configurations Nginx sont très correctes, la sécurité est très bonne. Sauf qu'il y a des gens qui ont lancé des images Mastodon qui étaient fournies par des gens et se sont retrouvés avec des bases de données qui étaient publiées sur Internet parce que le firewall ne bloquait pas le port PostgreSQL. Ils ont utilisé du Docker et plein de systèmes comme ça, qui faisaient tous ces trucs-là étaient publiés sur le Net. Et donc il y a des serveurs complets qui étaient publiés à poil !

Un exemple de serveur Mastodon, c'est par exemple ça [diapo 14]. Ça fait tourner un serveur de nom de domaine local, BIND9, exposé sur le Net, Portmap est exposé, NTP est exposé, Netbios est exposé, Samba est exposé ; donc je pense que celui-là a dû se prendre une jolie vague de Wannacrypt7 derrière. Le serveur d’impression, le MDNS – qui est un protocole local de communication DNS – est sur le Net, le MySQL à poil et, oui, effectivement, Mastodon lui est sécurisé. Par contre, personne ne s’est posé la question de où allait tourner cette instance-là, que la personne n’était pas forcément compétente en administration système et ne va pas se rendre compte que oui, Mastodon est sécurisé, mais son écosystème lui ne l’est pas. Je pense que cette instance-là va se faire hacker très rapidement. Typiquement, Samba, je pense que s'il n'a pas fait les mises à jour, il y a de grandes chances que ça tombe quelque part.

Il y a la Brique Internet qui a essayé de faire les choses un peu plus packagées, on va dire, parce que justement, ils ne vendent plus uniquement un logiciel, comme Mastodon, comme YunoHost ou comme NextCloud ou Cozy Cloud. Ils ont dit : « On va venir carrément avec notre boîtier ; donc on va pouvoir aller un peu plus loin, justement, penser tout l’écosystème et pas juste le logiciel en lui-même. » Sauf qu’on a un peu les problématiques précédentes, en termes de mises à jour, en termes de comment configurer le firewall de la Brique Internet et on a aussi des problèmes spécifiques ; on en a beaucoup. Comment je fais un backup sur des cartes SD qui vont s’user à vitesse grand V ? On a déjà eu des retours de personnes : « La carte SD est morte ; comment je fais pour récupérer mes données ? Tu as des backup ? Ben non ! Tu as perdu ! » Du coup, ce sont des systèmes comme ça qu’il va falloir mettre en œuvre si on veut avoir de l’auto-hébergement safe.

En fait, aujourd’hui, si les systèmes précédents fonctionnent, c’est parce qu’on est dans un cas un peu particulier. On est sur de la petite série, on ne fait pas 5000 Briques Internet qu'on vend dans la nature ; il n'y a pas 5000 YunoHost ou Cozy Cloud ou autres dans la nature. Donc on n’est pas encore très intéressants pour un attaquant. Cent machines à infecter, il s’en fout ! Et en plus de ça, toutes les solutions font quand même de l’accompagnement aux utilisateurs. Quand vous installez une Brique Internet, on ne va pas vous filer la Brique Internet, « branche-là chez toi, oublie-là ! » Il y a des sessions d’installation, d’accompagnement, des meetups, des choses comme ça, pour essayer de faire prendre conscience aux gens, justement, du genre de problèmes dans lesquels ils vont se lancer.

Par contre, clairement, aujourd’hui pour moi, ça ne passe pas l’échelle. Si on se mettait à déployer de la Brique Internet à tout-va, à tout le monde, on ne pourrait pas suivre le rythme des meetups et accompagner les gens, donc ça va finir, entre guillemets, en « Internet of Shit ». La sécurité, ça va être difficile de la mener jusqu’au bout et on risque de finir dans les fameux trucs type Mirai8 qui ont infecté l’Internet des objets et de convertir les trucs hébergés en systèmes de malwares qui vont mettre en péril la sécurité du réseau dans son ensemble.

Le genre d'exemple qu’on peut voir aujourd’hui : il y a Shodan9 qui est une interface qui scanne l’intégralité du réseau. Tous les jours IPv4 est passé à la moulinette sur l’intégralité des IP, l'intégralité des ports. C’est entièrement publié sur Internet ; il y a une base de données, vous pouvez faire des recherches dedans. Aujourd’hui, vous tapez « yunohost/admin », vous avez 1113 instances YunoHost qui tournent et vous pouvez les lister. Donc si jamais il y a une faille de sécurité dans YunoHost, vous avez 24 heures pour mettre à jour, sinon Shodan, vous vous le prenez dans la tronche et votre machine est infectée immédiatement.

Histoire de taper un peu sur Cozy Cloud aussi, Cozy Cloud a le même problème. 527 instances Cozy Cloud dans la nature ; le jour où il y a une faille, les interfaces d’admin et autres sont publiées, donc là, pareil, j’ai un botnet de 527 machines potentiellement sous la main si une faille de sécurité est publiée et que les administrateurs ne font pas le boulot. Pareil sur NextCloud. On voit aussi tous les NextCloud qui tournent ; pareil, en cas de faille, un coup de Shodan et là j’ai 700 machines sous la main,prêtes à faire du spam, du DDoS, du Wannacry ou ce genre de trucs.

Aujourd’hui, c’est un peu ça le problème de l’auto-hébergement en général, c’est difficile de trouver un compromis entre je vais faire de la grande échelle, enfin je vais me déployer auprès de beaucoup de monde et de pouvoir assumer derrière la sécurité ambiante qui change toutes les deux semaines, qui demande des compétences d’administration système pour gérer un firewall, pour être capable de tout bloquer. Par exemple, pour éviter Shodan, je vais vous expliquer quand même comment faire, mais vous allez voir le niveau que ça demande !

Sur les machines, il faut mettre un vhost Nginx ou Apache par défaut qui serve une page vide, et ne pas mettre un vhost, NextCloud ou Cozy Cloud ou autre, spécifique. Comme ça, quand Shodan passe, il va tomber sur le port 443 par défaut, il va tomber sur le vhost par défaut puisqu’il ne connaît pas le nom de domaine, donc il va avoir la page «Hello world ou It works» en fonction de votre système. Mais ça veut dire qu'il faut que l’utilisateur renseigne un nom de domaine, ça veut dire qu'il faut qu'il renseigne une adresse IP. Enfin voilà ! Il va falloir qu’on lui pose des questions et ce n’est plus une Brique du coup, ce n’est plus une image qu’on va flasher sur une Brique, qu’on va démarrer ; ça demande de la configuration, ça demande beaucoup de choses.

Et en plus ça ne suffit pas, parce qu’aujourd’hui Shodan a été un peu plus loin. Il y a ce qu’on appelle le Certificate Transparency maintenant, qui est une obligation pour les autorités de certification TLS de publier dans des annuaires l’intégralité des certificats TLS émis. Donc ça veut dire, en allant interroger ces annuaires de Certificate Transparency, on a tous les noms de domaines qui ont un certificat qui correspond. Il suffit de coupler Shodan avec la base de Certificate Transparency et on a le nom de domaine. Donc du coup on peut essayer : je sais que telle IP répond à tel nom de domaine, donc j’essaie tous les noms de domaines publiés dans le Certificate Transparency et je vais tomber sur l’interface de YunoHost. Même là, il faudrait potentiellement utiliser des autorités de certification internes, pas publiques, pour éviter de finir dans la base et, donc pareil, il faut que l'utilisateur sache comment importer une autorité de certification dans son navigateur, etc. C’est compliqué à patcher. C'est pour ça que je n'en veux pas. Ce n’est pas une critique de YunoHost, de la Brique ou autre ; c’est très compliqué d’y arriver, et je ne pourrais demander à personne d'aller monter sa propre autorité de certification pour après demander à ses utilisateurs ou ses administrateurs, de l’installer, etc. C’est humainement pas possible !

Du coup, on a des problèmes aujourd'hui, que l’auto-hébergement ce n’est pas forcément une bonne idée. Je pense qu'ici il n’y a pas beaucoup de risques parce que les gens sont plutôt globalement formés, sensibilisés à ça et donc vont faire des efforts, mais pour le grand public, ça risque de coincer un peu. En tout cas, on ne passe pas l’échelle, clairement.

Une des solutions, par exemple, ça va être les CHATONS – les Collectifs d'Hébergeurs Autonomes Transparents Ouverts Neutres et Solidaires – qui vont entre guillemets, « faire le boulot pour vous ». On va vous fournir des services qui sont à peu près équivalents à ce que vous faites en auto-hébergement, du coup ce n’est pas vraiment de l’auto-hébergement, mais vous avez les mêmes services. Vous avez des conditions qui sont plus décentes que ce que vous allez avoir chez les GAFAM ou autres, parce que les données sont bien à vous, vous n'avez pas d’enfermement technologique, tout est documenté, tout est neutre, etc. Par contre, derrière, il y a des vrais admins sys, qui font vraiment leur boulot, qui sont capables de sécuriser leurs machines, de faire les mises à jour quand ça va mal, et donc qui vont s’occuper de toute la partie d'administration que vous, vous n’êtes pas capable de faire ou que vous n’avez pas forcément envie de faire ou etc. Du coup c’est plutôt une bonne solution.

Parce qu'en fait, les problématiques de l’auto-hébergement, ce sont les manques de compétences et les manques de disponibilité. Manques de compétences parce qu’on ne peut pas tous être admin sys, on ne peut pas être un expert dans tous les domaines DNS, IP, routage, firewall, sécurité, etc. Et manques de disponibilité, parce que même si on a ces compétences-là, je sais ce que c’est au quotidien, quand il faut mettre à jour en permanence les machines, on n’a pas le temps. On dit c’est bon, je le ferai plus tard ; et plus tard, en informatique ça veut dire jamais. Donc on a encore des machines avec des Nginx qui ne sont pas à jour, avec des TLS qui ne sont pas à jour, juste parce qu’on n’a pas le temps ; ce n’est pas notre boulot, on a autre chose à faire. OpenSSL c’est trois mises à jour par jour, quelque chose comme ça. Les configurations de TLS, même sur Mastodon aujourd’hui, on a des trolls entiers sur Github de quelle configuration de TLS il faut mettre, et personne n’est d’accord. Donc on va essayer de regarder ce que préconise l’ANSSI ou autre, mais il faut se mettre d’accord sur ce qu’on fait, comment on s’y prend et ça demande du temps.

Les CHATONS10 vont un peu aider à ça, il y a des administrateurs système dédiés à ça, de manière bénévole ou salariée, ça dépend du modèle des CHATONS, mais en gros il y a un engagement. Il y a un engagement à « on a des personnes compétentes qui maîtrisent ce qu’elles font, qui ont du temps à passer, donc on va essayer de faire les choses correctement. »

En plus de ça, les CHATONS, il y a ce que fait déjà aujourd’hui la Brique Internet et autres, il y a de l’accompagnement ; vous n’êtes pas lâché dans la nature. Si vous avez juste envie d’un service qui marche chez vous, vous allez avoir juste un service qui va tourner, qui va vous faire ce que vous attendez de lui. Mais si vous avez envie d’aller plus loin, si vous avez envie de vous intéresser à tout ça, il y a des formations, il y a de l’accompagnement, vous pouvez venir de l’autre côté de la barrière en disant « eh bien tiens, moi j’ai du temps, je suis administrateur système ou juste quelqu’un d’intéressé par tout ça. Vas-y, viens, on va te filer les clés du datacenter, viens nous aider, viens mettre tes compétences à dispo ! » Et vous pouvez du coup monter en compétences, et venir aider, justement, à monter d’autres systèmes, pour ne pas que ça grossisse trop et que ça ne devienne pas des GAFAM, et monter le vôtre. monter votre CHATON et forker. Faites des petits !

Du coup c'est vachement pédagogique. C’est bon pour le réseau parce que c’est quand même un sacré bordel ; quand on voit tout ce qui se passe aujourd’hui, c’est assez flippant. Je ne sais pas trop ce que ça va donner dans les temps à venir, mais quand on suit les problèmes de sécurité, c’est violent, c’est du Mirai, c’est WannaCrypt, c’est toutes les saloperies comme ça ; ce sont des DDoS à un térabit/seconde juste parce qu’il y a des Chinois qui ont allumé des caméras connectées dans des coins ; ça fait peur ! je pense que si on fait de l’auto-hébergement version pas bien cadrée, on risque plutôt d’amplifier le problème. On voit déjà plus de 1000 YunoHost exposés sur Internet ; je n’ai pas regardé qui était à jour là-dedans, mais je suppose que s'il y en a plus de 10 % à être à jour, on sera contents, parce qu'il y a de grandes chances que ce soient des versions pas mises à jour. Déjà, pour être exposés comme ça sur Internet, c’est que l’administrateur système n’a pas dû trop s’en occuper !

Ce sera ma conclusion ; après on va passer aux questions. L’auto-hébergement a de très bons points, de très gros intérêts : se passer des GAFAM, reprendre le contrôle de son système, éviter les gags un peu comme moi, j’avais des serveurs dédiés, le jour où le serveur a disparu, je n’ai pas de données. Heureusement, j’avais les backups, mais j’ai tout perdu, potentiellement ; ou le système en face qui ferme. Enfin il y a plein de raisons qui font que vous pouvez avoir un problème. La sécurité, c’est le bordel, et aujourd’hui il va falloir réfléchir à comment on fait pour se sortir des GAFAM sans devenir l’Internet of Shit. Il va falloir bien surfer entre les deux et bien viser là où il faut, régler les problèmes sans en apporter d’autres qui peuvent, potentiellement, être assez violents.

J’ai fait le tour, je ne sais pas si vous avez des questions. Benjamin, tu en as bien une ?

Public : Inaudible.

aeris : La question c’est : quand on a un certificat Let's Encrypt11 et qu’on héberge un service, comment on fait pour se mettre à l’abri de Shodan ?

En fait, il y a deux choses à faire. Il faut bien séparer la partie administration de la partie publique. Ton service public Let's Encrypt, il est public, enfin ton service hébergé qui est avec un certificat, il est public. Donc celui-là, à la limite, tu t’en fous, tu le laisses traîner, il n’y a pas de raison de ne pas le publier. Par contre, toute la partie back office avec ton interface d’administration, avec tous tes systèmes comme ça, déjà il faut essayer de le mettre sur un domaine qui ne soit pas celui de ton service véritable parce qu’une fois qu'on le connait on va tomber dessus. Donc oui, il faut avoir ta propre autorité de certification, tu génères des certificats à toi. Ça peut être un auto-signé ; si tu ne vas pas forcément jusqu’à la CA [certification authority ] complète, tu mets un certificat auto-signé ; du coup il n’apparaîtra nulle part, et donc tu protèges ton service d’administration par un certificat auto-signé.

Public : Inaudible. [Mais du coup en pratique, on fait comment pour se protéger ? NdT]

aeris : C’est là où c’est compliqué. Effectivement, il faut aller mettre les mains dans le code. Il faut sortir l’interface admin et la mettre sur autre chose. Ça veut dire qu’il faut configurer le YunoHost correctement et il faut, effectivement, savoir ce qu’on fait. Il y a des solutions un peu à l’arrache, on va dire : blacklister carrément le /admin de YunoHost sur l’interface publique et le republier sur l’interface privée avec un certificat à toi. Shodan, sur les failles, on pense que WannaCrypt s’en est servi.. Tu chopes tout ce qui tourne et tu n’as plus qu’à tester après. Tel service fait tourner telle version, donc on a telle faille et on y va, on lance le scan, et en deux heures ce sont des milliers de machines peuvent être infectées comme ça. Mais à chaque fois, sur des solutions sur des problèmes comme ça il faut réfléchir. Il n’y a pas de solution ou de recette magique « voilà le vhost Nginx, tu copies colles, ça marche », mais il faut se poser la question de comment j’y arrive, etc. Tu peux aussi restreindre, par exemple, ton interface admin à juste ton réseau local.

Public : Inaudible.

aeris : Pourquoi les Certificates Transparency ont été publiés ?

C’est pour éviter, en fait, les générations frauduleuses de certificats. Parce qu'aujourd’hui le problème, c’est que toutes les autorités de certification, n’importe qui peut émettre n’importe quoi. Du coup, il y avait des autorités de certification qui s’amusaient ; il y a eu l’ANSSI, par exemple en France, qui a signé des certificats en gmail.com. Avec le Certificate Transparency, on aurait vu dans la base de données – surtout Google aurait vu – qu’il y a un certificat gmail.com qui a été émis, qui ne correspond pas à une demande que eux ont faite, et donc ils auraient pu alerter directement l’autorité de certification en disant « je ne comprends pas, ce n’est pas moi qui ai demandé ça, donc blacklistez-le-moi ». Moi je scanne, par exemple, tous les TLS en imhiril.fr. Dans la base, je les scanne en permanence et si j’en vois qui ne sont pas des certificats que moi j’ai demandés, je peux demander à les blacklister.

Aujourd’hui, Let’s Encrypt est dedans ; la plupart des autorités de certification sont dedans. Aujourd’hui, de mémoire, ce n’est pas encore complètement obligatoire partout, mais ça le deviendra de toutes façons.

Public : Inaudible. [Comment fonctionne Certificate Transparency ? Ce sont les autorités ou les navigateurs qui font les vérifications et vont réagir en cas de problème ? NdT]

aeris : Non, ce sont les émetteurs de certificats qui doivent vérifier. Je ne crois pas que les navigateurs fassent la vérification. De toutes façons, côté navigateur, tu ne peux pas faire la distinction entre un certificat mal émis et un certificat valide. Tu vas juste savoir que telle autorité a émis tel truc.

Public : Inaudible. [Les autorités peuvent vraiment émettre n’importe quoi ? Ce n’est pas illégal d’émettre des certificats n’importe comment ? NdT]

aeris : Ce n’est pas illégal, ce n’est pas interdit, et il y en a beaucoup qui le font aujourd’hui. La plupart des CDN [Content Delivery Network], les gros systèmes de distribution de données, ont des autorités de certificat différentes pour chaque N [Network ; en réalité, c’est pour chaque endpoint. Note de aeris] de leur machine parce que c’est sur des pays différents, etc., donc il y a des cas où c’est totalement légitime. Ils ne devraient pas le faire pour d’autres raisons, ça pète plein d’autres choses dans la sécurité : TLSA, HPKP [HTTP Public Key Pinning], HSTS [HTTP Strict Transport Security], toutes ces merdes-là, mais on ne peut pas le deviner ; c’est forcément l’émetteur du certificat légal qui va savoir que ce n’est pas normal, ce certificat-là, ce n’est pas moi qui l’ai demandé, donc il y a un problème. C’est comme ça qu’on a pu détecter que Let’s Encrypt générait beaucoup de certificats en paypal.quelquechose. C’était du paypal, mais pas vraiment paypal. Ils utilisaient des caractères cyrilliques et ça faisait passer pour paypal, vous aviez l’impression d’aller sur paypal.com, et en fait non, je ne sais pas comment ça se prononcerait en russe. Encore un coup des Russes tiens !

C’est là qu’on se rend compte que pour une personne lambda, arriver à être à l’abri, aujourd’hui, en termes de sécurité, ça demande des compétences qui sont juste démesurées. On ne peut pas imposer à des gens d’avoir ce niveau-là quand ils vont héberger quelque chose chez eux. Le problème c’est qu’ils mettent aussi en danger aussi le reste du réseau, parce que le jour où ils sont infectés eh bien… Typiquement, mon serveur a disparu, a été saisi, parce que quelqu’un n’a pas sécurisé sa machine chez une OIV [Opérateurs d’Importance Vitale] française. Donc des serveurs sécurisés en arrivent à être saisis parce que des machines non sécurisées sont infectées ; parce que la machine infectée chez l’OIV s’est connectée à mon serveur, et l’ANSSI n’a pas fait ni une ni deux, cette machine-là fait partie du truc d’infection, donc on la saisit ! Ce serait pareil si c’était une caméra connectée ou même un YunoHost. YunoHost qui se fait infecter, il va venir brute forcer ma machine demain.

Public : Inaudible. [Est-ce qu’on a les mêmes problèmes avec les téléphones mobiles ? NdT]

aeris : Oui, il y a les téléphones pas mis à jour et le téléphone va être allumé ; il y a des tonnes d’applications débiles installées dessus. Aujourd’hui, je n’arrive pas à comprendre pourquoi les gens font pas plus mumuse avec ce genre de choses, parce qu'installer une application dégueulasse sur un téléphone « tiens, vas-y, tu vas jouer à Candy Crush, pendant ce temps-là je vais faire une map de ton réseau ! » Il y aurait des trucs fun à faire quoi ! Ou monter des réseaux wifis ou des Google Cars connectées sur toutes les lampes connectées et les faire clignoter, ou faire un pong avec les lampes des bureaux. Il y a des trucs quand même vachement fun, mais bizarrement, ça ne bouge pas, on voit quelques grosses attaques. On a eu Dyn12, on a eu Cedexis, on a eu des choses de ce type-là, mais ce n’est pas encore massif alors que potentiellement, il y a quelqu’un qui a un gros bouton rouge sous la main et qui peut dire « eh, stop Internet ! » Est-ce qu’il y a d’autres questions ?

Public : Inaudible. [Avec tous les problèmes de l’IoT, est-ce qu’Internet peut être en danger ? Est-ce qu’on peut faire tomber tout le réseau avec autant de failles dans le réseau ? NdT]

aeris : Oui, c’est possible. Schneir avait écrit un bon article de blog là-dessus en disant on ne comprend pas, on voit des choses de plus en plus ciblées, on voit du bordel infâme dans le réseau qui les aide, en plus. Avant il fallait trouver les botnets ; quand on voulait faire une attaque, par exemple par amplification de DNS pour faire tomber une machine, il fallait trouver des machines qui étaient faillibles, dans lesquelles on pouvait s’introduire, et généralement il n’y en avait pas des masses. C’étaient des serveurs d’entreprises qu’il fallait aller chercher à la pêche, mais les machines domestiques étaient derrière le NAT, derrière la box ADSL, donc on était quand même relativement à l’abri. Aujourd’hui, on a l’Internet des objets, le dernier DDoS en date, c’étaient des caméras IP chinoises. Ça maintenant, tu en as des paquets. Avant, un botnet de 10 000 machines ou 100 000 machines, il fallait le vouloir, et t’en prenais soin de tes machines, parce qu’une fois que c’était infecté ! Tu voulais la garder bien à l’abri. Aujourd’hui, tu sais que si tu en perds 10, tu en trouveras 100 en scannant un peu le réseau à côté.

Le genre de conneries que vous pouvez avoir, par exemple avec Shodan, sur Shodan vous cherchez les imprimantes réseau. Les universités ont la chance d’avoir des plages IPv4 assez énormes, et elles filent des adresses publiques IPv4 à leurs imprimantes. Donc vous avez des imprimantes complètes, vous avez l’interface d’administration de l’imprimante ; vous pouvez imprimer, changer le fond d’écran, et d’ailleurs vous tombez sur certaines imprimantes, le fond d’écran, vous sentez bien qu’il y a quelqu’un qui est passé avant ! Ou des trucs de gestion de vidéoprojection, des trucs comme ça, vous allez les avoir en public sur Internet. Je suivais des MOOC à distance en participant à des amphithéâtres de médecine d’université de l’Ohio parce que leur bordel machin était connecté. J’avais des formations en médecine gratuite ! En anglais c’est un peu indigeste quand même ! Par contre c’est marrant, on peut faire monter et descendre le vidéoprojecteur à distance. C’est le genre de trucs, avec un YunoHost pas à jour, je rentre dedans, j’ai accès à votre réseau , ou les imprimantes réseau que je vais scanner ou le réseau local. Si vous avez du Windows, généralement vous avez du Samba ou Netbios, ou des machins comme ça, donc je peux scanner le réseau, récupérer ce que vous imprimez. Il y a avait eu une attaque comme ça aussi : des petites imprimantes connectées, thermiques, pour imprimer des étiquettes. Ils avaient trouvé sur Internet ; ils avaient imprimé plein de trucs avec les imprimantes en disant « coucou, je suis ton imprimante, je suis maintenant douée d’une vie autonome » en imprimant des petits robots et des chatons.

Ça va être la fin, merci à vous. Et si vous avez des questions, de toutes façons, je serai dans le coin jusqu’à ce soir, donc n’hésitez pas.

[Applaudissements]