Planète Warez

@Aerya a dit dans [Docker Apps] DockHand : un sérieux concurrent à Portainer pour vos environnements Docker :

J’ai fait un test/article dessus aussi, c’est devenu mon outil favoris 🙂

C’est vrai qu’il à l’air top.
Je vais le “dockerisé” sur mon Syno celui-là 😉

Gainax, le studio d’animation à l’origine de Neon Genesis Evangelion, FLCL, Gurren Lagann et bien d’autres œuvres, a définitivement fermé ses portes après près de 42 ans d’existence.

Le créateur d’Evangelion, fondateur du Studio Khara et cofondateur de Gainax, Hideaki Anno, a annoncé le 10 décembre 2025 sur le site de Studio Khara que la procédure de faillite visant Gainax s’était conclue par la restitution des droits restants de diverses œuvres à leurs créateurs et ayants droit légitimes, entraînant ainsi la dissolution officielle du studio en tant qu’entreprise. Gainax avait initialement annoncé l’ouverture de la procédure de faillite en juin 2024.

Le studio est né d’un collectif d’étudiants de l’Université des arts d’Osaka qui réalisaient des courts métrages d’animation pour la Convention nationale japonaise de science-fiction, connue sous le nom de DAICON. Après avoir marqué les esprits avec le court métrage Daicon IV en 1983, le groupe s’est constitué en société sous le nom de Gainax en 1984 afin de produire Royal Space Force: The Wings of Honneamise (Les Ailes d’Honnéamise), réalisé et scénarisé par Hiroyuki Yamaga, sorti en 1987.

– Une enveloppe de Hayao Miyazaki félicitant la fondation de Gainax, appuyée par une feuille de papier d’animation.

À partir de là, Gainax a produit des œuvres telles que Gunbuster, les débuts de Hideaki Anno à la réalisation en 1988, puis Nadia : Le Secret de l’Eau Bleue, le premier anime télévisé de longue durée du studio, également réalisé par Anno, en 1990. Le studio a connu son premier grand succès commercial avec le cultissime Neon Genesis Evangelion au milieu des années 1990, mais aussi l’apparition de ses premières fissures.

Anno a expliqué dans un article de Diamond Online publié en 2019 qu’il avait appris, lors d’un appel téléphonique en 1999 avec TV Tokyo, diffuseur d’Evangelion, que le studio Gainax se livrait à une évasion fiscale, et qu’il avait dû s’excuser au cours de ce même appel. Le réalisateur a déclaré qu’il ne se sentait pas respecté au sein du studio et, bien qu’il ait conservé des liens en tant qu’actionnaire, il a transféré Evangelion chez Khara pour la saga des films Rebuild Of Evangelion au milieu des années 2000, avant de quitter officiellement Gainax en tant qu’employé régulier en 2007.

En 2014, des représentants de Gainax, dont le cofondateur Yasuhiro Takeda, ont emprunté 100 millions de yens à Anno afin de maintenir le studio à flot, comme détaillé dans l’article de Diamond Online. En décembre 2016, Khara a poursuivi Gainax pour récupérer ce prêt, Hiroyuki Yamaga présentant publiquement ses excuses quelques jours après le dépôt de la plainte.
En juin 2017, un juge a statué en faveur de Khara et a ordonné le remboursement intégral de la somme.

Dans une déclaration récente publiée sur le site de Khara, Anno a indiqué que, lors des enquêtes menées après l’installation d’un nouveau conseil d’administration chez Gainax en février 2020, le studio a « constaté de visu le manque de bonne foi de Gainax concernant le remboursement ». Il ajoute que l’ancienne équipe dirigeante « faisait preuve d’un manque de respect envers ses propres œuvres, son personnel, ainsi que la préservation des opérations de l’entreprise et des matériaux de production ».
Anno affirme notamment que Yamaga aurait demandé aux employés de Gainax de « faire comme s’il était hospitalisé », tout en tenant des « propos hostiles » et en cherchant des moyens d’éviter les paiements. Anno précise que l’ancienne direction de Gainax, qui incluait Takeda et Yamaga, était composée d’amis de ses années universitaires, et qu’il « ne pourrait jamais revenir au type de relation qu’il avait autrefois avec eux ».

Dans le même article de Diamond Online, Anno a également déclaré que Gainax avait vendu les droits de Gunbuster et FLCL en 2014 sans l’en informer, alors même qu’il avait proposé d’acheter ces droits afin d’aider financièrement le studio.

Gainax a subi une restructuration en 2020 après que son président de l’époque, Tomohiro Maki, a été arrêté en décembre 2019 pour agression indécente. Il a ensuite été officiellement condamné en décembre 2020 à deux ans et six mois de prison. Yasuhiro Kamimura, responsable des droits de la franchise Evangelion via Groundworks, est alors devenu directeur représentatif de Gainax et a rédigé la déclaration de faillite du studio en juin 2024.

Dans sa dernière déclaration, Anno a expliqué que l’équipe — composée de Yuko Takaishi (Kadokawa), Atsushi Moriyama ([censored] Records), Yoshiki Usa (Studio Trigger) et de Kamimura en tant que directeur représentatif — a travaillé avec les créateurs originaux et les ayants droit afin de leur restituer ce qui leur appartenait. Cela incluait notamment des matériaux de production originaux, dont certains ont été exposés lors de l’exposition Gurren Lagann x Kill la Kill au Japon plus tôt l’année dernière.

Le dernier article, qui, selon Anno, contient « presque tous les détails pouvant être rendus publics », se conclut par des remerciements adressés à Kamimura — lui aussi un ami de ses années universitaires — pour tout son « travail acharné ». Anno explique que Kamimura a travaillé sans relâche depuis 2019 pour « préserver l’héritage » des matériaux et des droits, et qu’il « a sincèrement fait face aux créanciers » afin de s’assurer que tout soit géré correctement, « au milieu de l’abandon du studio d’animation historique Gainax par son ancienne direction ».

– Sources:

https://www.khara.co.jp/2025/12/11/251211/?lang=en

https://www.crunchyroll.com/news/latest/2025/12/27/gainax-anime-studio-officially-closes

–> Triste fin 😞

Merci à Gainax et ce cher Hideaki Anno pour m’avoir fait découvrir cette grosse claque de l’animation japonaise qu’est Neon Genesis Evangelion. Œuvre culte pour moi, que tout bon Otaku qui se respecte se doit de voir et connaitre, ainsi que tant d’autres séries cultes…

Imaginez un monde sans Google, sans Facebook, où pour se connecter, il faut débrancher le téléphone et écouter la symphonie stridente d’un modem 56k. Nous sommes en 1992… Quelque part à Helsinki, dans une cave mal ventilée, un ingénieur finlandais s’apprête à lancer un petit script Perl qui va faire trembler la planète entière. Johan Helsingius, ou “Julf” pour les intimes, vient de créer le premier grand service d’anonymat du Web : anon.penet.fi.

J’ai toujours eu une fascination pour ces pionniers qui ont bâti le Web avec trois bouts de ficelle et Julf est l’archétype du héros cypherpunk. Ce type, qui a étudié la musique avant de devenir un pilier du réseau, a notamment fondé EUnet Finlande, le premier FAI commercial du pays. Et tenez-vous bien, c’est lui qui a aussi aidé à tirer les premiers câbles pour connecter l’Union Soviétique à Internet. Rien que ça !

En 1992, alors qu’il traîne sur les newsgroups Usenet (l’ancêtre de Reddit ^^), une discussion éclate : doit-on obligatoirement signer ses messages de son vrai nom ? Pour Julf, c’est un “non” ferme et définitive, alors plutôt que de débattre pendant des heures, il fait ce que tout bon hacker fait et il code une solution. Il lance son serveur en octobre 1992 et c’est ce qu’on appelle un “remailer de type 0”.

Concrètement, vous envoyez un mail à “[email protected]”, le serveur efface votre nom et votre IP, vous attribue un pseudo genre “an1234” et transfère le message. Et voilà, le tour est joué !

Et la vraie révolution, c’est surtout que ça marchait dans les deux sens… Ainsi, si on répondait à “an1234”, le serveur renvoyait le courrier dans votre vraie boîte. C’était la première fois qu’on pouvait avoir une conversation suivie tout en restant un fantôme.

– Le genre de bécane qui faisait tourner le monde en 93

Le succès de son service a été immédiat et assez violent. En quelques mois, le petit serveur gérait plus de 10 000 messages par jour. Et au moment de sa fermeture, on comptait pas moins de 700 000 comptes enregistrés. C’est énorme pour l’époque ! On y trouvait des gens qui voulaient juste discuter tranquillement, mais aussi des victimes de violences conjugales, des groupes de soutien et des lanceurs d’alerte.

Perso, je trouve ça dingue quand on y repense. Et c’est là que les emmerdes arrivent car parmi les utilisateurs les plus actifs, on trouvait les critiques de l’Église de Scientologie. En 1995, la secte contre-attaque avec l’affaire “Miss Blood”. Ils affirment qu’un utilisateur (identifié sous le pseudo “-AB-”) a volé des fichiers secrets. Ils mettent alors Interpol et la police finlandaise dans la boucle et les flics débarquent chez Julf le geek juste parce qu’une secte américaine a fait son petit caprice.

Car oui, le système de Julf avait une faille mortelle : c’était un système centralisé. Pour que ça marche, le serveur devait garder une table de correspondance entre les vrais mails et les pseudos donc s’il donnait la base, il grillait 700 000 personnes. Julf a tenu bon et a négocié comme un chef, acceptant de ne révéler qu’une seule identité pour sauver toutes les autres. Mais la leçon était apprise : l’anonymat centralisé ne peut pas résister à la pression légale.

Comme si ça ne suffisait pas, la presse s’en est mêlée avec un article délirant de The Observer accusant le service d’héberger 90% de la pédopornographie mondiale. C’était techniquement impossible car le serveur avait une limite de 16 Ko par message, pile de quoi bloquer les images binaires de l’époque mais le mal était fait.

Alors le 30 août 1996, Julf annonce la fermeture. Le service s’arrête définitivement en septembre, laissant un vide immense mais pavant la voie aux outils modernes comme Tor. D’ailleurs, si vous voulez creuser le sujet, j’avais publié un guide pour créer votre relais Tor ou encore comment utiliser Tor avec Thunderbird .

Et aujourd’hui, Julf continue de bosser dans la tech, mais son héritage le plus fort reste ces trois années folles. Alors la prochaine fois que vous utilisez un VPN ou Signal, ayez une petite pensée pour l’homme qui, seul avec son 486 dans une cave finlandaise, a offert un masque à des centaines de milliers de visages juste par principe.

Références :

https://en.wikipedia.org/wiki/Project_Chanology?utm_source=chatgpt.com
https://pet3rpan.medium.com/before-bitcoin-pt-3-90s-cryptowars-e857915fab82?utm_source=chatgpt.com
https://en.wikipedia.org/wiki/Johan_Helsingius

– Sources : Wikipedia

https://korben.info/johan-helsingius-anonymiseur-internet.html

En bref :
(Résumé généré automatiquement par IA)

– Votre VPN vous trahit et vous ne le savez pas encore
– Ce que les trackers torrent voient vraiment de vous
– Un test gratuit qui va vous faire flipper (ou vous rassurer)

J’espère que vous passez une bonne semaine et que votre connexion internet ne vous fait pas trop la misère en ce moment…

Car aujourd’hui, on va parler d’un truc qui devrait intéresser tous ceux qui utilisent un VPN (ou qui pensent en utiliser un, un jour) pour leurs activités un peu… gourmandes en bande passante. Vous le savez, je le sais, BitTorrent c’est génial, mais c’est aussi un moyen facile de se retrouver avec son adresse IP exposée aux trackers et aux pairs du swarm. Et même avec un tunnel sécurisé, on peut toujours être victime d’une fuite en cas de mauvaise configuration ou de rupture du VPN.

Et là, y’a toujours Hadopi (enfin, ce qu’il en reste) qui pour justifier leur budget annuel vous enverra un petit message de menace automatique. Pas de communication non violente ici ^^.

C’est précisément là qu’intervient **Torrent Peek **, un petit outil qui est gratuit et sans inscription et qui va vous permettre de vérifier si votre protection est efficace ou si elle laisse filtrer votre IP. Pour cela, le site génère un lien magnet unique que vous ouvrez dans la plupart des clients torrent (uTorrent, Transmission, Deluge, etc.).

Une fois le lien ajouté, votre client va tenter de se connecter aux trackers du site, et hop ! Torrent Peek affichera alors l’adresse IP qu’il voit passer. Si c’est celle de votre VPN, c’est un bon signe. Si c’est votre vraie IP… eh bien vous êtes dans la mierda ^^.

