Différences entre les versions de « Auto-hébergement, Fausse Bonne Idée ? Aeris - PSES 2017 »

De April MediaWiki
Aller à la navigationAller à la recherche
(Aeris - Auto-hebergement, Fausse Bonne Idée ?)
 
(Aucune différence)

Version du 27 septembre 2017 à 07:33

  • Titre : Auto-hébergement, Fausse Bonne Idée ?
  • Intervenants : Aeris
  • Lieu : PSES 2017
  • Date : 20 mai 2017
  • Durée : 42 min 40
  • Média : Lien vers la vidéo : https://www.youtube.com/watch?v=3F7qHA0zF2E - Transparents : https://confs.imirhil.fr/20170520_hack2g2_autohebergement/#1

    Transcription

    Bonjour à tous,

    On est partis pour 1 h de conférence. J'ai essayé de garder un peu de temps sur la fin parce que je pense qu'il y aura beaucoup de questions, et pour qu'on puisse 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 – groupe de cyberterroriste individuel autoradicalisé sur Internet.

    Vous pouvez me contacter par courriel, par Mastodon et sur mon blog qui référencera cette conférence. 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. Sinon, je milite pas mal autour de cafés vie privée, autour du Tor Project et, en vrai, je suis développeur chez CozyCloud, on en parlera un peu plus tard. Je vais aussi leur taper dessus, pas seulement sur les autres.

    On est là parce qu'on entend beaucoup parler d'autohébergement, il a le vent en poupe en ce moment et beaucoup de solutions sortent dans le commerce. Il y a aussi des solutions associatives, comme YunoHost, La Brique Internet 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'autohé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 qu'est et ce que n'est pas l'autohébergement parce qu'il y en a de toutes sortes. On va parler des problématiques qu'il peut y avoir derrière, les solutions potentielles pour les éviter et enfin la séance de questions.

    D'abord, qu'est-ce que l'autohébergement ? Moi je vais cataloguer ça en trois catégories. Ce que j'appelle le vrai autohébergement. Ce n'est pas péjoratif, c'est juste que le vrai autohébergement c'est quand tout le matériel est chez nous à la maison. Au pied de ??? sur une Raspberry Pi, sur un PC allumé.

    Il y a le faux autohébergement qui est la même chose mais dans des data centers avec un serveur qu'on va louer en mutualisé, en serveur dédié ou autre, mais 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 connecté chez nous (la porte de frigo, le vibromasseur, la fontaine à chat, etc.) et, c'est aussi des choses qui vont être dans notre réseau chez nous et qu'on pourrait voir d'une certaine façon comme de l'autohébergement. Mais avec des éléments particuliers à gérer.

    Ce qui n'est pas du tout de l'autohébergement, c'est tout ce qui est l'infogérence, c'est-à-dire des machines gérées par d'autres administrateurs systèmes, mais pour faire tourner vos services à vous. Enfin, le fameux cloud, dont on ne sait pas trop ce que ça veut dire. On consomme du service sans qu'on sache qui le gère, comment, pourquoi, où. Ces deux-là ne sont pas de l'autohébergement, on ne va pas en parler aujourd'hui.

    Je vais commencer par le plus marrant, c'est l'Internet of things. Tous les trucs aujourd'hui qui vont être connectés à votre réseau chez vous : vos frigos, vos montres, les ours en peluche qui commençent à arriver, les sextoys, il y en a des paquets dans tous les coins. Le problème de ces objets est la sécurité qui est proche aujourd'hui de 0. Il n'y a quasiment jamais de mises à jour, des mauvaises pratiques sont en œuvre, comme des réseaux WiFi publics pour que les machins puissent communiquer entre eux, il n'y a pas de mot de passe, ceux par défaut sont toujours trop faibles et sont souvent les mêmes (admin/admin ou root/root, ça passe généralement sans trop de soucis). C'est un peu l'infection aujourd'hui, on a dans la presse en permanence des 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é sur un réseau WiFi sans mot de passe et qui diffusait à 30 m de portée. Si en plus vous aviez une caméra de vidéo surveillance chez vous qui diffusait aussi votre vidéo, vous avez l'intérieur et l'extérieur, ce qui peut donner des trucs funs sur pornup derrière. Mais c'est le bordel infâme.

    On a aussi le problème des pertes de contrôle. On a eu le cas récemment de quelqu'un qui a acheté une porte de garage soi-disant connectée, mais 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 ». Arrivé chez lui, sa 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é, tu ne peux plus ouvrir ta porte ». Là, c'est une porte de garage, 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 de solutions aujourd'hui où tout est connecté et, si le fabricant disparaît ou décide de vous blacklister, vous risquez de vous retrouver dans des situations qui peuvent être un peu bordéliques.

    Tous ces défauts viennent d'une seule chose. Pour simplifier, c'est parce qu'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 qu'on ne connaît pas, on a du matériel qui vient de l'extérieur, par un fabricant tiers. On ne sait pas non plus comment le réseau est configuré, quelle est son adresse de réseau local, quelle est la machine d'administration chez soi. Par exemple, qu'est-ce que ce machin qui communique sur le réseau, c'est juste un frigo qui est aussi en train de passer sa commande sur Amazon ou en train de télécharger des vidéos Youporn (un fabricant s'est fait infecté comme ça et 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, on apprend que quand on fait la cartographie réseau, on dit qui a le droit de communiquer avec qui, avec quoi, on connaît les adresses de ports, on sait dans quoi on va atterir. 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 il est obligé de faire des règles qui vont marcher partout, ce qui signifie des règles qui ne font rien du tout. On ne peut pas blacklister, par exemple, le port SSH de la box - ou du bidule connecté -, 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.

    On a toutes les problématiques comme les adresses IP dynamiques parce que le grand public est chez Orange, SFR, Bouygues, Numéricable, et donc a des IP qui bougent en permanence, des ports qui sont bloqués. Comment faire pour gérer ces cas-là ? On aura systématiquement un matériel qui va changer d'IP et c'est difficile en tant que constructeur tiers de prétendre le sécuriser pour que ça fonctionne dans le réseau.

    On a les problèmes de NAT car, si on a un matériel derrière notre box ADSL, il va falloir ouvrir un port sur le NAT pour faire rentrer le trafic pour pouvoir communiquer de l'extérieur vers le bidule connecté. Il y a des petites particularités, comme le hairpinning niveau NAT, qui fait que depuis l'extérieur, notre 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 objet connecté.

    J'ai un peu bossé là-dedans dans mon ancienne SSII, on arrive avec de bonnes préconisations réseaux et de 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, le marketing vend ça comme des briques plug and forget, « vous branchez, vous oubliez », vous n'avez rien à configurer, ça se débrouille tout seul comme un grand. C'est ce qu'ils appellent le dump-proof, c’est-à-dire que même un neuneu doit savoir s'en servir. Ils ne veulent pas avoir une documentation de mille pages, ils ne veulent pas les personnes aient besoin de compétences réseau pour configurer tout ça. Parce que si la première fois que vous branchez votre porte de garage, 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 l'adresse de réseau et votre masque de sous-réseau, vous allez perdre 99 % de la planète, pourtant vous en avez besoin si vous voulez sécuriser, comme 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 vendent plutôt aux alentours de 20 €, et n'ont pas envie de la vendre 2 000 €. Personne ne va acheter 10 ampoules à 2 000 €. Or, si on veut faire de la sécurité, ça coûte vite très très cher. Un très bon exemple que j'ai eu, c'était sur des espèces de tablettes numériques connectées. Un jour on leur a dit qu'il fallait mettre un mot de passe différent pour chacune des boîtes qu'ils allaient vendre et que cela signifiait 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 de l'adresse MAC qui est la même sur toutes les machines, mais si à chaque flash, à chaque image qu'on va flasher, il faut la refaire, la regénérer pour changer l'adresse MAC, pour changer le mot de passe par défaut ou autre, c'est la chaîne de production qui n'est pas du tout la même. Le mot de passe par défaut n'est pas le même, donc on ne peut plus imprimer des 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 imprimé. En termes de logistique, on passe d'une chaîne de production massive avec 5 000 box en une fois, à des trucs unitaires qui demandent des processus de logistique très compliqués, et on arrive vite à des systèmes qui coûtent 200, 300, 400, 500 € juste pour gérer les bonnes pratiques de changer un mot de passe, de ne pas avoir le même par défaut, et qui ne soit pas admin/admin.

    On va aussi se taper le support parce que les mots de passe compliqués les utilisateurs vont avoir du mal à les taper. Les i et l, les 1 et i, les 0 et les O… Vous êtes sûrs que vous allez avoir une ??? de support, parce que admin/admin c'est très bien quand on veut se connecter et, vous êtes sûrs que vous n'avez pas de support dedans. Donc le marketing vend des trucs comme ça qui sont juste pas compatibles avec du réseau, avec la sécurité, avec faire les choses proprement. La sécurité c'est compliqué. TLS je n'en parle pas, mais je fais des conférences et ça peut durer 4 h pour savoir comment on peut gérer correctement TLS ça veut dire qu'il faut se taper les anciens navigateurs Internet Explorer 6, XP, tous ces trucs-là. TLS c'est aussi très coûteux, c’est-à-dire que les fabricants vont faire des petites cartes TLS hardware qui vont coûter 20 €, sauf que ça n'a pas de mémoire. Donc la liste des autorités de certification qui font quelques Mo à stocker sur la carte, vous oubliez. On vous dit « on fait du TLS », par contre on ne vérifie rien, il n'y a aucun certificat de vérifié, donc tout passe comme il faut, man-in-the-middle avec, etc. Pareil pour la petite carte qui a 60 octets de mémoire, ça va coûter 20 €, la carte avec 10 Mo, de mémoire va coûter 200 €. Les firewalls, ça devient le bordel. Il y a 5 ans de ça, on disait « vous bloquez tout le trafic externe et ça devrait suffire pour 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 mille trucs dans le réseau qu'il faut aussi à prendre en compte. On a eu des cas de frigos connectés qui étaient infectés qui se mettaient à brutforcer les ports SSH d'une machine 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 dynamique, en DHCP, qui peut changer à la moindre panne de courant, eh bien faire un firewall qui tienne la route, c'est le merdier.

    Les mises à jour. Comment vous faites pour aller pousser les mises à jour sur 5000 lampes connectées, sachant que vous allez avoir même 1 % de taux de panne, donc un support qui explose à chaque mise à jour ? Des ampoules ne vont plus redémarrer et ça fait drôle de le dire, mais c'est ça. Il faut gérer deux systèmes d'exploitation 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 planter, il ne faut pas bricker notre ampoule connectée, il faut donc tout dupliquer, ce qui demande plus de mémoire, du développement en plus, etc., c'est compliqué. Enfin, les problèmes de logistique dont je parlais tout à l'heure avec 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 que Internet c'est compliqué, pour plein de raisons, DNS, noms de domaine, adresses IP, le NAT, etc. Le marketing vend ça comme étant très simple et accessible à tous, « vous achetez, vous pluggez, vous oubliez ». La sécurité, c'est un processus, on est censé le faire évoluer régulièrement, se tenir informé, faire les correctifs qui vont bien, et on a ces trois trucs-là qui vont collisionner en permanence entre « ça coûte cher, c'est compliqué, on veut du simple, du pas cher ». Donc ça donne l'Internet des objets tel qu'on le connaît.

    15:06

    Là on va attaquer le morceau qui nous intéresse : l'auto-hébergement. Pourquoi est-ce que j'ai parlé de tout ça pour finalement parler de l'auto-hébergement derrière ? Aujourd'hui, des solutions existent, YunoHost, Cozy Cloud, NextCloud, et on vous vend ça comme étant relativement accessible. N'importe qui peut les installer. Vous avez même des images Raspi qui existent, 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 un peu compliqué, mais vous êtes accompagné dans l'association 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. Quand vous lancez un système, vous n'avez pas envie qu'on vous demande votre adresse de réseau, votre adresse de sous-réseau, beaucoup ne savent pas répondre. Surtout, sur le long terme, car comme disait Bruce Schneier « Security is a process, not a product », 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 Nginx, qu'il faut reconfigurer votre bordel pour en tenir compte puis reflasher les images ? Il y a certainement des gens qui vont le faire mais d'autres ne le feront pas. 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 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 « solution-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, pas de problématique particulière, qu'on va faire les mises à jour régulières, par contre l'écosystème global, c’est-à-dire d'où va tourner ce machin-là, on s'en fout un peu. Ainsi, 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 que des gens ont lancé des images Mastodon qui étaient fournies par des gens et se sont retrouvés avec des bases de données publiées sur Internet parce que le firewall ne bloquait pas le port PostgreSQL. Ils ont utilisé du ??? et plein de systèmes comme ça qui faisaient tous ces trucs-là étaient publiés sur le net, donc il y a des serveurs complets qui étaient publiés, à poil ! Un exemple de serveur Mastodon (cf. diapo), ça fait tourner un serveur de nom de domaines local, bind 9, qui est exposé sur le net, portmap est exposé, NTP est exposé, Netbios est exposé, Samba est exposé et a dû se prendre une jolie vague de Wannacrypt, le serveur d'impression, le MDNS - qui est un protocole local de communication DNS - est sur le net, le MySQL à poil et, oui, Mastodon est sécurité, par contre, personne s'est posé la question de là 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 Mastodon est sécurisé, mais son écosystème ne l'est pas. Je pense que cette instance-là va se faire hacker très rapidement. Typiquement, Samba je pense que si les mises à jour ne sont pas faites, 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. Justement, ils ne vendent plus uniquement un logiciel, comme Mastodon, YunoHost ou NextCloud ou Cozy Cloud. Ils proposent directement leur boîtier pour 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. Par exemple, 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 dont la carte SD est morte qui se demandaient comment récupérer ses données. Et sans backup, pas de récupération. C'est 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 5 000 Briques Internet, y a pas 5 000 YunoHost ni Cozy Cloud ou autres dans la nature. Donc, on n'est pas encore très intéressant pour un attaquant. Cent machines à infecter, il s'en fout. Et toutes les solutions font quand même de l'accompagnement utilisateur. Quand on installe une Brique Internet, on ne nous dit pas de la brancher chez soi et de l'oublier. Il y a des sessions d'installation, d'accompagnement, des meetups, des choses comme ça, pour essayer de faire prendre conscience aux gens justement le genre de problèmes dans lesquels ils vont se lancer. Par contre, aujourd'hui, clairement 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 en « Internet of shit ». La sécurité, ça va être difficile de la mener jusqu'au bout et on risque d'aboutir aux fameux trucs type Mirail qui ont infecté l'Internet des objets et de convertir les trucs hébergés en système de malwares qui vont mettre en péril la sécurité du réseau dans son ensemble. Exemples de qu'on peut voir aujourd'hui : il y a Shodan qui scanne l'intégralité du réseau. Tous les jours IPv4 est passé à la moulinette sur l'intégralité des IP et des ports. C'est entièrement publié sur internet, il y a une base de données, et on peut faire des recherches dedans. Aujourd'hui, vous tapez « yunohost/admin », vous avez 1 113 instances YunoHost qui tournent et vous pouvez les lister. Si jamais il y a une faille de sécurité dans YunoHost, vous avez 24 h 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, il se trouve qu'il 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 ou autres sont publiées, donc là j'ai un botnet de 527 machines potentielles sous la main s'il y a une faille de sécurité qui est publiée et que les administrateurs ne font pas le boulot. Pareil sur NextCloud où on voit tous les NextCloud qui tournent. Idem, 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 un déploiement auprès de beaucoup de monde et assumer derrière la sécurité ambiante qui change toutes les deux semaines, qui demandent des compétences d'administrateur système pour gérer un firewall pour être capable de tout bloquer. Par exemple, pour éviter Shodan, je vais vous expliquer 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 parce qu'il ne connaît pas le nom de domaine, donc il va avoir la page « Hello world, it's work » en fonction de votre système. Ça veut dire que l'utilisateur doit renseigner un nom de domaine, une adresse ip, il va falloir qu'on lui pose des questions, et c'est plus une Brique, 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 ç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 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 si je sais que telle IP répond à tel nom de domaine, 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 pareil, l'utilisateur doit savoir comment importer une autorité de certification dans son navigateur, etc. C'est compliqué à patcher, donc ce n'est pas une critique, je n'en veux pas à YunoHost, la Brique ou autre, c'est très compliqué d'y arriver, et on ne peut pas demander aux gens de monter leur propre autorité de certification pour ensuite demander à ses utilisateurs ou des administrateurs, de l'installer, c'est humainement pas possible. Du coup, l'auto-hébergement n'est pas forcément une bonne idée. Ici, il n'y a pas beaucoup de risques parce que les gens sont plutôt globalement formés, sensibilisés à ça et vont faire les 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, ça va être les CHATONS – Collectifs 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, donc ce n'est plus 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, il n'y a pas d'enfermement technologique, tout est documenté, tout est neutre, etc. Par contre, derrière, il y a de vrais admins système qui font vraiment leur boulot, qui sont capables de sécuriser leurs machines, de faire les mises à jour quand ça va mal, et donc ils vont s'occuper de toute la partie administration que vous n'êtes pas capable de faire ou que vous n'avez pas forcément envie de faire. C'est plutôt une bonne solution. 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, être un expert dans tous les domaines DNS, IP, routage, firewall, sécurité, etc., et manques de disponibilité car même si on a les compétences, 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. Alors on a des machines avec Nginx qui ne sont pas à jour, avec des TLS qui ne sont pas à jour, juste parce qu'on n'a pas le temps, c'est pas notre boulot, on a autre chose à faire. OpenSSL c'est trois mises à jour par jour, quelque chose comme ça. Pour 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. On essaie 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 CHATONS vont aider à ça, il y a des administrateurs système dédiés à ça, de manière bénévole ou salarié, ça dépend du modèle, mais il y a un engagement. Ils ont 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, avec les CHATONS, et que font déjà aujourd'hui la Brique Internet et autres, il y a de l'accompagnement, vous n'êtes pas lâchés 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 faire ce que vous attendez de lui. Et 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, ben tiens, moi j'ai du temps, je suis administrateur système ou juste quelqu'un d'intéressé par tout ça. Alors viens, on va te filer les clés du datacenter, viens nous aider, viens mettre tes compétences à dispo, et vous pouvez monter en compétences, et venir aider justement à monter d'autres systèmes, pour pas que ça grossisse trop et que ça ne devienne des GAFAM, et montez votre CHATON, forkez et faites des petits. C'est très pédagogique, c'est bon pour le réseau, parce qu'aujourd'hui, c'est 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, 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, c'est des DdoS à 1 Tb/s parce qu'il y a des Chinois qui ont allumé des caméras connectées dans des coins, ça fait peur. Si on fait de l'auto-hébergment pas bien cadrée, on risque d'amplifier le problème. On voit déjà plus de 1 000 YunoHost exposés sur Internet et je n'ai pas regardé qui était à jour là-dedans, mais si plus de 10 % est à jour, on sera content. Déjà pour être exposé comme ça sur internet, c'est que l'administrateur système n'a pas dû trop s'en occuper.

    Ce sera ma conclusion et après on passera aux questions. L'auto-hébergement a de très bons points, 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, j'ai pas de données. Heureusement, j'avais des backups, mais j'ai tout perdu potentiellement. Ou le système en face qui ferme, il y a plein de raisons qui font qu'on peut 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 de 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.

    31.00

    J'ai fait le tour, si vous avez des questions.

    Benjamin, t'en as bien une ?

    Question (sans micro, reprise par Aeris) : Quand on a un certificat let's encrypt et qu'on héberge un service, comment on fait pour se mettre à l'abri de Shodan ?

    Réponse : 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, 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, il faut déjà essayer de le mettre sur un domaine qui ne soit pas celui de ton service véritable parce qu'une fois que tu le connais on va tomber dessus. Donc il faut avoir ta propre autorité de certification, tu génères des certificats à toi. Ça peut être un autosigné si tu ne veux pas aller jusqu'à la CA complète. Tu mets un certificat autosigné qui n'apparaîtra nulle part, et donc tu protèges ton service d'administration par un certificat autosigné.

    * Intervention du questionneur non enregistrée *

    C'est là que c'est compliqué, il faut mettre les mains dans le code. Il faut sortir l'interface admin et la mettre sur autre chose. Ça veut dire qu'il faut reconfigurer le YunoHost correctement, il faut effectivement savoir ce qu'on fait. Il y a aussi des solutions à l'arrache comme blacklister carrément le /admin de YunoHost sur l'interface publique, et de le republier sur l'interface privée avec un certificat à toi. On pense que Wannacrypt s'est servi des failles révélées par Shodan. Tu chopes tout ce qui tourne et tu n'as plus qu'à tester. Tel service fait tourner telle version, donc on a telle faille, on lance le scan, et en 2 h des milliers de machines peuvent être infectées comme ça. À chaque fois, sur des problèmes comme ça il faut réfléchir. Il n'y a pas 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.

    Question : Pourquoi les certificates transparency ont été publiés ?

    Réponse : C'est pour éviter les générations frauduleuses de certificats. Le problème aujourd'hui, c'est que dans les autorités de certification, n'importe qui peut émettre n'importe quoi. Il y avait donc des autorités de certification qui s'amusaient, comme l'ANSSI 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 et qui ne correspond pas à une demande que eux ont faite. Ils auraient pu alerter directement l'autorité de certification en disant « je ne comprends pas, ce n'est pas qui ai demandé ça, 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 que je n'ai pas demandés, je peux demander à les blacklister.

    Aujourd'hui, let's encrypt est dedans et la plupart des autorités de certification sont dedans. De mémoire, ce n'est pas obligatoire complètement encore partout mais ça le deviendra de toutes façons.

    Question : *Non enregistrée *

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

    * Intervention non enregistrée *

    Réponse : C'est pas illégal, c'est pas interdit, beaucoup le font aujourd'hui. Les gros systèmes de distribution de données, la plupart des CDN [Content Delivery Network] par exemple, ont des autorités de certificat différentes pour chaque N [NDT : network] 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, parce que ça amène 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 tel certificat n'a pas été demandé par lui et qu'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 du paypal. Ils utilisaient des caractères cyrilliques et ça faisait passer pour paypal, on avait l'impression d'aller sur paypal.com, en fait on était sur un site russe. Encore un coup des Russes ! 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 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 le reste du réseau. 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. En fait, 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à faisant partie du réseau d'infection, elle a été saisie. Ce serait pareil si c'était une caméra connectée ou même un YunoHost. YunoHost qui se fait infecter va venir brutforcer ma machine demain.

    * Intervention non enregistrée *

    Réponse : Oui, il y a les téléphones pas mis à jour et le téléphone va être allumé, avec 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. On peut installer une application dégueulasse sur un téléphone pour que pendant que tu joues à Candy Crush, je fasse une map de ton réseau. Il y aurait des trucs funs à faire, comme monter des réseaux Wifi, des Google car, ou se connecter sur toutes les lampes connectées et les faire clignoter, ou faire un pong avec les lampes des bureaux, il y a des trucs vachement funs. Bizarremment, ça bouge pas, on voit quelques grosses attaques. On a eu Dyn, 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 « hey, stop internet ! ». Est-ce qu'il y a d'autres questions ?

    Question : *Non enregistrée *

    Réponse : Oui, c'est possible, Schneir avait écrit un bon article de blog là-dessus. Il disait, on ne comprend pas, on voit des choses là-dessus de plus en plus ciblées, on voit pourtant du bordel infâme dans le réseau qui les aide. Avant, il fallait trouver les botnets, quand on voulait faire une attaque par amplification de DNS pour faire tomber une machine, il fallait trouver des machines qui étaient faillibles, dans lesquelles on pouvait s'introduire, et il 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ères le NAT, derrière la box ADSL, donc on était 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, on en a des paquets. Avoir un botnet de 10 000 ou 100 000 machines, 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 le réseau à côté. Le genre de conneries que vous pouvez avoir avec Shodan par exemple, c'est avec 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 on a des interfaces d'administration complètes, on peut imprimer, changer le fond d'écran, et d'ailleurs sur le fond d'écran, on sent bien parfois que quelqu'un est passé avant ! Ou des trucs de gestion de vidéos projection, vous pourrez les avoir en public sur internet. Je suivais des MOOCs à distance en participant à des amphithéâtres de médecine de l'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, mais c'est marrant, on peut faire monter et descendre le vidéo projecteur à distance. C'est le genre de trucs, avec un YunoHost pas à jour, ou par les imprimantes réseau que je vais scanner, j'accède à votre réseau. Si vous avez Windows, vous avez du Samba ou du Netbios, ou quelque chose comme ça, donc je peux scanner le réseau et récupérer ce que vous imprimez. Il y a avait eu une attaque comme ça avec des petites imprimantes connectées thermiques pour imprimer des étiquettes. Ils avaient imprimé plein de trucs, en disant « coucou, je suis ton imprimante, je suis maintenant doué d'une vie autonome » en imprimant des petits robots et des chatons.

    Ça va être la fin, merci à vous.