Car même avec un VPN actif, une défaillance du “kill switch” ou un trafic qui sort du tunnel peut exposer votre identité réelle. Notez d’ailleurs que l’exposition peut aussi se faire via DHT ou PEX, ce que ce test ne couvre pas forcément, mais c’est déjà une excellente première vérification côté trackers.

Le truc cool avec cet outil, c’est qu’il propose aussi une API JSON pour ceux qui aiment bien automatiser leurs tests ou surveiller leur connexion via un petit script maison. Il suffit de faire un petit curl sur l’URL fournie pour obtenir le statut de votre connexion à l’instant T.

D’ailleurs, si vous voulez aller plus loin dans la bidouille torrentielle, je vous recommande de jeter un œil à cet article pour ouvrir des liens magnet directement avec VLC (moyennant un petit plugin), car c’est super pratique.

Voilà, ça vous permettra de vérifier que vous ne faites pas n’importe quoi quand vous téléchargez des ISO Linux toute la nuit 😅…

– Source :
https://korben.info/torrentpeek-vpn-test-leak-ip-checker.html

Moi aussi, j’ai justement récupéré des Tiny PC, ça ca être parfait pour tester.

J’ai encore mon vieux sanyo plv Z3 qui traine au bureau, je l’avais chez mes parents et m’a bien depanné pour jouer à la Xbox lorsque ma tv loewe était tombée en panne :smile:
Malgres son peu de nombre d’heures d’utilisation, ça vaut plus rien maintenant.
Et qui plus est, je ne saurai plus où projeter…

En bref:
(Résumé généré automatiquement par IA)

– VoidLink est un nouveau framework de malware Linux découvert par Check Point Research, conçu spécifiquement pour infiltrer de façon furtive les environnements cloud et conteneurs (AWS, Azure, Google Cloud, Kubernetes…).

– Il dispose d’une architecture modulaire avec plus de 30 plugins, permettant aux attaquants d’adapter ses capacités (furtivité, mouvement latéral, collecte d’identifiants) selon l’environnement ciblé.

– Sa communication chiffrée et son intégration profonde dans le système le rendent très difficile à détecter, ce qui pose une nouvelle menace aux infrastructures cloud basées sur Linux.

Check Point Research révèle l’existence de VoidLink, un cadre malveillant Linux de nouvelle génération, conçu pour infiltrer des environnements cloud et des infrastructures conteneurisées. Développé en Zig et doté de capacités noyau, de greffons et de communications chiffrées, il vise l’accès furtif et durable aux charges de travail critiques hébergées sur AWS, Azure, Google Cloud, Alibaba Cloud et Tencent Cloud.

Les plates-formes Linux et les architectures Kubernetes concentrent désormais les données applicatives, les secrets d’authentification et les accès aux chaînes d’approvisionnement logicielles. Cette concentration technique transforme chaque nœud de calcul et chaque poste d’ingénierie en point d’entrée convoité pour des acteurs capables d’opérer dans la durée sans perturber les environnements de production.

VoidLink repose sur une architecture complète de commande et de contrôle composée d’un chargeur en deux étapes, d’un implant principal et d’un serveur central piloté par une console Web. L’implant, écrit en Zig, intègre un cœur de communication et d’orchestration auquel viennent se greffer des modules chargés en mémoire à la demande. L’opérateur peut générer de nouvelles charges utiles depuis l’interface graphique, ajuster les paramètres de communication et déployer des greffons ciblés sur chaque machine compromise. L’ensemble constitue une plate-forme opérationnelle unifiée, comparable aux cadres de post-exploitation du monde Windows, mais entièrement adaptée à Linux et aux environnements cloud.

Il détecte les grands fournisseurs de cloud et Kubernetes

La console regroupe les fonctions de gestion des implants, de terminal distant, de génération de charges et d’administration des modules. Elle organise les opérations en domaines comme la reconnaissance, la persistance, la collecte d’identifiants, le déplacement latéral et l’effacement de traces, ce qui permet une conduite industrialisée des opérations malveillantes sur des parcs de serveurs et de conteneurs.

Dès son déploiement, VoidLink interroge l’environnement hôte pour identifier le fournisseur de cloud sous-jacent, avec une prise en charge native de AWS, Google Cloud, Azure, Alibaba Cloud et Tencent Cloud. Il exploite ensuite les interfaces de métadonnées propres à chaque plate-forme pour collecter des informations sur l’instance compromise, ses rôles et ses autorisations. Le même mécanisme permet de déterminer si le code s’exécute dans un conteneur Docker ou dans un pod Kubernetes, afin d’adapter les stratégies d’escalade et de propagation.

Des modules spécialisés automatisent la recherche de failles de configuration, l’extraction de secrets et les tentatives de sortie de conteneur vers l’hôte sous-jacent. Cette logique transforme une simple compromission applicative en accès potentiel à l’ensemble d’un cluster ou d’un compte cloud.

Une furtivité pilotée par la détection des outils de sécurité

VoidLink intègre un moteur d’évaluation du risque qui inventorie les solutions de détection Linux, les mécanismes de durcissement du noyau et les outils de supervision présents sur la machine. À partir de ces éléments, l’implant calcule un profil d’exposition et ajuste le comportement de ses modules, par exemple en ralentissant un balayage de ports ou en fragmentant une exfiltration lorsque la surveillance est élevée. Cette adaptation automatique constitue un élément central de sa stratégie de discrétion.

Le dispositif est complété par des techniques de chiffrement du code à l’exécution, par des vérifications d’intégrité et par une autodestruction en cas de tentative d’analyse ou de modification. Ces mécanismes visent à réduire la visibilité du code en mémoire et à compliquer toute investigation.

Des modules noyau et eBPF pour masquer l’activité du maliciel

Pour se dissimuler, VoidLink s’appuie sur une famille de composants de type rootkit adaptés aux différentes versions du noyau Linux. Selon la configuration de l’hôte, il peut utiliser des détournements du chargeur dynamique via LD_PRELOAD, des modules noyau LKM ou des programmes eBPF pour intercepter et filtrer les appels sensibles. Ces techniques permettent de cacher les processus, les fichiers et les sockets réseau liés à l’implant, tout en masquant les composants de dissimulation eux-mêmes.

L’implant ajuste également ses intervalles de communication en fonction de l’activité du système, en tenant compte de la charge, du trafic réseau et des périodes de faible usage, afin de se fondre dans le bruit normal de la plate-forme.

La collecte de secrets vise les ingénieurs cloud

Les greffons fournis par défaut couvrent la collecte de clés SSH, d’identifiants Git, de jetons d’interface de programmation applicative, de mots de passe stockés en mémoire et de secrets présents dans les variables d’environnement ou les trousseaux système. Des modules dédiés aux navigateurs extraient également des cookies et des informations d’authentification. Cette orientation montre un intérêt marqué pour les postes de développeurs et d’administrateurs qui pilotent les déploiements cloud.

En parallèle, des fonctions de tunnel, de transfert de fichiers, de ver SSH et de persistance via cron, systemd ou le chargeur dynamique facilitent la propagation contrôlée et l’ancrage à long terme dans les environnements compromis.

L’émergence d’un cadre aussi complet que VoidLink confirme que les infrastructures Linux, les grappes Kubernetes et les comptes cloud sont désormais des cibles de choix pour des opérations d’espionnage et de compromission de chaînes d’approvisionnement. La combinaison entre reconnaissance automatisée, furtivité adaptative et modules noyau réduit fortement les fenêtres de détection et augmente les coûts de réponse à incident pour les organisations.

– Source :

https://itsocial.fr/cybersecurite/cybersecurite-actualites/voidlink-un-nouveau-maliciel-linux-cible-les-environnements-cloud-et-conteneurs/

En bref :
(Résumé généré automatiquement par IA)

– Jonathan James, alias c0mrade, est devenu à 15 ans le premier mineur condamné pour cybercriminalité aux États-Unis après avoir piraté des serveurs de la NASA et du Département de la Défense, interceptant des milliers d’e-mails et téléchargeant du code source critique.

– Il a été assigné à résidence puis emprisonné pour avoir violé sa probation, marquant un tournant dans la manière dont la justice traite les mineurs dans le cyberespace.

– Après avoir tenté de mener une vie normale, il s’est suicidé à 24 ans, convaincu d’être faussement accusé dans une enquête informatique ultérieure, laissant un héritage tragique et controversé dans l’histoire du hacking

Un gamin de 15 ans qui pète les serveurs de la NASA pendant que moi, à son âge, j’en était encore à configurer mon modem 56k pour qu’il arrête de faire du bruit en pleine nuit… Jonathan James, alias c0mrade, est devenu le premier mineur emprisonné pour cybercriminalité aux États-Unis… avant, malheureusement, de se suicider à 24 ans parce qu’il pensait qu’on allait l’accuser d’un crime qu’il n’avait pas commis.

Voici l’histoire la plus dingue et la plus tragique du hacking que vous n’avez jamais entendue.

Jonathan Joseph James naît le 12 décembre 1983 à Pinecrest, un quartier cossu de Miami-Dade County. Son père, Robert James, bosse comme programmeur pour le comté… déjà, on sent que l’informatique, c’est de famille. Sa mère, Joanne Jurysta, tient la maison pendant que les deux frangins, Jonathan et Josh, grandissent dans un environnement de classe moyenne supérieure.

Dès 6 ans, Jonathan passe ses journées sur l’ordinateur paternel. Au début, c’est pour jouer, évidemment. Mais très vite, le gamin comprend qu’il peut faire bien plus que lancer des jeux. Il commence à triturer, à fouiller, à comprendre comment ça marche sous le capot. Ses parents, inquiets de voir leur fils scotché à l’écran, décident alors de lui confisquer l’ordinateur quand il atteint ses 13 ans.

Grosse erreur.

Car Jonathan fait une fugue. Il refuse catégoriquement de rentrer à la maison tant qu’on ne lui rend pas son accès à l’informatique. J’imagine la scène avec ces parents complètement dépassés face à un ado qui préfère dormir dehors plutôt que de vivre sans son ordinateur. Bon, ils finissent par craquer, évidemment.

C’est à cette époque que Jonathan se forge son identité de hacker. Il choisit l’alias c0mrade avec un zéro à la place du ‘o’, parce que dans les années 90, remplacer des lettres par des chiffres, c’était le summum du cool.

Et surtout, il passe ses nuits sur les BBS et les premiers forums de hacking, à échanger avec une communauté underground qui n’a absolument rien à voir avec les script kiddies d’aujourd’hui. C’est une époque où pirater demandait de vraies compétences techniques, pas juste télécharger un exploit sur GitHub.

L’été 1999. Jonathan a 15 ans, les cheveux longs, et une curiosité maladive pour tout ce qui ressemble à un serveur mal configuré. Entre le 23 août et le 27 octobre 1999, il va commettre une série d’intrusions qui vont faire de lui une légende du hacking… et accessoirement, le faire finir en prison.

Pour son méfait, le gamin scanne les réseaux à la recherche de serveurs Red Hat Linux mal patchés et comme en 1999, la sécurité informatique, c’est encore le Far West, les administrateurs système pensent que mettre leur serveur derrière un firewall basique, c’est suffisant.

Sauf que ça ne l’était pas.

Jonathan exploite des vulnérabilités connues pour installer des backdoors c’est à dire des portes dérobées qui lui permettent de revenir à volonté sur les systèmes compromis. Mais le plus fort, c’est qu’il installe aussi des sniffers réseau, des programmes qui interceptent tout le trafic qui passe par le serveur. Mots de passe, emails, données sensibles… tout y passe.

Sa première cible d’envergure ? BellSouth, le géant des télécoms. Puis le système informatique des écoles de Miami-Dade County. Mais c’est quand il s’attaque aux agences gouvernementales que les choses deviennent vraiment intéressantes.

En septembre 1999, c0mrade détecte une backdoor sur un serveur situé à Dulles, en Virginie. Au lieu de passer son chemin, il décide d’aller voir de plus près. Il se connecte, installe son sniffer maison, et se rend compte qu’il vient de compromettre un serveur de la DTRA, c’est à dire la Defense Threat Reduction Agency, une division ultra-sensible du Département de la Défense qui s’occupe d’analyser les menaces NBC (nucléaires, biologiques, chimiques) contre les États-Unis.

Pendant plusieurs semaines, Jonathan intercept plus de 3300 emails entre employés de la DTRA. Il récupère aussi des centaines d’identifiants et mots de passe, ce qui lui permet d’accéder à une dizaine d’ordinateurs militaires supplémentaires. Tout ça sans que personne ne s’en aperçoive.

Mais le clou du spectacle, c’est son intrusion chez NASA.

En juin 1999, Jonathan tombe sur un serveur mal configuré à Huntsville, Alabama. Il l’infecte avec son malware habituel et découvre qu’il vient de compromettre le Marshall Space Flight Center de la NASA. Et c’est pas n’importe lequel puisque c’est celui qui développe les moteurs de fusée et les logiciels pour la Station Spatiale Internationale.

En installant sa backdoor, c0mrade réalise qu’il peut accéder à 12 autres ordinateurs du réseau. Et là, jackpot ! Il met la main sur le code source d’un programme qui contrôle des éléments critiques de l’ISS. On parle du système de contrôle de la température et de l’humidité dans les modules habitables de la station spatiale.

Rien que ça…

Jonathan télécharge l’intégralité du logiciel. Valeur estimée par la NASA : 1,7 million de dollars. Mais attention, ce n’est pas un vol dans le sens classique du terme puisque le gamin ne revend rien, ne détruit rien, ne modifie rien. Il copie, point. Sa philosophie de grey hat hacker de l’époque c’est d’explorer sans nuire.

Sauf que quand la NASA découvre l’intrusion, et ça devient vite la panique à bord. L’agence spatiale est obligée de couper ses serveurs pendant 21 jours pour vérifier l’intégrité de ses systèmes et colmater les failles. Coût de l’opération : 41 000 dollars de plus. Pour l’époque, c’est énorme.

Encore une fois, on réalise à quel point la sécurité de nos infrastructures critiques tenait du miracle en 1999.

Nous sommes le 26 janvier 2000. Jonathan vient d’avoir 16 ans depuis quelques semaines. Il est tranquillement dans sa chambre quand des agents fédéraux débarquent chez lui avec un mandat de perquisition. FBI, NASA, Département de la Défense… tout le gratin de la sécurité nationale américaine vient cueillir le gamin de Miami. Comme l’a rapporté ABC News à l’époque , l’arrestation fait sensation dans les médias.

Jonathan ne fait même pas semblant de nier. Plus tard, il expliquera aux enquêteurs qu’il aurait pu facilement couvrir ses traces s’il avait voulu. Mais il ne pensait pas faire quelque chose de mal. Dans sa tête d’ado, il “jouait” juste avec des ordinateurs. Il n’avait volé aucune donnée pour s’enrichir, n’avait planté aucun système, n’avait rien détruit.

Le problème c’est que la justice américaine ne voit pas les choses du même œil.

Le 21 septembre 2000, Jonathan James devient alors officiellement le premier mineur condamné à une peine de prison pour cybercriminalité aux États-Unis. À 16 ans, il entre dans l’histoire du droit pénal informatique. Et sa sentence est de 7 mois d’assignation à résidence, probation jusqu’à ses 18 ans, et interdiction d’utiliser un ordinateur à des fins “récréatives”.

Mais Jonathan est un ado. Il est positif à un contrôle antidrogues (cannabis) et viole ainsi sa probation. Direction la prison fédérale de l’Alabama pour 6 mois supplémentaires. Le gamin qui piratait la NASA depuis son lit se retrouve derrière les barreaux.

L’ironie, c’est que son cas va complètement révolutionner la législation sur la cybercriminalité juvénile. Avant Jonathan, les juges ne savaient littéralement pas comment traiter un mineur capable de compromettre des systèmes gouvernementaux. Son procès a forcé le Congrès à repenser les lois fédérales sur les crimes informatiques commis par des mineurs.

Jonathan sort de prison en 2001. Il a 17 ans, un casier judiciaire, et une réputation sulfureuse dans le milieu du hacking et il essaie de se tenir à carreau, de mener une vie normale. Mais son passé va le rattraper de la pire des manières.

En 2007, la chaîne de magasins TJX (TJ Maxx, Marshalls, HomeGoods) subit l’une des plus grosses fuites de données de l’histoire : 45,6 millions de numéros de cartes de crédit volés. L’enquête mène à Albert Gonzalez, un hacker de Miami qui dirigeait un réseau international de cybercriminels, selon le département de la Justice américain .

Source

Mais le problème c’est qu’Albert Gonzalez et Jonathan James se connaissent. Ils évoluent dans les mêmes cercles, fréquentent les mêmes forums, habitent la même région. Alors quand le FBI épluche les connexions de Gonzalez, le nom de c0mrade ressort forcément.

En janvier 2008, le Secret Service débarque chez Jonathan, chez son frère, chez sa copine. Ils retournent tout, confisquent ses ordinateurs, l’interrogent pendant des heures. Jonathan nie catégoriquement toute implication dans le hack TJX. Il répète qu’il n’a plus fait de hacking depuis sa sortie de prison, qu’il essaie de refaire sa vie.

Les agents trouvent une arme à feu légalement détenue et des notes suggérant que Jonathan a déjà pensé au suicide. Mais aucune preuve de sa participation au hack TJX.

Pourtant, l’étau se resserre. La presse s’empare de l’affaire, ressort son passé de “hacker de la NASA”. Jonathan devient paranoïaque, convaincu que le gouvernement veut faire de lui un bouc émissaire. Il sait qu’avec son casier, aucun jury ne croira en son innocence.

Alors le 18 mai 2008, Pinecrest, Floride, Jonathan James, 24 ans, se tire une balle dans la tête sous la douche de sa salle de bain.

Il laisse une note déchirante : “Je n’ai honnêtement, honnêtement rien à voir avec TJX. Je n’ai aucune foi dans le système de ‘justice’. Peut-être que mes actions d’aujourd’hui, et cette lettre, enverront un message plus fort au public. De toute façon, j’ai perdu le contrôle de cette situation, et c’est ma seule façon de le reprendre.”

La suite lui donnera raison : Albert Gonzalez sera condamné à 20 ans de prison, mais aucune preuve ne sera jamais trouvée contre Jonathan James concernant l’affaire TJX.

Ce gamin était un génie pur. Pas le genre de génie qu’on voit dans les films, mais un vrai génie technique, capable de comprendre et d’exploiter des systèmes complexes à un âge où la plupart d’entre nous découvraient à peine Internet.

Le problème, c’est que personne n’a su canaliser ce talent. Ses parents ont essayé de le brider en lui confisquant son ordinateur. Le système judiciaire l’a traité comme un criminel ordinaire. Et la communauté du hacking de l’époque n’avait pas vraiment de garde-fous éthiques.

Et aujourd’hui, combien de c0mrade potentiels traînent-ils sur nos serveurs Discord, nos repos GitHub, nos communautés de makers ?

Maintenant on a des programmes de bug bounty, des certifications en cybersécurité, des bootcamps éthiques. Des voies légales pour exprimer ce genre de talent. Alors que Jonathan n’a jamais eu ces options.

Son héritage, comme celui de Kevin Mitnick , c’est donc d’avoir forcé le monde à prendre la cybersécurité au sérieux. Après ses exploits, la NASA a complètement revu ses protocoles de sécurité, le Pentagone a investi des milliards dans la protection de ses systèmes et le Congrès a voté de nouvelles lois sur la cybercriminalité juvénile.

Je pense que Jonathan James aurait mérité mieux que cette fin tragique. Il aurait pu devenir un expert en cybersécurité, un consultant, un formateur. Il aurait pu utiliser ses compétences pour protéger les systèmes qu’il avait appris à compromettre… C’est triste.

A nous de faire en sorte que les prochains génies du code ne suivent pas le même chemin.

– Sources : wikipedia

https://korben.info/jonathan-james-plus-jeune-hacker-emprisonne-usa.html

I. Présentation

Traefik est un reverse proxy (et un load balancer) open source conçu pour les applications web (HTTP/HTTPS) et la gestion des connexions TCP. Créé par le Français Émile Vauge, Traefik s’est imposé comme une solution incontournable pour publier des applications exécutées au sein de conteneurs Docker, bien que ce ne soit pas le seul cas d’utilisation. Comment fonctionne-t-il ? Comment installer Traefik ? Réponse dans ce guide complet.

Dans un environnement basé sur Docker, il est fréquent d’héberger plusieurs applications web sur un même serveur. Chaque conteneur peut exposer un port différent, mais il devient vite difficile d’organiser les accès, de gérer les certificats TLS, et d’ajouter ou retirer des services sans casser les autres. La solution naturelle pour publier ces applications et mieux s’y retrouver, c’est d’utiliser un reverse proxy. Et parmi les reverse proxy capables de tirer parti de Docker de manière dynamique, Traefik s’est imposé comme une référence en tant que reverse proxy pour microservices.

La force de Traefik, c’est notamment sa capacité à détecter automatiquement vos conteneurs et à simplifier l’intégration d’applications avec de simples labels. À cela s’ajoute la possibilité d’obtenir automatiquement des certificats TLS via Let’s Encrypt (ACME).

Dans ce tutoriel, nous allons installer Traefik sur un serveur Linux (Debian 13) avec Docker Compose, puis déployer une première application pour valider que tout fonctionne correctement. Cette application sera publiée avec Traefik en HTTP puis en HTTPS (avec l’obtention automatique d’un certificat TLS). L’objectif est de comprendre les briques fondamentales de Traefik.

II. Les composants de Traefik

Avant même d’écrire un fichier Docker Compose et de foncer dans le déploiement du reverse proxy Traefik, il est nécessaire de comprendre comment il est structuré. Le schéma ci-dessous met en évidence le positionnement central de Traefik dans l’accès aux applications web et aux API. Du côté backend, même si ce tutoriel est axé sur l’intégration avec Docker, il est envisageable de router le trafic vers d’autres destinations (Kubernetes, machine virtuelle, etc.).

Traefik a quatre briques fondamentales :

Élément Rôle Entrypoint Représente un point d’entrée, c’est-à-dire un port sur lequel Traefik écoute (par exemple, du classique : HTTP sur 80, HTTPS sur 443) Router Décide vers quel service envoyer une requête, en fonction de règles. Par exemple, une correspondante avec un nom d’hôte : app1.it-connect.fr. Service Représente réellement l’application cible, le conteneur Docker qui doit recevoir les requêtes Middleware Permet d’appliquer une transformation sur une requête (par exemple : ajout d’authentification HTTP, redirection, headers, etc.)

Bien qu’il y ait une partie de la configuration de Traefik qui soit statique, il y a aussi une partie de la configuration qui est vivante, voire même dynamique. En pratique, comme nous le verrons par la suite, pour exposer une app via Traefik, nous devons simplement ajouter les labels qu’il faut sur le conteneur, et Traefik récupère la configuration via Docker.

III. Prérequis pour Traefik

Pour la suite, il faut un serveur (Linux) sur lequel Docker et Docker Compose sont installés. Le tutoriel s’applique aussi bien sur un VPS cloud que sur un serveur physique local. Vous devez aussi disposer d’un nom de domaine : it-connectlab.fr sera utilisé pour cette démonstration. Un enregistrement DNS a été fait pour une application dont l’adresse IP correspond au serveur Traefik, ce dernier étant en charge de router le trafic (principe du reverse proxy).

Pour installer Docker sur Linux, vous pouvez suivre ce tutoriel :

Installation de Docker sur Linux IV. Prise en main de Traefik A. Créer la racine du projet

Nous allons commencer par créer un dossier pour stocker les données de l’application Traefik.

mkdir /opt/docker-compose/traefikcd /opt/docker-compose/traefik

À la racine de ce dossier, nous allons créer le fichier docker-compose.yml.

En guise de point de départ, nous allons utiliser le** fichier Docker Compose** disponible dans la documentation de Traefik. La version 3.6 de Traefik sera utilisée, il s’agit de la dernière version stable actuelle. Deux ports sont exposés au niveau de ce conteneur : 80, pour bénéficier d’un entryPoint en HTTP (pour publier une application en HTTP) et 8080 pour l’accès au tableau de bord de Traefik.

# docker-compose.ymlservices: traefik: image: traefik:v3.6 command: - "--api.insecure=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" ports: - "80:80" - "8080:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock

Trois commandes sont aussi associées à l’exécution de ce conteneur en tant qu’arguments :

Argument Signification --api.insecure=true Active le dashboard web de Traefik, sans authentification (sur le port 8080 par défaut). --providers.docker=true Active le Provider Docker de Traefik pour découvrir automatiquement les services / labels. --entrypoints.web.address=:80 Déclare un entryPoint nommé web, qui écoute sur port 80 dans le conteneur. Idéal pour les accès HTTP.

Enfin, une dernière ligne importante est intégrée à ce fichier : /var/run/docker.sock:/var/run/docker.sock. Elle permet à Traefik d’accéder au socket Docker pour “voir” en temps réel les autres conteneurs. C’est important pour l’intégration de Traefik avec Docker, notamment pour lire les labels.

B. Créer un réseau Docker pour Traefik

Vous remarquerez que ce Docker Compose ne contient pas de directives pour la connexion au réseau du conteneur. C’est la première évolution que nous allons lui apporter. Nous allons créer un réseau Docker nommé frontend, ce qui me semble être un nom adapté dans le contexte d’un reverse proxy.

docker network create frontend

Une fois le réseau créé, vérifiez qu’il est bien présent :

docker network ls

Dans le fichier Docker Compose, nous allons associer ce réseau au conteneur Traefik. Il sera déclaré comme un réseau externe (external: true) pour ne pas que Docker cherche à le créer.

# docker-compose.ymlservices: traefik: image: traefik:v3.6 command: - "--api.insecure=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" ports: - "80:80" - "8080:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock networks: - frontendnetworks: frontend: external: true

Note: le port HTTPS, à savoir 443, n’est pas exposé pour le moment. Si vous envisagez dès maintenant de publier une application HTTPS, vous pouvez ajouter le port dès maintenant via l’ajout d’une ligne supplémentaire.

C. Le fichier traefik.yml

La configuration globale et statique de Traefik se déclare par l’intermédiaire du fichier traefik.yml, au format YAML.

Nous allons ajouter une ligne sous volumes pour déclarer le fichier de configuration de Traefik, afin qu’il soit persistant et modifiable, tout en étant lu par le conteneur. Par la suite, nous manipulerons à plusieurs reprises le fichier traefik.yml pour ajouter différentes directives.

volumes: - /var/run/docker.sock:/var/run/docker.sock - ./traefik.yml:/etc/traefik/traefik.yml:ro

Le fichier doit donc être créé à cet emplacement : /opt/docker-compose/traefik/traefik.yml.

Éditez le fichier et ajoutez le code précisé ci-dessous pour définir les bases de Traefik en mode proxy inverse pour HTTP et HTTPS.

Nous désactivons l’envoi de statistiques anonymisées (sendAnonymousUsage) et la vérification automatique de nouvelles versions (checkNewVersion). Nous activons le tableau de bord interne (port 8080) en mode non sécurisé (pas adapté à la production !) afin de pouvoir y accéder dans un premier temps pour visualiser les routes de Traefik. Enfin, on déclare deux entryPoints : un pour le trafic HTTP classique sur le port 80 (nommé web), et un second pour le trafic HTTPS sécurisé sur le port 443 (nommé websecure). Cela prépare Traefik à écouter sur ces deux ports et à accepter des requêtes entrantes que l’on pourra ensuite router vers nos conteneurs.

# Configuration statique de Traefikglobal: checkNewVersion: false sendAnonymousUsage: false api: dashboard: true # Dashboard Traefik : 8080 insecure: true entryPoints: web: address: ":80" # EntryPoint pour HTTP websecure: address: ":443" # EntryPoint pour HTTPS

Enregistrez et fermez le fichier.

Pour éviter les doublons entre la configuration statique et les arguments en ligne de commande, je vous invite à supprimer la ligne command et les trois lignes associées dans le fichier Docker Compose, à savoir :

command: - "--api.insecure=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" D. Intégrer Docker à Traefik

Dans le fichier Docker Compose, le nécessaire a été fait pour que le conteneur Traefik dispose d’un accès au socket de Docker (/var/run/docker.sock). Mais ce lien n’est pas exploité en l’état actuel de la configuration. Dans le fichier de configuration⁣ traefik.yml, il est nécessaire d’ajouter un nouveau fournisseur (Provider) correspondant à Docker.

Éditez de nouveau le fichier traefik.yml et ajoutez ce bloc à la fin du fichier :

providers: docker: endpoint: "unix:///var/run/docker.sock" exposedByDefault: false

La directive exposedByDefault joue un rôle important ! Si elle est sur false comme ici, cela signifie que Traefik va détecter les conteneurs Docker sans les exposer automatiquement : seuls les conteneurs qui auront des labels Traefik seront pris en compte et routés, ce qui évite d’exposer par erreur un service qui ne devrait pas être accessible depuis l’extérieur.

Désormais, enregistrez la configuration et lancez la construction du conteneur Traefik (depuis le répertoire /opt/docker-compose/traefik).

docker compose up -d E. Accéder au tableau de bord Traefik

Ouvrez un navigateur web et accédez au tableau de bord de Traefik via l’adresse IP de l’hôte Docker sur le port 8080. Par exemple : http://192.168.10.200:8080. Ce tableau de bord ne permet pas d’effectuer la configuration en ligne, mais il présente l’avantage d’afficher l’état de la configuration actuelle. Vous devriez notamment visualiser les 3 entryPoints de notre configuration Traefik (celui du dashboard est automatique quand ce dernier est activé).

F. Associer un service HTTP à Traefik

Traefik tourne sur notre serveur, c’est une bonne chose. Mais, pour le moment, il ne sert pas à grand-chose car aucun service n’est exposé par son intermédiaire. Pour commencer, nous allons exposer une application facile à héberger : IT-Tools, une boite à outils en ligne. Dans un premier temps, l’accès sera effectué en HTTP, puisque la gestion du certificat rajoute une couche de complexité supplémentaire.

Créez un dossier pour ce projet :

mkdir /opt/docker-compose/it-tools

Dans ce répertoire, créez un fichier docker-compose.yml et insérez le code ci-dessous. Ce service lance l’application IT-Tools à partir de l’image officielle ghcr.io/corentinth/it-tools:latest et nomme le conteneur it-tools. Il est important de noter aussi que ce conteneur est rattaché au réseau Docker externe frontend, le même réseau que Traefik : c’est ce qui permet à Traefik de le découvrir et de router le trafic vers lui (grâce au montage du socket Docker côté Traefik et au provider Docker activé). Il n’y a donc pas de port exposé sur l’hôte pour ce conteneur.

services: it-tools: image: ghcr.io/corentinth/it-tools:latest container_name: it-tools restart: unless-stopped networks: - frontend labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web networks: frontend: external: true

Il y a aussi une section labels essentielle pour permettre la découverte par Traefik.

Les Labels Traefik : ce qu’ils font

**traefik.enable=true **: nécessaire car, dans notre config Traefik, il y a l’instruction exposedByDefault: false. Ce label autorise explicitement Traefik à gérer ce service. traefik.http.routers.it-tools.rule=Host(\it-tools.it-connectlab.fr): crée un routeur HTTP nommé it-tools qui ne s’active que lorsque la requête du client Web est à destination de l’hôte it-tools.it-connectlab.fr (soit un enregistrement DNS à associer). traefik.http.routers.it-tools.entrypoints=web : indique que ce routeur écoute sur l’entrypPoint intitulé web donc celui qui écoute sur le port 80.

Petite parenthèse : il est à noter que Traefik va automatiquement associer un service à ce routeur. Chaque service est associé à un module load balancer Traefik (équilibrage de charge), car c’est une fonction indispensable pour chaque reverse proxy pour distribuer la charge en plusieurs serveurs de backends. Même s’il n’y a qu’un seul serveur de backend, comme c’est le cas ici avec un seul conteneur, il y a le load balancer. Dans le cas présent, afin de compléter la configuration, nous pourrions ajouter ce label supplémentaire (c’est important sur les conteneurs où plusieurs ports sont en écoute) :

- traefik.http.services.it-tools.loadbalancer.server.port=80

Enregistrez le fichier et lancez le déploiement de l’application :

docker compose up -d

À partir d’un navigateur Web, vous devriez pouvoir accéder à l’application :

L’application a été correctement publiée par l’intermédiaire de Traefik !

V. Traefik HTTPS : comment ça marche ? A. ACME avec Traefik

Un accès en HTTP en 2025, ce n’est pas l’idéal tant le HTTPS s’est démocratisé depuis plusieurs années. Surtout, il n’est pas nécessaire de payer pour obtenir un certificat TLS valide : merci Let’s Encrypt. La bonne nouvelle, c’est que Traefik supporte deux Certificate Resolvers : **ACME **(donc Let’s Encrypt) et **Tailscale **pour les services internes et accessibles via cette solution.

Dans le contexte de la méthode ACME, Traefik prend en charge plusieurs types de challenges pour demander automatiquement le certificat. Il y a le challenge HTTP (httpChallenge) qui est surement le plus classique, mais qui implique que l’hôte soit accessible en HTTP sur le port 80. Surtout, il y a le challenge DNS (dnsChallenge) grâce à l’intégration de Lego, ce qui permet de jouer sur les enregistrements DNS de façon automatique en ciblant les API des gestionnaires de zones DNS.

Par exemple : vous disposez d’un domaine enregistré chez OVHCloud, vous pouvez effectuer des demandes de certificats Let’s Encrypt via le composant ACME intégré à Traefik, le tout via l’API de OVHCloud. Autrement dit, c’est un processus pleinement automatisé. Cela est aussi vrai pour des dizaines d’autres providers DNS compatibles Traefik, comme Cloudflare, Azure DNS, Gandi, Hostinger ou encore Ionos (voir cette page).

Pour la suite de cet article, l’objectif sera le suivant : obtenir un certificat TLS pour le domaine it-tools.it-connectlab.fr afin de publier l’application en HTTPS. Ce domaine étant enregistré chez OVHCloud, nous devrons utiliser leur API.

B. Traefik : exposer le port 443

Vous devez commencer par exposer le 443 au niveau du conteneur Traefik en éditant le fichier docker-compose.yml de ce projet.

ports: - "80:80" - "8080:8080" - "443:443" C. Créer une clé d’API OVHCloud pour Traefik

Vous devez commencer par créer une nouvelle API d’application à partir du portail OVHCloud. Pour l’Europe, il faut accéder à la page eu.api.ovh.com/createApp/, tandis que pour les États-Unis et le Canada, c’est sur la page ca.api.ovh.com/createApp/.

Donnez un nom à l’application et précisez une description. Par exemple :

En retour, vous obtenez une clé d’application et un secret associé. Vous devez garder précieusement ces deux informations.

Ensuite, à l’aide d’une console PowerShell (passez par PowerShell ISE ou VSCode, ce sera plus pratique), vous devez envoyer une requête sur l’API pour donner des droits à cette application. Utilisez le code ci-dessous, en adaptant le nom DNS pour cibler le bon domaine, ainsi que la valeur à la suite de X-Ovh-Application en précisant la clé d’application.

curl -XPOST -H "X-Ovh-Application: 3f6ed0ayzxyz" -H "Content-type: application/json" https://eu.api.ovh.com/1.0/auth/credential -d '{ "accessRules":[ { "method":"POST", "path":"/domain/zone/it-connectlab.fr/record" }, { "method":"POST", "path":"/domain/zone/it-connectlab.fr/refresh" }, { "method":"DELETE", "path":"/domain/zone/it-connectlab.fr/record/*" } ], "redirection":"https://www.it-connectlab.fr"}'

L’exécution de cette commande retourne deux informations importantes :

consumerKey : vous devez conserver la valeur associée à ce champ, car elle sera nécessaire pour la suite de la configuration. validationUrl : vous devez copier cette URL et y accéder avec votre navigateur préféré pour valider l’autorisation. {"consumerKey":"cf5b9e91fffff21233464135","validationUrl":"https://www.ovh.com/auth/sso/api?credentialToken=04fa6c66011dc8498ab80814b140d6b1eea133e520612228fc3620747de0cfdc","state":"pendingValidation"}

L’URL à laquelle vous avez accédé précédemment affiche une demande de confirmation comme celle ci-dessous. Pensez à ajuster la durée de validité de cet accès et cliquez sur le bouton “Authorize”.

5bbf2121-2cc0-476a-bc54-da96bb1d384a-image.png

Vous serez redirigé vers la page indiquée lors de l’exécution de la commande curl. Même si le domaine ne renvoie vers rien, ce n’est pas gênant.

Voilà, l’accès est prêt au niveau de l’API OVHCloud et de votre compte.

D. Utiliser OVHCloud avec Traefik

Puisque Traefik intègre Lego, vous devez consulter la documentation du fournisseur DNS correspondant à vos besoins pour savoir comment le configurer. Vous pouvez consulter, par exemple, la page concernant ovh. Ici, nous allons ajouter 4 variables d’environnement au fichier docker-compose.yml de Traefik :

OVH_ENDPOINT : définit le point d’accès de l’API OVH (par exemple : ovh-eu), afin que Traefik sache vers quelle région OVH communiquer. OVH_APPLICATION_KEY : identifie l’application (ici Traefik) auprès de l’API OVH. OVH_APPLICATION_SECRET : sert à authentifier de façon sécurisée l’application auprès de l’API OVH. OVH_CONSUMER_KEY : autorise l’application à agir au nom de ton compte OVH, selon les droits accordés lors de la création de la clé.

Dans le fichier Docker Compose, ces variables sont introduites sans valeur directe, car nous allons utiliser un fichier externe. En même temps, dans la section volumes, rajoutez le montage du dossier ./certs (soit /opt/docker-compose/traefik/certs/ que vous devrez créer).

# docker-compose.ymlservices: traefik: image: traefik:v3.6 restart: unless-stopped environment: - OVH_ENDPOINT=${OVH_ENDPOINT} - OVH_APPLICATION_KEY=${OVH_APPLICATION_KEY} - OVH_APPLICATION_SECRET=${OVH_APPLICATION_SECRET} - OVH_CONSUMER_KEY=${OVH_CONSUMER_KEY} ports: - "80:80" - "8080:8080" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock - ./traefik.yml:/etc/traefik/traefik.yml:ro - ./certs:/var/traefik/certs:rw networks: - frontendnetworks: frontend: external: true

Enregistrez et fermez ce fichier. Aux côtés du fichier Docker Compose, créez le fichier .env et associez les bonnes valeurs aux variables. Mise à part pour la première variable, pour les autres, ce sont des informations confidentielles spécifiques à votre environnement.

OVH_ENDPOINT=ovh-euOVH_APPLICATION_KEY=3f6ed77777777OVH_APPLICATION_SECRET=f6f8d623bf73abcdefghxyzzzzOVH_CONSUMER_KEY=cf5b9e913c5776itconnect2025 E. Ajouter un résolveur ACME

Pour autant, la configuration ne s’arrête pas là. Ensuite, vous allez devoir ouvrir le fichier de configuration traefik.yml. Vérifiez la présence d’un entryPoint HTTPS, comme websecure dans l’exemple ci-dessous.

Dans cette configuration, nous devons définir un nouveau résolveur de certificats ACME pour OVHCloud utilisé par Traefik pour obtenir automatiquement des certificats SSL/TLS via Let’s Encrypt.

Dans cet exemple, le résolveur sera simplement nommé ovhcloud, une adresse e-mail ([email protected]) est associée au compte ACME, tandis que le fichier /var/traefik/certs/ovh-acme.json stocke les certificats et clés générés. Le paramètre caServer indique l’URL de l’API Let’s Encrypt, ici en mode production (avec une alternative en mode staging, moins limitée). Vous pouvez tout à fait utiliser le mode staging pour tester la configuration, puis basculer en mode production ensuite.

Enfin, la section dnsChallenge précise que la validation du domaine s’effectue via OVHCloud, en créant automatiquement un enregistrement DNS (demandé par Let’s Encrypt au cours du processus). Le delayBeforeCheck de 10 secondes associé laisse le temps à la propagation DNS avant la vérification du certificat. Si vous indiquez 0, cela améliore la réactivité mais c’est aussi une source d’erreur, ce qui est contreproductif.

# Configuration statique de Traefikglobal: checkNewVersion: false sendAnonymousUsage: false api: dashboard: true # Dashboard Traefik : 8080 insecure: true entryPoints: web: address: ":80" # EntryPoint pour HTTP websecure: address: ":443" # EntryPoint pour HTTPS certificatesResolvers: ovhcloud: acme: email: "[email protected]" storage: "/var/traefik/certs/ovh-acme.json" caServer: "https://acme-v02.api.letsencrypt.org/directory" # Production #caServer: "https://acme-staging-v02.api.letsencrypt.org/directory" dnsChallenge: provider: ovh delayBeforeCheck: 10 providers: docker: endpoint: "unix:///var/run/docker.sock" exposedByDefault: false

Enregistrez et fermez le fichier. La configuration de Traefik est terminée ! Pensez à faire un Down/Up sur le conteneur pour recharger la configuration.

F. Ajouter un routeur HTTPS à Traefik

Pour que notre application IT-Tools soit accessible en HTTPS, sa configuration doit être adaptée. Je vous rappelle que ses labels actuels s’appuient sur l’entryPoint en HTTP. Ouvrez le fichier Docker Compose de l’application, puis ajoutez quatre lignes supplémentaires dans les labels regroupées avec le nom de routeur it-tools-https :

services: it-tools: image: ghcr.io/corentinth/it-tools:latest container_name: it-tools restart: unless-stopped networks: - frontend labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web - traefik.http.routers.it-tools-https.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools-https.entrypoints=websecure - traefik.http.routers.it-tools-https.tls=true - traefik.http.routers.it-tools-https.tls.certresolver=ovhcloudnetworks: frontend: external: true

Ces directives configurent le routeur HTTPS de Traefik pour l’application it-tools. L’entrée entrypoints=websecure indique que ce routeur utilise le point d’entrée HTTPS. Le paramètre tls=true active le chiffrement TLS pour sécuriser les connexions. Enfin, tls.certresolver=ovhcloud précise que les certificats TLS/SSL doivent être obtenus automatiquement via le résolveur ACME nommé ovhcloud (nom précisé dans traefik.yml).

Arrêter ce projet et relancez-le (Down/Up).

Il ne reste plus qu’à tester l’accès en HTTPS à l’application : https://it-tools.it-connectlab.fr. Si vous êtes en mode STAGING sur Let’s Encrypt, il y aura bien un certificat mais il n’est pas valide (ce qui est normal). Cela permet de valider le bon fonctionnement de la configuration.

G. Traefik : redirection HTTP vers HTTPS

Pour finaliser la configuration, il me semble judicieux de configurer la redirection HTTP vers HTTPS. De ce fait, les applications publiées seront accessibles uniquement au travers d’une connexion sécurisée. Les requêtes HTTP seront redirigées, plutôt que de finir dans le vide…

À ce sujet, il y a une technique évoquée dans la documentation de Traefik et que nous pouvons appliquer. Au sein du fichier traefik.yml, nous allons éviter l’entryPoint web pour ajouter une redirection en HTTPS vers l’entryPoint websecure.

entryPoints: web: address: ":80" # EntryPoint pour HTTP http: redirections: entryPoint: to: websecure scheme: https websecure: address: ":443" # EntryPoint pour HTTPS

Ce qui correspond à l’ajout de ces lignes :

Vous n’avez plus qu’à relancer le conteneur Traefik et à tester !

VI. Les journaux de debug de Traefik

Dans le cas où la configuration ne fonctionne pas, vous devez aller faire un tour dans les journaux de Traefik. Par défaut, seules les erreurs sont retournées, ce qui peut être trop limite pour du troubleshooting Traefik.

Ouvrez le fichier traefik.yml et ajoutez ces lignes pour ajuster le niveau de logs. Ici, nous configurons le mode DEBUG qui est le plus verbeux.

log: level: DEBUG # Niveau de log

Ensuite, arrêtez et relancez le conteneur. Attention, les journaux ne sont pas persistants, donc le redémarrage implique un effacement des journaux.

Consultez les journaux du conteneur Traefik, vous devriez voir de nombreuses informations passer dans la console. Si tout se passe bien, il y aura quand même des informations dans les logs, c’est aussi tout l’intérêt du mode debug.

/opt/docker-compose/traefik$ docker compose logs -f --tail 100

Je vous encourage aussi à vérifier :

La syntaxe de vos fichiers de configuration : attention au copier-coller, au formatage et aux erreurs de frappe. La configuration des entryPoints et des ports exposés au niveau du conteneur Traefik. Les permissions sur les répertoires associés aux données persistantes de Traefik. VII. Conclusion

Grâce à ce guide d’introduction à Traefik, vous devriez être capable de mettre en place un reverse proxy dans des environnements basés sur Docker. Vous disposez des bases nécessaires pour bien comprendre le fonctionnement de Traefik, afin de l’adapter à vos besoins et votre contexte.

Pour aller plus loin, consultez la documentation officielle de Traefik et notamment cette page qui regroupe tous les labels Docker. Aimeriez-vous d’autres tutoriels sur Traefik ? N’hésitez pas à partager vos suggestions en commentaire.

FAQ Qu’est-ce que Traefik et à quoi sert-il ?

Traefik est un reverse proxy et un load balancer qui simplifie la gestion du trafic réseau vers des applications, conteneurs ou services, tout en automatisant la configuration grâce à l’intégration avec Docker, Kubernetes, ou d’autres orchestrateurs. Il a été créé par Émile Vauge, un Français.

Comment fonctionne l’auto-discovery des services dans Traefik ?

Traefik se connecte à un “provider” (tel que Docker ou Kubernetes) et détecte les conteneurs ou services exposés. Il crée automatiquement les routes et règles associées selon les labels configurés. La découverte automatique peut être désactivée pour éviter que des services inappropriés soient exposés. Le provider agit comme une source de configuration dynamique.

Comment Traefik gère-t-il les certificats SSL/TLS ?

Traefik prend en charge Let’s Encrypt et plus particulièrement l’ACME. Ainsi, il peut demander, renouveler et gérer automatiquement les certificats SSL/TLS pour les domaines associés à vos applications, garantissant un accès HTTPS avec un certificat valide et sans configuration complexe.

Traefik peut-il gérer plusieurs domaines ou sous-domaines ?

Oui. Chaque domaine ou sous-domaine peut être routé vers un service différent grâce aux règles (comme Host()) dans la configuration ou via des labels Docker.

À quoi sert le tableau de bord de Traefik ?

Le tableau de bord (Dashboard) de Traefik permet de visualiser en temps réel la configuration active : routes, middlewares, services, certificats et métriques. Il aide au diagnostic et à la supervision du trafic. Mais, il ne permet pas de faire la configuration en ligne : c’est uniquement de la lecture seule.

Comment fonctionnent les middlewares dans Traefik ?

Les middlewares servent à transformer les requêtes : ajout d’en-têtes, authentification avant de pouvoir accéder à une application, filtrage applicatif (WAF), etc. On peut dire qu’ils ajoutent des capacités supplémentaires à Traefik.

Quels sont les journaux (logs) générés par Traefik ?

Traefik produit deux types de logs : les access logs (requêtes HTTP) et les logs applicatifs (erreurs, warnings, événements internes). Comme l’explique cet article, il y a notamment un paramètre permettant d’ajuster le niveau de log.

Comment monitorer Traefik ?

Traefik expose des métriques au format OpenTelemetry et dans des formats adaptés pour des solutions comme Prometheus et InfluxDB2. Il y a également un tableau de bord prêt à l’emploi pour Grafana. Un bloc de configuration metrics: permet d’ajuster la configuration des métriques exposées et leur accès.

– Source :

https://www.it-connect.fr/tuto-traefik-reverse-proxy-avec-docker/

Une petite interview de Michael Crandell, PDG chez Bitwarden

– Source :

https://www.clubic.com/actualite-591613-bitwarden-pour-un-monde-ou-personne-ne-se-fait-pirater---interview-michael-crandell.html

I. Présentation

Protégez vos services web avec Tinyauth : une solution open source légère, simple à déployer et idéale pour centraliser l’authentification dans votre Home Lab ou votre environnement Docker. Ce tutoriel explique comment installer et configurer Tinyauth en tant que middleware pour Traefik.

Dans un Home Lab, multiplier les services web rime souvent avec multiplier les écrans de connexion, enfin, quand ils existent. Pour ajouter une authentification centralisée à toutes les applications, vous pouvez opter pour des solutions comme Authentik ou Keycloak. Au-delà de ces deux applications très connues, il y a Tinyauth : une approche légère et épurée de l’authentification, pensée pour protéger facilement vos services derrière un reverse proxy (Traefik, Nginx Proxy Manager, Caddy).

Que ce soit dans un Home Lab, une petite infrastructure ou un environnement de dev, on peut rapidement se retrouver avec une multitude de services web : interfaces d’administration, outils internes, dashboards… C’est là que Tinyauth intervient. Couplé à Traefik, il permet d’unifier l’authentification sans mettre en place une usine à gaz. Tinyauth se place entre les utilisateurs et les conteneurs Docker pour afficher une page de login.

Pour authentifier les utilisateurs, Tinyauth peut s’appuyer sur une base de comptes locale, utiliser OAuth (sur Google ou GitHub, par exemple) et même s’interfacer avec un annuaire LDAP (LLDAP, OpenLDAP, Active Directory).

Note: l’intégration de Tinyauth avec vos services web Docker est basée sur le mécanisme de ForwardAuth de Traefik.

II. Principe de fonctionnement : Traefik + Tinyauth

Avant la partie pratique, clarifions le rôle de chacun des composants utilisés :

Traefik : reverse proxy / load balancer qui reçoit les requêtes HTTP(S) et les route vers vos services (une boite à outils, un wiki, un site web, etc.). Tinyauth : service d’authentification et d’autorisation. Il reçoit les requêtes “à valider” de la part de Traefik en agissant comme un middleware, puis il authentifie l’utilisateur avant de répondre à Traefik.

Le lien entre Traefik et Tinyauth se fait grâce au mécanisme ForwardAuth :

Le client demande l’accès à un service web, par exemple : https://it-tools.it-connectlab.fr. Traefik intercepte la requête et l’envoie d’abord à Tinyauth (ForwardAuth). Tinyauth entre en action si l’utilisateur : n’est pas connecté, renvoie une redirection vers une page de login ; est connecté mais n’a pas les autorisations, renvoie une erreur (403 par exemple) ; est connecté et autorisé, il renvoie un 2xx avec éventuellement des en-têtes HTTP spécifiques. Traefik relaie alors la requête au service cible, en y ajoutant les en-têtes reçus.

Vos applications n’ont pas besoin de gérer elles-mêmes l’authentification, c’est Tinyauth qui s’en charge en proposant un portail d’authentification.

III. Installation de Tinyauth avec Docker

Point de départ de cette démonstration : un serveur Linux (Debian) sur lequel Docker est installé. Un conteneur avec le reverse proxy Traefik est déjà en cours d’exécution, tout comme un conteneur avec l’application IT-Tools. Cette application est accessible, sans authentification, à l’adresse suivante : https://it-tools.it-connectlab.fr. Si vous souhaitez utiliser ce point de départ, suivez mon guide d’introduction à Traefik.

L’objectif : protéger l’accès à IT-Tools en ajoutant une page de connexion gérée par Tinyauth.

A. Créer le dossier pour le projet

Nous allons commencer par créer un répertoire pour stocker les fichiers du projet Tinyauth :

mkdir /opt/docker-compose/tinyauth B. Docker Compose Tinyauth

À l’intérieur du répertoire créé précédemment, nous allons créer un fichier docker-compose.yml. Voici le code à insérer dans ce fichier :

services: tinyauth: image: ghcr.io/steveiliop56/tinyauth:v4 container_name: tinyauth restart: unless-stopped networks: - frontend environment: - APP_URL=https://tinyauth.it-connectlab.fr - USERS=${USERS} - SECRET=${SECRET} - LOG_LEVEL=debug labels: - traefik.enable=true - traefik.http.routers.tinyauth.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth.entrypoints=web - traefik.http.routers.tinyauth-https.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth-https.entrypoints=websecure - traefik.http.routers.tinyauth-https.tls=true - traefik.http.routers.tinyauth-https.tls.certresolver=ovhcloud - traefik.http.services.tinyauth.loadbalancer.server.port=3000 - traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik networks: frontend: external: true

Cette configuration crée un conteneur nommé tinyauth, connecté au réseau Docker frontend sur lequel est déjà connecté Traefik. L’application Tinyauth sera accessible via l’adresse https://tinyauth.it-connectlab.fr (APP_URL), à laquelle deux routers Traefik sont associés (un en HTTP, l’autre en HTTPS). Un certificat TLS Let’s Encrypt sera obtenu via le fournisseur de certificat ovhcloud, qui est configuré dans Traefik (c’est une interaction avec l’API OVHcloud pour gérer le challenge DNS du processus ACME).

J’attire votre attention sur deux variables d’environnement pour lesquelles les valeurs seront stockées dans un fichier distinct :

USERS = sert à déclarer, de façon statique, un ou plusieurs utilisateurs. SECRET = sert à signer et chiffrer les sessions ou les jetons (cookies) générés par Tinyauth.

Enregistrez et fermez ce fichier.

Vous devez générer une valeur aléatoire pour la variable SECRET. En ligne de commande, vous pouvez le faire à l’aide d’OpenSSL comme ceci : openssl rand -base64 32 | tr -dc 'a-zA-Z0-9' | head -c 32.

Pour créer un utilisateur statique, vous avez besoin de deux informations : un nom d’utilisateur et un mot de passe, ou plutôt le hash BCrypt d’un mot de passe. Vous pouvez utiliser un outil en ligne pour obtenir cette information ou en ligne de commande, avec la commande mkpasswd, par exemple.

apt install whois -y mkpasswd --method=bcryptPassword:# Saisissez le mot de passe en mode interactif et copiez la valeur obtenue.

Voici un exemple de valeur obtenue (le point final fait partie de la valeur) : $2b$05$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.

Vous pouvez alors constituer une chaine sous cette forme : <nom utilisateur>:<hash bcrypt>. Dans l’exemple ci-dessous, le nom du compte sera adm_fb.

Créez un fichier nommé .env et ajoutez ce contenu :

USERS=<nom utilisateur>:<hash bcrypt>SECRET=<la valeur obtenue avec la commande openssl> # Par exemple :USERS=adm_fb:$2b$05$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.SECRET=2BBUv0YFcZRoWMndmG9kaI3US5QU7u6Z

J’ai eu des cas où il fallait doubler les $ dans la valeur du mot de passe pour que ça fonctionne. Ce qui donnerait :

$$2b$$05$$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.

Enregistrez et lancez la création du conteneur Docker TinyAuth :

cd /opt/docker-compose/tinyauthdocker compose up -d IV. Protéger un service web avec Tinyauth

Pour ajouter une page d’authentification à un service web exécuté dans un conteneur Docker, vous devez éditer le fichier Docker Compose de l’application en question. Ici, nous prenons l’exemple du service IT-Tools, donc nous allons éditer le fichier /opt/docker-compose/it-tools/docker-compose.yml.

Dans la section dédiée aux labels Traefik, vous devez ajouter cette ligne pour lui associer le middleware Tinyauth :

- traefik.http.routers.it-tools-https.middlewares=tinyauth

Ce qui donne cette configuration complète :

labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web - traefik.http.routers.it-tools-https.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools-https.entrypoints=websecure - traefik.http.routers.it-tools-https.tls=true - traefik.http.routers.it-tools-https.tls.certresolver=ovhcloud - traefik.http.routers.it-tools-https.middlewares=tinyauth

Suite à cette modification, relancez le conteneur applicatif :

cd /opt/docker-compose/it-toolsdocker compose downdocker compose up -d --build

Tentez d’accéder à l’application web, ici représentée par l’adresse : https://it-tools.it-connectlab.fr. Au lieu d’avoir l’interface d’IT-Tools, la page de connexion Tiny Auth s’affiche :

Donc, là, il n’y a plus le choix : il faut s’authentifier avec le compte renseigné dans le fichier .env.

Une fois l’authentification réussie, le reverse proxy Traefik nous redirige vers l’application IT-Tools. La configuration est opérationnelle !

V. Tinyauth et l’authentification OAuth

Plutôt que d’utiliser une base de comptes locale, nous allons utiliser la méthode OAuth couplée à GitHub. Ainsi, il sera possible de s’authentifier auprès du portail Tinyauth à l’aide d’un compte GitHub.

La première étape consiste à créer une nouvelle application OAuth sur GitHub (à partir de votre compte GitHub). Vous pouvez créer une application OAuth sur GitHub via la page github.com/settings/developers. Cliquez sur le bouton “New OAuth app”.

– Vous devez ensuite :

Spécifier un nom pour l’application Définir la Homepage URL, c’est-à-dire l’adresse de votre Tinyauth. Spécifier la callback URL, en utilisant l’adresse de Tinyauth + /api/oauth/callback/github.

Voici un exemple :

Vous arrivez sur la page de votre application. Cliquez sur le bouton “Generate a new client secret” pour générer un secret permettant d’utiliser cette application. Copiez le “Client ID” et “Client secret” car nous allons en avoir besoin par la suite.

Éditez le fichier de configuration du conteneur Tinyauth :

nano /opt/docker-compose/tinyauth/docker-compose.yml

Puis, ajoutez ces trois variables d’environnement :

- PROVIDERS_GITHUB_CLIENT_ID=${PROVIDERS_GITHUB_CLIENT_ID} - PROVIDERS_GITHUB_CLIENT_SECRET=${PROVIDERS_GITHUB_CLIENT_SECRET} - OAUTH_WHITELIST=${OAUTH_WHITELIST}

Quelques explications s’imposent :

PROVIDERS_GITHUB_CLIENT_ID : la valeur Client ID obtenue précédemment. PROVIDERS_GITHUB_CLIENT_SECRET : la valeur Client secret obtenue précédemment. PROVIDERS_GITHUB_CLIENT_ID : la liste des adresses e-mail de comptes GitHub autorisés à se connecter. Sinon, n’importe qui avec un compte GitHub peut s’authentifier sur votre portail.

Puis, dans le fichier .env, configurez les variables d’environnement avec vos valeurs (ajoutez ces lignes à la suite de celles déjà présentes) :

PROVIDERS_GITHUB_CLIENT_ID=Ov23liQVitconnectPROVIDERS_GITHUB_CLIENT_SECRET=e78bf94fb2ab4f16ditconnectitconnectOAUTH_WHITELIST=mon-utilisateur@it-connect.fr

Enregistrez, puis relancez le conteneur Tinyauth :

cd /opt/docker-compose/tinyauth/dodocker compose downdocker compose up -d --build

Désormais, quand nous tentons une connexion à l’application, un nouveau bouton apparaît sur la page de connexion Tinyauth ! Il permet de s’authentifier avec GitHub, ce qui est plutôt de bonne augure !

Il convient alors de préciser son nom d’utilisateur et son mot de passe.

Puis, d’autoriser l’application Tinyauth à obtenir l’adresse e-mail et les informations du profil (en lecture seule). Ces informations peuvent aussi être relayées à l’application sur laquelle une connexion est tentée.

Une fois l’authentification GitHub réussie, vous accédez à votre application !

VI. Personnaliser l’interface de Tinyauth

Tinyauth prend en charge plusieurs variables d’environnement que vous pouvez utiliser pour configurer votre instance, y compris pour personnaliser l’apparence. Vous pouvez notamment changer le titre et le fond d’écran. Voyons comment effectuer ces deux modifications.

Ouvrez le fichier /opt/docker-compose/tinyauth/docker-compose.yml. Dans la section environment, ajoutez la variable APP_TITLE avec la valeur souhaitée pour le titre visible au-dessus du formulaire. Par exemple :

- APP_TITLE=IT-Connect Lab

Pour utiliser un fond d’écran personnalisé, vous avez deux options :

Stocker l’image sur votre serveur et la monter dans le conteneur Tinyauth. Pointer vers l’image via une URL web, ce qui peut être une ressource externe hébergée sur un autre domaine.

Dans le cas où vous souhaitez stocker l’image sur votre serveur, vous devez positionner le fichier sous /opt/docker-compose/tinyauth/ puis le monter dans le conteneur via l’ajout d’une ligne sous volumes. Par exemple :

volumes: - ./wallpaper.jpg:/data/resources/wallpaper.jpg:ro

Puis, dans la section environment, ajoutez deux lignes pour préciser le chemin vers le dossier disposant des ressources personnalisées (RESOURCES_DIR), puis le chemin vers le fichier image en lui-même (BACKGROUND_IMAGE). Voici un exemple (respectez bien ce format).

- RESOURCES_DIR=/data/resources - BACKGROUND_IMAGE=/resources/wallpaper.jpg

Relancez le conteneur avec la nouvelle configuration :

docker compose downdocker compose up -d --build

VII. Le contrôle d’accès avec Tinyauth

Tinyauth intègre des fonctions pour le contrôle d’accès, notamment pour limiter l’accès à certains sous-domaines (ou certaines URL / chemins) uniquement à certains utilisateurs. Vous pouvez créer des règles basées sur les utilisateurs, les comptes OAuth, les chemins et les adresses IP (autoriser uniquement les connexions depuis une liste blanche d’adresses IP, par exemple).

Dans tous les cas, Tinyauth doit pouvoir surveiller vos conteneurs et lire les labels (comme le fait Traefik). Vous devez donc ajouter ce volume dans la configuration de Tinyauth :

volumes: - /var/run/docker.sock:/var/run/docker.sock:ro

La configuration s’effectue ensuite au niveau de chaque application, grâce à un système de labels Tinyauth. Vous devez rajouter une ligne pour préciser le nom de domaine de l’application (bien que ce soit facultatif car Tinyauth prend par défaut le sous-domaine) et ensuite ajouter les ACL Tinyauth.

L’exemple ci-dessous, positionné sur l’application IT-Tools, permet d’autoriser uniquement le compte adm_fb à accéder à cette application. Ici, on autorise explicitement un utilisateur (on peut aussi en préciser plusieurs), donc tous les autres seront interdits. Nous pouvons aussi faire l’inverse : tout autoriser et bloquer uniquement certains comptes, mais j’aime moins cette approche.

labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web - traefik.http.routers.it-tools-https.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools-https.entrypoints=websecure - traefik.http.routers.it-tools-https.tls=true - traefik.http.routers.it-tools-https.tls.certresolver=ovhcloud - traefik.http.routers.it-tools-https.middlewares=tinyauth - tinyauth.apps.it-tools.config.domain=it-tools.it-connectlab.fr - tinyauth.apps.it-tools.users.allow=adm_fb

Relancez les deux conteneurs… Puis, testez. Pour l’occasion, j’ai ajouté un second utilisateur nommé flo et qui, en principe, doit se voir l’accès refusé. Voici le résultat obtenu :

D’autres exemples sont précisés dans la documentation officielle.

VIII. Docker Compose Tinyauth - Exemple complet

Pour finir, voici la configuration complète avec l’authentification GitHub et la personnalisation de l’interface Tinyauth :

services: tinyauth: image: ghcr.io/steveiliop56/tinyauth:v4 container_name: tinyauth restart: unless-stopped networks: - frontend environment: - APP_URL=https://tinyauth.it-connectlab.fr - APP_TITLE=IT-Connect Lab - RESOURCES_DIR=/data/resources - BACKGROUND_IMAGE=/resources/wallpaper.jpg - USERS=${USERS} - SECRET=${SECRET} - PROVIDERS_GITHUB_CLIENT_ID=${PROVIDERS_GITHUB_CLIENT_ID} - PROVIDERS_GITHUB_CLIENT_SECRET=${PROVIDERS_GITHUB_CLIENT_SECRET} - OAUTH_WHITELIST=${OAUTH_WHITELIST} - LOG_LEVEL=debug volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - ./wallpaper.jpg:/data/resources/wallpaper.jpg:ro labels: - traefik.enable=true - traefik.http.routers.tinyauth.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth.entrypoints=web - traefik.http.routers.tinyauth-https.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth-https.entrypoints=websecure - traefik.http.routers.tinyauth-https.tls=true - traefik.http.routers.tinyauth-https.tls.certresolver=ovhcloud - traefik.http.services.tinyauth.loadbalancer.server.port=3000 - traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik networks: frontend: external: true

Ainsi que le fichier .env associé :

USERS=adm_fb:$2b$05$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.SECRET=2BBUv0YFcZRoWMndmG9kaI3US5QU7u6ZPROVIDERS_GITHUB_CLIENT_ID=Ov23liQVitconnectPROVIDERS_GITHUB_CLIENT_SECRET=e78bf94fb2ab4f16ditconnectitconnectOAUTH_WHITELIST=e-mail@it-connect.fr IX. Conclusion

À condition d’être un minimum à l’aise avec Docker, Tinyauth se présente comme une solution simple et efficace pour protéger n’importe quelle application par un portail d’authentification. L’association avec Traefik est très intéressante pour mettre en place une authentification centralisée.

Ce type d’architecture reste relativement simple à maintenir, tout en offrant un bon contrôle sur qui accède à quoi. Vous pouvez ensuite affiner les politiques d’accès, ajouter des groupes ou intégrer d’autres services, tout en conservant le même socle : Traefik en frontal, Tinyauth comme brique d’authentification partagée.

En complément de ce tutoriel, vous pouvez consulter la documentation de Tinyauth.

FAQ Qu’est-ce que Tinyauth et à quoi sert-il ?

Tinyauth est une solution légère permettant d’ajouter un portail d’authentification à une application web sans mettre en place une infrastructure complexe. C’est un outil open source codé majoritairement en Go et TypeScript.

Tinyauth est-il compatible avec toutes les applications web ?

Oui, dès lors que l’application peut être protégée derrière un reverse proxy ou une redirection HTTP/HTTPS. L’intégration avec Traefik est possible, mais ce n’est pas la seule possibilité. Certaines applications peuvent être plus difficiles à intégrer s’il y a des en-têtes spécifiques à gérer.

Tinyauth fonctionne-t-il avec Nginx ou Traefik ?

Oui. Nginx, Traefik et Caddy peuvent être configurés pour rediriger l’utilisateur vers Tinyauth avant d’accéder à l’application.

Comment activer HTTPS pour Tinyauth ?

On peut activer TLS en passant par Traefik ou Caddy, ou en configurant Nginx avec un certificat Let’s Encrypt. L’utilisation du HTTPS avec un certificat TLS est plus que recommandée puisqu’il est question d’authentification.

Peut-on personnaliser l’interface du portail Tinyauth ?

Oui, l’apparence peut être modifiée, notamment le titre de l’instance et le fond d’écran, grâce à deux variables d’environnement prévues à cet effet (APP_TITLE et BACKGROUND_IMAGE).

Est-il possible de connecter Tinyauth à un Active Directory ou un LDAP ?

Oui, la documentation de Tinyauth met en évidence la possibilité de connecter un annuaire LDAP pour l’authentification. Plusieurs champs sont proposés, comme l’adresse du serveur LDAP, le Bind DN, etc… C’est suffisant pour envisager une connexion AD.

Comment consulter les logs de Tinyauth ?

Si Tinyauth est déployé par l’intermédiaire d’un conteneur Docker, vous pouvez exécuter la commande docker compose logs -f --tail 100 depuis le répertoire du projet pour afficher les journaux en temps réel.

– Source :

https://www.it-connect.fr/tinyauth-traefik-ajoutez-un-portail-authentification-a-vos-applications-web/

I. Présentation

Dans un environnement Docker, certains services ont besoin d’un accès au socket de Docker pour fonctionner correctement, notamment pour consulter l’état des conteneurs Docker en cours d’exécution. Dans ce cas, on peut avoir tendance à aller au plus simple : exposer directement le socket Docker. Malheureusement, cette pratique ouvre la porte à un contrôle total du daemon Docker, et donc de l’ensemble de vos conteneurs. Se pose alors une question : comment exposer de manière sécurisée le Socket Docker ?

Dans ce tutoriel, nous allons voir comment utiliser un proxy pour accéder au socket de Docker pour apporter plus de sécurité aux échanges avec l’API Docker. Pour cela, nous allons utiliser l’image d’un projet nommé docker-socket-proxy qui s’appuie sur une image Alpine et HAProxy pour filtrer les accès à l’API Docker.

II. Exposer le socket de Docker : quels sont les risques ?

Le simple fait de monter docker.sock dans un conteneur lui donne un pouvoir total sur le démon Docker. En disant cela, je référence à ce type d’instruction que nous pouvons retrouver dans les fichiers Docker Compose :

volumes: - /var/run/docker.sock:/var/run/docker.sock

Concrètement, si un attaquant parvient à compromettre ce conteneur, il peut agir sur l’ensemble de votre environnement conteneurisé. Il peut envisager les actions suivantes :

Supprimer ou modifier n’importe quel conteneur. Créer de nouveaux conteneurs (ce qui lui permettrait d’injecter du code malveillant). Accéder à l’hôte Docker en lui-même dans le pire des cas.

Monter le socket de Docker en lecture seule ne permet pas de se prémunir contre une attaque potentielle : l’attaquant peut créer un conteneur Docker avec un shell au sein duquel il monte la racine du volume système, qui lui ouvrira la voie royale.

C’est précisément pour éviter ce scénario catastrophe que le proxy pour le socket Docker entre en jeu…

III. Le rôle du Docker Socket Proxy

Le Docker Socket Proxy joue un rôle d’intermédiaire entre vos applications et Docker. Ainsi, au lieu d’exposer directement docker.sock à vos conteneurs (et risquer le pire), ce proxy agit comme un filtre qui ne laisse passer que ce qui est strictement nécessaire et autorisé selon la configuration. C’est lui qui définit quelles actions sont autorisées.

Dans le cas du projet Docker Socket Proxy que nous allons utiliser, le principe est le suivant :

Par défaut, le proxy autorise les accès aux sections de l’API EVENTS, PING, VERSION. Tous les autres accès sont refusés par défaut : CONTAINERS, IMAGES, NETWORKS, VOLUMES, etc…

Vous souhaitez autoriser un accès dans votre proxy ? Vous devez l’autoriser explicitement avec une directive sous la forme suivante : CONTAINERS=1.

Au final, ce proxy est un moyen efficace de concilier praticité et sécurité, sans bouleverser l’architecture existante. Vous n’aurez qu’à effectuer quelques ajustements dans la configuration de vos conteneurs.

Note: la mise en place d’un proxy pour le socket Docker est un très bon moyen de réduire la surface d’attaque de votre système.

IV. Déployer un Docker Socket Proxy

Désormais, nous allons passer au déploiement de Docker Socket Proxy dans un conteneur Docker. Vous devez disposer d’une machine sur laquelle Docker est installé et vous y connecter.

Créez un dossier pour ce projet, puis enchainez sur la création du fichier Docker Compose :

mkdir /opt/docker-compose/docker-socket-proxynano /opt/docker-compose/docker-socket-proxy/docker-compose.yml

Voici le code utilisé pour déployer cette application :

services: docker-proxy: image: tecnativa/docker-socket-proxy:latest container_name: docker-socket-proxy restart: unless-stopped environment: - LOG_LEVEL=info - CONTAINERS=1 volumes: - /var/run/docker.sock:/var/run/docker.sock:ro networks: - frontend networks: frontend: external: true

Comme toujours, quelques explications s’imposent :

Ce conteneur s’appuie sur la dernière image du projet tecnativa/docker-socket-proxy Ce conteneur a accès au socket Docker en direct, via la directive sous volumes: (ce sera le seul à avoir cette ligne désormais). Le réseau auquel se connecte le conteneur se nomme frontend et il existe déjà, mais sinon, vous pouvez tout à fait le créer (ici, c’est dans un contexte avec Traefik). Ainsi, le proxy sera accessible par les autres conteneurs connectés à ce même réseau (qui est isolé). Ici, le port 2375 n’est pas directement exposé sur l’hôte Docker pour des raisons de sécurité. Néanmoins, c’est sur ce port que devront se connecter les autres conteneurs qui ont besoin de solliciter le proxy, mais via le réseau frontend directement, donc pas besoin de l’exposer.

Nous pouvons constater également la ligne précisée ci-dessous, dont l’objectif est de donner accès à l’endpoint /containers/ de l’API. Il y a un lien entre les variables d’environnement supportées par le proxy et les endpoints présents dans l’API de Docker (voir cette documentation).

CONTAINERS=1

Il est important de noter que par défaut, la méthode POST est désactivée ! C’est essentiel d’un point de vue sécurité, car cela signifie que tous les endpoints de l’API sont accessibles en lecture seule. Sinon, un accès à l’endpoint CONTAINERS pourrait, en principe, permettre de créer un conteneur, mais là ce n’est pas le cas.

Vous n’avez plus qu’à lancer la construction du projet :

docker compose up -d

La suite se passe du côté de vos applications.

V. Cas d’usage A. Utiliser le proxy Socket Docker avec Portainer

Pour commencer, nous allons voir comment configurer Portainer avec le Docker Socket Proxy. Pour rappel, Portainer est une application open source qui facilite l’administration des conteneurs Docker et des éléments associés : volumes, réseaux, images… De ce fait, l’application a besoin d’un ensemble de permissions.

Tout d’abord, dans le fichier Docker Compose de Portainer, vous devez supprimer la liaison avec le socket Docker :

volumes: - /var/run/docker.sock:/var/run/docker.sock

À la place, ajoutez une commande pour connecter Docker via le proxy (attention au nom du conteneur) :

command: -H tcp://docker-socket-proxy:2375# ou command: -H tcp://docker-socket-proxy:2375 --tlsskipverify

Ce qui donne le fichier docker-compose.yml suivant :

services: portainer: container_name: portainer image: portainer/portainer-ce:lts command: -H tcp://docker-socket-proxy:2375 restart: always volumes: - ./portainer_data:/data ports: - 9443:9443 networks: - frontend networks: frontend: external: true

Néanmoins, en l’état, cela ne fonctionnera pas car la configuration de notre proxy est trop restrictive. En effet, nous autorisons uniquement un accès en lecture seule aux conteneurs, ce qui n’est pas suffisant pour Portainer. Il doit pouvoir gérer le réseau, les images, les volumes, etc… Vous devez donc ajuster les permissions de votre proxy pour adopter cette configuration :

environment: - LOG_LEVEL=info - CONTAINERS=1 - INFO=1 - TASKS=1 - SERVICES=1 - NETWORKS=1 - VOLUMES=1 - IMAGES=1 - SYSTEM=0 - EXEC=0 - POST=1

L’instruction POST=1 est uniquement utile si vous souhaitez autoriser la création d’éléments via Portainer. Ainsi, nous autorisons les requêtes POST vers les endpoints de l’API qui sont autorisés, donc création / modification de ressources (démarrer/arrêter des conteneurs, créer des services, etc.). Si vous l’utilisez seulement pour de la lecture, ce n’est pas nécessaire d’ajouter cette instruction.

À l’inverse, nous bloquons l’exécution de docker exec via l’API grâce à l’instruction EXEC=0, donc c’est un bon point pour la sécurité. L’idée ici étant de trouver un bon compromis entre sécurité et fonctionnement de Portainer. Nous bloquons aussi les accès sur l’endpoint système avec SYSTEM=0.

Note: rien ne vous empêche de déployer un proxy socket spécifique pour Portainer afin de ne pas ouvrir les permissions pour tous les conteneurs.

Vous pouvez modifier les permissions du proxy à tout moment. Ensuite, en consultant les journaux, vous verrez quelles sont les requêtes autorisées ou refusées en regardant les codes HTTP.

docker logs docker-socket-proxy # Exemples :dockerfrontend dockerbackend/dockersocket 0/0/0/2/2 200 9298 - - ---- 2/2/0/0/0 0/0 "GET /v1.51/images/json HTTP/1.1"dockerfrontend/<NOSRV> 0/-1/-1/-1/0 403 192 - - PR-- 2/2/0/0/0 0/0 "GET /v1.41/info HTTP/1.1"

Portainer pourra ensuite se connecter à votre instance Docker par l’intermédiaire de notre proxy (en mode API).

B. Utiliser le proxy Socket Docker avec Traefik

Cette section explique comment utiliser le proxy Socket Docker avec le reverse proxy Traefik. C’est un très bon exemple, car Traefik est souvent couplé avec Docker et il a un accès aux conteneurs Docker, notamment pour lire les informations sur les labels. Ainsi, un accès en lecture seule sur les conteneurs lui suffit pour fonctionner ! Soit la configuration suivante dans le proxy :

environment: - LOG_LEVEL=info - CONTAINERS=1

Dans le fichier Docker Compose de Traefik, il convient donc de supprimer cette ligne :

volumes: - /var/run/docker.sock:/var/run/docker.sock

Puis, dans le fichier de configuration⁣ traefik.yml, le fournisseur Docker doit être modifié. En principe, vous avez l’instruction endpoint: "unix:///var/run/docker.sock" qui donne un accès direct au socket Docker grâce au volume.

Celle-ci doit être remplacée par une connexion TCP vers le conteneur du proxy sur le port 2375. Ce qui donne :

providers: docker: #endpoint: "unix:///var/run/docker.sock" endpoint: "tcp://docker-socket-proxy:2375" exposedByDefault: false

Une fois l’opération arrêtée, vous devez relancer la construction du conteneur Traefik avec cette nouvelle configuration. Voilà, votre reverse proxy Traefik fonctionne normalement, et en plus, l’accès aux conteneurs est sécurisé.

VI. Conclusion

L’utilisation d’un proxy pour exposer le Socket de Docker est une bonne manière de filtrer les accès entre vos applications et l’API de Docker. Rien ne vous oblige à le faire, mais c’est un plus pour réduire la surface d’attaque de votre hôte Docker, dans le cas où vous utilisez des applications qui “se connectent” au socket Docker.

FAQ Pourquoi le socket Docker représente-t-il un risque de sécurité ?

Le socket Docker donne un accès direct au Docker Daemon, c’est-à-dire au moteur Docker en lui-même. Tout conteneur ou application ayant accès à docker.sock sans contrôle peut créer, modifier ou supprimer des conteneurs, accéder aux volumes, manipuler les réseaux et potentiellement compromettre l’hôte en lui-même.

Quel est le rôle du Docker Socket Proxy ?

Le Docker Socket Proxy agit comme un intermédiaire sécurisé (rôle de base du proxy) entre les conteneurs et le démon Docker. Il permet de définir précisément quelles actions sont autorisées (lecture des informations des conteneurs, création de conteneurs, gestion des images, etc.). Cela évite d’exposer le socket brut et réduit considérablement les risques d’escalade : la surface d’attaque est maîtrisée.

Le Docker Socket Proxy fonctionne-t-il avec Docker Swarm ?

Oui. Il peut limiter les permissions liées à Docker Swarm. Cela implique d’ajuster la configuration du proxy pour autoriser les endpoints nécessaires (SERVICES, TASKS, NETWORKS, etc.).

Le Docker Socket Proxy est-il adapté pour un usage en production ?

Oui, à condition de configurer précisément les endpoints autorisés : des tests approfondis peuvent s’avérer nécessaires pour bien identifier les besoins de certaines applications. Le Docker Socket Proxy permet de respecter un principe de moindre privilège, essentiel dans une architecture Docker en production.

– Source :

https://www.it-connect.fr/docker-comment-ameliorer-la-securite-avec-un-docker-socket-proxy/

Alternative intéressante. Il faut reconnaître que la gestion Portainer sur smartphone est une vraie tannée, il faut zoomer pour cliquer au bon endroit, puis dézoomer pour voir plus large…
Ce qui pourrait m’empêcher de basculer, outre le problème des droits que tu mentionnes, c’est la confiance. En effet, ce type d’app nécessite un accès étendu au socket Docker, droit sensible que je n’accorde sur sur des outils répandus, reconnus et donc supposés fiables. C’est le cas pour Portainer, est-ce aussi le cas pour Arcane ?

Hello ! Donc ça y est Xthor c’est définitif … je n’avais que lui pour mes torrents, merci à Zlatan pour sa longévité … rip Xthor

Je ne sais pas vraiment, je n’ai pas trop suivi

La Commission européenne franchit une nouvelle étape dans sa quête de souveraineté numérique. Selon une consultation publique lancée ce mardi 6 janvier 2026, Bruxelles entend désormais favoriser la commercialisation des logiciels open source développés sur le Vieux Continent. L’objectif est clair : ne plus se contenter de financer la recherche, mais transformer ces projets en alternatives commerciales crédibles face aux géants technologiques américains.

Le constat de l’Europe est lucide : jusqu’à présent, une grande partie de la valeur générée par les projets open source européens est exploitée en dehors de l’UE, profitant souvent aux grandes plateformes propriétaires qui intègrent ces briques libres dans leurs propres services payants.

Pour corriger ce déséquilibre, la nouvelle stratégie de la Commission se concentrera sur quatre piliers :

la montée en puissance des communautés locales de développeurs ; le déploiement industriel et l’intégration profonde au marché ; la viabilité commerciale des innovations, afin qu’elles ne dépendent plus uniquement de subventions ; la sécurité des chaînes d’approvisionnement, pour garantir une confiance totale des acteurs publics et privés. Remplacer les piles propriétaires coûteuses

L’exécutif européen espère ainsi remplacer les « piles propriétaires les plus coûteuses ou les plus gourmandes en données » par des solutions souveraines. Cette initiative s’inscrit dans un calendrier législatif dense, puisque cette stratégie sera publiée en parallèle du Cloud and AI Development Act (CAIDA), attendu pour le premier trimestre 2026.

Bruxelles n’avance pas seule. Le document mentionne notamment le rôle du Consortium européen pour les infrastructures numériques communes, où la France, l’Allemagne, l’Italie et les Pays-Bas collaborent déjà sur des technologies ouvertes pour leurs administrations. Cette dynamique fait directement écho au lancement de l’EuroStack Foundation en novembre 2025, qui vise précisément à construire une infrastructure numérique européenne indépendante et interopérable.

Un appel aux acteurs du secteur

La Commission souhaite également garantir la pérennité financière des organisations open source via des partenariats avec le secteur public. Le programme de financement « Next Generation Internet » a d’ailleurs été rebaptisé « Open Internet Stack » l’an dernier, marquant cette volonté d’orienter les projets vers des modèles économiques viables.

Les entreprises, développeurs et citoyens ont désormais jusqu’au 3 février 2026 pour soumettre leurs avis sur cette consultation. C’est une occasion unique pour l’écosystème du logiciel libre de peser sur la future politique industrielle de l’Union.

– Source :

https://goodtech.info/commission-europeenne-strategie-open-source-souverainete-2026/

C’est une histoire qui ferait passer Indiana Jones pour un simple amateur de brocantes. Alors que le personnel de la Kahlert School of Computing de l’Université de l’Utah rangeait un local de stockage en juillet 2025, une petite boîte a attiré l’attention d’Aleksander Maricq. À l’intérieur : une bande magnétique portant la mention manuscrite « UNIX Original from Bell Labs v4 ».

Ce que l’équipe vient de mettre au jour n’est rien de moins que la seule copie complète connue au monde d’UNIX v4, datant de novembre 1973. Une relique d’une époque où l’informatique n’était pas encore une industrie de masse, mais une aventure de pionniers.

Pourquoi UNIX v4 change tout (même en 2026)

Pour comprendre l’excitation qui secoue la communauté, il faut remonter aux années 70. À l’époque, les systèmes d’exploitation étaient écrits en « assembleur », un langage ultra-complexe et propre à une seule machine. Si vous changiez d’ordinateur, il fallait tout réécrire.

UNIX v4 est la première version dont le noyau a été écrit en langage C. C’est ce choix technique, révolutionnaire pour l’époque, qui a rendu UNIX (et plus tard Linux, macOS ou BSD) portable sur n’importe quel matériel. Sans cette bande de 1973, notre monde numérique n’aurait pas la même allure : le C est devenu la langue universelle du code, le fondement de la cybersécurité et de l’architecture logicielle moderne.

Le sauvetage : une course contre le temps et la démagnétisation

Récupérer des données sur une bande de 52 ans est un défi physique. Les particules magnétiques s’effacent, le support devient friable. La bande a été confiée au Computer History Museum, où Al Kossow et Len Shustek ont utilisé un lecteur de bande modifié et des logiciels de reconstruction de flux magnétique pour extraire l’image numérique.

Le résultat est miraculeux : sur l’ensemble de la bande, seuls deux blocs de données n’ont pu être lus correctement, mais ils ont pu être reconstruits. Le noyau complet, une merveille de minimalisme, ne pèse que 27 kilo-octets. À titre de comparaison, une simple icône sur votre bureau aujourd’hui est souvent plus lourde que tout le cœur du système de 1973.

L’expérience UNIX v4 : l’informatique à l’état brut

Grâce à cette récupération, le développeur Mitch Riedstra a mis en ligne un émulateur permettant de tester ce monument de l’histoire directement dans votre navigateur. Mais attention, l’expérience est austère :

pas de souris, pas de fenêtres, juste un terminal noir ; pour changer de dossier, on ne tape pas cd mais chdir ; pour effacer un caractère, on utilise la touche # et pour supprimer une ligne entière, le caractère @.

C’est une informatique « physique », où le système traite l’écran comme un rouleau de papier continu. C’est frustrant, c’est brut, mais c’est le point de départ de tout ce que nous considérons aujourd’hui comme acquis.

Un bien commun pour l’humanité

Le contenu de la bande a été déposé sur Internet Archive, garantissant que cette pièce d’histoire ne sera plus jamais perdue. Il est fascinant de noter qu’UNIX v4 avait été libéré sous licence BSD par Caldera en 2002, mais il nous manquait le code complet pour le faire revivre.

Cette découverte nous rappelle que derrière nos interfaces lisses et nos IA génératives se cachent des décennies de réflexion sur la structure même de l’information. En 1973, dans les bureaux des Bell Labs, Ken Thompson et Dennis Ritchie ne créaient pas seulement un outil pour le mini-ordinateur PDP-11/45, ils forgeaient les clés de notre liberté numérique future.

– Source :

https://goodtech.info/unix-v4-decouverte-bande-magnetique-preservation-2026/

@Aerya a dit dans Bose libère l'API de ses enceintes SoundTouch avant leur fin de vie :

C’était la question à l’annonce de la fin de support produit. C’est plutôt intelligent comme fin et respectueux du consommateur.

Oui, je trouve aussi.
C’est transparent et on va pouvoir même bien en profiter.

Perso j’utilisais rien du Cloud avec l’app

Ça m’a fait marrer aussi