1 line
29 KiB
JSON
1 line
29 KiB
JSON
[{"uuid":"cfe738e9-7ac2-4c7e-9205-dab4957835c6","slug":"preparation-du-raspberry-pi","title":"Décoder les infos de la TIC et les communiquer","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-19 06:48","created_at":"2025-11-19 06:48:01","updated_at":"2026-05-12 17:38:19","tags":[],"plain":"Choix du Raspberry Pi\r\n\r\nL'objectif est de récupérer automatiquement et à intervalles réguliers les informations émises par un compteur Linky, puis de les rendre accessibles depuis l'extérieur du Raspberry Pi.\r\n\r\nTrois prérequis matériels s'imposent donc :\r\nune connexion réseau, pour exposer ou transmettre les données collectées ;\r\nun espace de stockage, suffisant pour l'OS, les outils et l'historique des relevés ;\r\nune liaison série, pour dialoguer avec la sortie TIC du compteur.\r\n\r\nLe choix s'est porté sur un Raspberry Pi 3, qui couvre ces trois besoins sans surcoût ni complexité supplémentaire. Le stockage est assuré par une carte SD, la liaison série est exposée sur le port GPIO, et la connectivité réseau bénéficie d'un atout pratique : l'armoire de brassage de la maison se trouve à quelques mètres du compteur électrique, ce qui permet d'envisager un raccordement filaire fiable plutôt qu'un lien sans fil.\r\n\r\nCôté logiciel, le système retenu est Raspberry Pi OS (anciennement Raspbian), recommandé par défaut sur cette plateforme. Cette distribution dérivée de Debian apporte tout l'écosystème GNU/Linux nécessaire : pile réseau TCP/IP, accès distant par SSH, synchronisation horaire NTP, gestion de bases de données, serveur web, interpréteurs PHP et Python. Autant de briques qui serviront aux étapes ultérieures du projet.\r\n\r\nCâblage\r\n\r\nLe compteur Linky émet la trame TIC sous forme d'un signal modulé en ASK (Amplitude Shift Keying). Ce signal n'est pas directement exploitable par l'UART du Raspberry Pi, qui attend un niveau logique TTL stable.\r\n\r\nUn démodulateur ASK est donc intercalé entre le compteur et le Raspberry Pi. Son rôle est de récupérer la porteuse modulée et de restituer en sortie un signal binaire TTL propre, directement lisible par le port série.\r\n\r\nLa chaîne complète est la suivante :\r\n\r\n\r\n\r\nLe câblage côté Raspberry Pi se résume à trois fils :\r\nBroche | Signal | Rôle |\r\n---|---|---|\r\nPin 1 | 3V3 | Alimentation du démodulateur |\r\nPin 6 | GND | Masse commune |\r\nPin 10 | RX (GPIO15) | Lecture de la sortie TTL du démodulateur |\r\n\r\nSchéma de câblage\r\n\r\n\r\n\r\nInstallation de l'OS\r\n\r\nLe déploiement de Raspberry Pi OS sur la carte SD suit la procédure standard décrite dans l'article [à compléter]. Un point d'attention : activer le service SSH dès la préparation de l'image, faute de quoi aucun accès distant ne sera possible au premier démarrage.\r\n\r\nUne fois le Raspberry Pi mis sous tension et raccordé au réseau, son adresse IP n'est pas connue à l'avance. Un balayage du réseau local avec permet de l'identifier :\r\nNote : la cible passée à est l'adresse du réseau (), pas celle de la passerelle. Le indique le masque de sous-réseau et délimite la plage scannée.\r\n\r\nUne fois l'adresse repérée, la connexion s'établit avec le compte et le mot de passe par défaut :\r\nPremier réflexe sécurité : changer immédiatement le mot de passe du compte avec , voire désactiver ce compte au profit d'un utilisateur dédié. Les identifiants par défaut sont connus de tous les scans automatisés."},{"uuid":"5ec98b44-5158-4c69-9593-934d470a2f21","slug":"le-bornier-teleinformation-d-un-compteur","title":"Le bornier téléinfo","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-01-01 16:13:08","created_at":"2021-01-01 16:13:08","updated_at":"2021-01-01 16:13:08","tags":[],"plain":"En France, c'est à la suite à l’arrêté du 6 janvier 1987 relatif à la construction et à l’approbation de types de compteurs d’énergie électrique, fondés sur un principe électronique, qu'est apparu les compteurs électroniques. Il permettait la réception et l'interprétation des ordres de télécommande centralisée 175 Hz de réseau de distribution, mais cela ne nous intéresse pas dans ce dossier. La partie intéressante de ces nouveaux compteurs est l'aide à la gestion de la consommation d'énergie, au moyen d'une liaison série de télé-information client sur laquelle le compteur envoie en permanence ses données internes. La télé-information du client est réalisée par une liaison série (modulée en ASK à 50 kHz) qui diffuse en permanence les informations contenues dans les mémoires du compteur. Les informations qui sont transmises sur une ligne bifilaire avec écran peuvent être utilisées par un dispositif de gestion de l’énergie. Les bornes de cette liaison sont isolées galvaniquement des circuits internes du compteur.\nCette liaison doit être configurée (en programmation locale) :\nmode TELEIN : trames de télé-information transmises\nmode METROL : émission d’impulsions métrologiques\nmode VEILLE : trames réduites à l’émission de numéro de série. Après démodulation, on retrouve une liaison asynchrone classique :\n vitesse de transmission : 1200 bits/s\n parité paire\n 7 bits par caractère\n 1 stop bit. Le Raspberry Pi va se connecter à la sortie Téléinfo du compteur. Ce bornier est identifié I1 et I2. Ce bornier est disponible sur les compteurs suivants :\ncompteur électronique de marques SAGEM, Landis+Gyr.\ncompteur intelligent Linky de marques Sagemcom, Landis+Gyr et Itron. Les caractéristiques physiques du câble à utiliser entre le RasbperryPi et la sortie télé-information du compteur sont celles d’un câble téléphonique intérieur de type suivant: \npaire torsadée simple avec écran (aluminium) et conducteur de drain,\nconducteurs monobrins en cuivre étamé de diamètre compris entre 0,5 mm et 0,6 mm,\nisolant PVC. En utilisation, la longueur du bus mis en œuvre doit est inférieure ou égale à 500m (en topologie quelconque). Ce qui n'oblige pas à disposer le RasbperryPi à proximité du compteur. biblio : http://www.erdf.fr/sites/default/files/ERDF-NOI-CPT_02E.pdf"},{"uuid":"2396f42f-4c5a-4cf1-a6b4-215d20bb471d","slug":"iot-principes-et-inconvenients","title":"iOT, principes et inconvenients","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:32","created_at":"2023-02-10 22:48:32","updated_at":"2023-02-10 22:48:32","tags":[],"plain":"Cet article a été repris dans un épisode du podcast mindCast mindCast Info n°12 Les Français ne sont pas emballés par les objets connectés.\\\\\n32 % d'entre eux jugent l’installation d’objets connectés « complexe » et 19 % « énervante », selon le baromètre Boulanger/Ifop On va voir pourquoi. 5 principes de fonctionnement\nUn objet connecté repose sur 5 principes : 1. Un espace de stockage facilement accessible\nPour pouvoir déposer et consulter des informations, il fallait un système qui puisse être accessible depuis n'importe quel réseau. Un espace de stockage qui puisse répondre aux exigences de l'hétérogénéité des médias de communications. Les serveurs hébergés dans des datacenter permettent de répondre à cette problématique. Cela fait partie du Cloud. 2. Un support de communication en or\nLe support de communication, jusqu'à dans les années 90, reposait essentiellement sur des solutions câblées : bus RS485, bus CAN... et également du sans fils grâce aux fréquences réservés aux usages du grand public : 900 MHz, 2,4 GHz (2400 MHz) et 5,8 GHz (5800 MHz) Les réseaux sans fils : 4G, 5G, SigFox, Lora, Wifi, bluetooth LE, Z-Wave, ZigBee, et Enocean... apparus depuis les années 2000 ont permis d'ajouter les moyens d'interconnecter plus facilment les iOT. Des standards se profilent. Des notions plus compréhensibles du grand public. Ces notions sont apparues avec l’introduction des technologies utilisées couramment (ordinateurs, assistants personnels...) Petite aparté, la fréquence 900 MHz est réservée en France à la radiotéléphonie. Donc, son usage n'est pas autorisée. C'est également cette fréquence qui est utilisée pour le support de communication Z-Wave.\\\\\nJe vous invite à consulter la page WikiPédia sur l'[utilisation de la bandes des 900 MHz] 3. Un logiciel adapté à l'iOT\n Vous avez une sonnette Somfy, n'hesitez pas utiliser le programme Somfy. Vous avez une station météo Netatmo, un programme netatmo, une sonde pour vos plantes, utilisez GreenBox, MEG, Flower Power de chez Parrot, Koubachi... 4. Des informations compréhensibles par tous\nAfin d'en facilité l'exploitation par des humains, les ordinateurs :\n1. récupèrent les données depuis les espaces de stockage,\n1. compilent les informations sur des calculateurs et \n1. mettent en forme ces informations pour qu'elles soient plus attrayantes et facilement interprétables. La compilation des informations s'appelle le Data Analyitics / l'analyse de données. Les data scientists, les personnes réalisant les programmes d'analyse, exploitent vos données pour pouvoir en interpréter une notion facilement compréhensible. 5. Des informations accessibles par tous moyens\nDes interfaces idéales pour l’exploitation des iOT : smartphone, tablette ou écrans dédiés. L'interface pour les iOT permet à l'utilisateur d'interagir avec le système et s'adapter au support utilisé.\\\\\nElle permet, entre autres, l'affichage d'informations calculées depuis les données relevés des différents iOT, de manières compréhensible. Inconvénients\n1. Fuite de données en dehors de votre bulle privée. Le stockage s'effectue sur le cloud. 2. Les fréquences exploitées sont également utilisées pour d'autres usages. Wifi, Micro-onde, objets télécommandés.. et peuvent perturber le fonctionnement des iOT 3. Trop de logiciels pour l'utilisation de ces différents capteurs. De manière simplicité, il ne faudrait utiliser une série d'objet connectée que d'un seul fabricant. A écouter les fabricants, il suffit d’utiliser leur programme pour se simplifier la vie. Pas simple. 4. L'analyse des données s'effectuent en dehors de la bulle privée. Conclusion\nVie privée mise en danger, complexité due à la multiplication des acteurs que ne s'accordent pas sur un standard. Et je ne vous ai pas parlé de protocole de communication logiciel et de sécurité des communications. On n'a pas tous la fibre d'un informaticien, d'un électronicien ou d'un spécialiste de la sécurité, mais pourtant le sujet mérite toute notre attention sur ces problématiques. Concernant le DoIt Yourself (faites le vous même), c'est une autre histoire. Beaucoup plus technique et plus orientée pour les électroniciens et informaticiens chevronnés, le DIY est une solution qui me séduit. Mais c'est une histoire que je reprendrais au retour des vacances avec le coupeur de veille. Malheureusement, concernant les IoT, je n'ai pas de solution pour pouvoir aborder les sereinement. Il y a bien des tentatives de simplification avec Jeedom, HomeLive, Vera, Zipato, eedomus ou Home Center, mais on voit que ça part encore dans tous les sens et on reste sur notre faim. Liens & Bibliographie\nUnion internationale des télécommunications (ITU), L'internet des objets connectés Présentation de Sami TABBANE (ITU), Présentation de Sami TABBANE (ITU), Présentation de Frédéric Camps (LAAS/CNRS), Présentation de Martha Zemede, Keysight Technologies,"},{"uuid":"4cf880e6-e4e0-42dd-aae2-675837850b83","slug":"compromission-de-jdownloader-6-7-mai-2026-analyse-indicateurs-et-procedure-de-detection","title":"JDownloader : quand le CMS devient la faille","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.webp","published":true,"published_at":"2026-05-12 17:09","created_at":"2026-05-12 17:10:36","updated_at":"2026-05-12 17:21:01","tags":[],"plain":"À propos de l'incident de sécurité affectant le site officiel jdownloader.org les 6 et 7 mai 2026.\r\n\r\nJDownloader expliqué simplement\r\n\r\nJDownloader est un gestionnaire de téléchargements écrit en Java, distribué gratuitement par l'éditeur allemand AppWork GmbH depuis plus de quinze ans. Il sert essentiellement à automatiser la récupération de fichiers depuis des hébergeurs (Mega, Uptobox, Rapidgator…), des plateformes vidéo et des services de liens premium. Côté utilisateur, c'est l'outil qu'on lance pour récupérer une série de fichiers en une opération, plutôt que cliquer sur cent liens un par un. L'application est multiplateforme — Windows, Linux, macOS — et tourne sur quelques millions de postes dans le monde.\r\n\r\nLe projet est distribué de plusieurs façons : un JAR principal (le binaire Java pur), des installateurs natifs par OS depuis le site officiel, et des paquets passant par des canaux distribués comme Flatpak, Snap ou Winget. C'est cette diversité de canaux qui va jouer un rôle central dans ce qui suit.\r\n\r\nL'incident : ce qui s'est passé\r\n\r\nEntre le 6 mai 2026 à 00 h 01 UTC et le 7 mai 2026 à 17 h 06 UTC, le site officiel a distribué des installateurs piégés à la place des binaires légitimes. La fenêtre n'a duré qu'environ 48 heures, et seuls deux liens ont été affectés. Mais pendant cette fenêtre, tout utilisateur qui passait par le bon parcours téléchargeait un cheval de Troie au lieu d'un gestionnaire de téléchargements.\r\n\r\nLe scénario reconstitué par l'équipe d'AppWork et les chercheurs en sécurité (BleepingComputer, Thomas Klemenc, équipe Rescana) se déroule en quatre temps.\r\n\r\n1. Compromission du CMS du site. Les attaquants ont exploité une vulnérabilité non corrigée dans le système de gestion de contenu de , qui permettait de modifier les listes de contrôle d'accès et le contenu publié sans authentification. Point crucial : ils n'ont pas eu accès au serveur sous-jacent, ni au système de fichiers, ni à l'infrastructure de build. Juste au contenu web — et ça a suffi.\r\n\r\n2. Réécriture de deux liens. Plutôt que de tenter de modifier les binaires originaux (qui étaient hors de leur portée), les attaquants ont fait beaucoup plus simple : ils ont changé l'URL cible de deux liens publics sur la page de téléchargement. Le lien « Download Alternative Installer » pour Windows et le script shell pour Linux pointaient désormais vers des fichiers malveillants hébergés sur une infrastructure tierce. Le HTML autour, lui, restait identique. Visuellement, rien ne distinguait la page propre de la page piégée.\r\n\r\n3. Charges utiles différenciées par plateforme. Sur Windows, l'installateur piégé agit comme un loader qui déploie un RAT (Remote Access Trojan) écrit en Python, fortement obfusqué, communiquant avec deux serveurs de commande et contrôle ( et ). Le RAT est modulaire : il reçoit du code Python depuis le C2 et l'exécute, ce qui donne aux attaquants une porte ouverte indéfiniment extensible. Sur Linux, le script shell modifié télécharge une archive depuis , déguisée en fichier SVG, dont il extrait deux binaires ELF — et . Le second est installé en SUID-root dans , le premier est copié dans , et la persistance est assurée par un script déposé dans . Le malware se lance ensuite déguisé en , un nom de processus qui existe légitimement sur la plupart des distributions.\r\n\r\n4. Détection par la communauté. L'alerte n'est pas venue d'un système de surveillance, mais d'un utilisateur Reddit (PrinceOfNightSky) qui a remarqué que Microsoft Defender bloquait son installateur fraîchement téléchargé. La signature numérique indiquait « Zipline LLC » au lieu de « AppWork GmbH ». L'équipe AppWork a confirmé, mis le site hors ligne pour investigation dans les heures qui ont suivi, puis publié un rapport d'incident détaillé. Le site est revenu en ligne dans la nuit du 8 au 9 mai avec des liens vérifiés.\r\n\r\nPourquoi c'est systémique\r\n\r\nÀ première vue, c'est un incident isolé : une faille CMS, une équipe qui patche, le service revient. Vu de loin, ça ressemble à un mauvais quart d'heure. Mais en prenant un peu de recul, le schéma est troublant.\r\n\r\nCPUID, début avril 2026. Le site officiel de l'éditeur de CPU-Z est compromis, des installateurs piégés sont distribués pendant plusieurs jours.\r\n\r\nDAEMON Tools, début mai 2026. Même schéma : compromission du site officiel, substitution d'installateurs, plusieurs versions infectées (12.5.0.2421 à 12.5.0.2434) distribuées avant détection.\r\n\r\nJDownloader, 6–7 mai 2026. Toujours le même schéma.\r\n\r\nTrois compromissions d'éditeurs logiciels en cinq semaines, exactement sur le même schéma : pas d'intrusion dans l'infrastructure de build, pas de modification du code source, pas de vol de certificat de signature de l'éditeur. À chaque fois, le maillon faible est le CMS qui sert la page de téléchargement. Ce qu'on attaque, ce n'est pas le logiciel ; c'est le panneau publicitaire qui pointe vers le logiciel.\r\n\r\nCette mécanique est intéressante parce qu'elle déjoue à peu près toutes les défenses « modernes » de la chaîne d'approvisionnement.\r\n\r\nLa signature de code ne protège pas. Le binaire légitime de JDownloader est toujours signé proprement par AppWork GmbH. Mais le binaire malveillant servi à sa place est signé, lui aussi — par un autre éditeur (Zipline LLC, The Water Team), avec des certificats vraisemblablement volés ou achetés au marché noir. La signature certifie que le fichier vient bien de celui qui l'a signé ; elle ne certifie pas que c'est le bon fichier.\r\n\r\nLe HTTPS ne protège pas. La page de téléchargement est servie en HTTPS valide, depuis le bon domaine, avec le bon certificat. Le navigateur n'a aucune raison de tiquer.\r\n\r\nLes mises à jour in-app sont, elles, protégées. AppWork le souligne : chaque mise à jour livrée par le mécanisme intégré de JDownloader est signée RSA et vérifiée cryptographiquement, indépendamment du site web. Ce canal n'a pas été touché. C'est tout le paradoxe : les utilisateurs qui mettaient à jour JDownloader depuis l'application elle-même n'ont rien risqué ; ceux qui sont allés sur le site officiel pour le télécharger « proprement » sont les seuls exposés.\r\n\r\nLes paquets distribués sont protégés. Flatpak, Snap, Winget, le JAR principal — tout ce qui passe par une chaîne d'approvisionnement où l'intégrité est vérifiée par checksum hors site est resté propre. AppWork le résume sans détour : « Winget/Flatpak/Snap infra is outside of our reach — files downloaded by those are hosted on other infra and secured by sha256 checksums that are unchanged. »\r\n\r\nAutrement dit, plus le canal est court et naïf, plus il est vulnérable. Le téléchargement direct depuis un site web est le canal le plus naïf qui soit : on fait confiance au CMS, point. Tout l'effort de sécurisation de l'écosystème logiciel — signatures, builds reproductibles, SBOMs, attestations de provenance — porte sur la chaîne de production et la chaîne de distribution centralisée. Le maillon « page HTML qui dit clique ici », lui, est resté tel qu'il était en 2005.\r\n\r\nComment vérifier si on est touché\r\n\r\nLa fenêtre est étroite, donc le filtrage est simple. Trois questions, dans l'ordre :\r\n\r\n1. L'installateur a-t-il été récupéré entre le 6 mai 2026 (00 h 01 UTC) et le 7 mai 2026 (17 h 06 UTC) ?\r\n2. S'agit-il du lien « Download Alternative Installer » Windows ou du script shell Linux depuis ?\r\n3. Le fichier a-t-il été exécuté ?\r\n\r\nTrois oui → traiter la machine comme compromise. N'importe quel non dans la liste → aucun risque lié à cet incident. Une installation pré-existante mise à jour automatiquement, un paquet Flatpak/Snap/Winget, le JAR, la version macOS : rien à craindre.\r\n\r\nSous Windows\r\n\r\nLe contrôle de référence, c'est la signature numérique. Clic droit sur l'installateur → Propriétés → onglet Signatures numériques. La valeur attendue est . Toute autre signature (notamment Zipline LLC ou The Water Team), ou l'absence de signature, désigne un fichier malveillant.\r\n\r\nEn PowerShell :\r\n\r\n\r\n\r\nSi n'est pas ou si le certificat ne contient pas , ne pas exécuter.\r\n\r\nSous Linux\r\n\r\nTrois artefacts sont à chercher en post-exécution :\r\n\r\n\r\n\r\nL'apparition de l'un de ces trois éléments suffit à confirmer l'infection. Pour aller plus loin, un coup d'œil au trafic sortant vers les trois domaines C2 (, , ) dans les logs DNS ou via permet de confirmer l'activité du malware.\r\n\r\nSi le script installateur traîne encore quelque part, sa signature est sans ambiguïté : taille de 7 934 496 octets, SHA-256 commençant par .\r\n\r\nEn cas de compromission confirmée\r\n\r\nLa position officielle d'AppWork est sans nuance : réinstallation complète du système. Un RAT modulaire avec persistance SUID-root et exécution arbitraire de code Python depuis un C2 n'est pas quelque chose qu'on retire avec un antivirus. Il faut considérer que tout secret qui a transité sur la machine est compromis — mots de passe saisis au clavier, clés SSH, jetons API, cookies de session, configurations cloud — et les faire tous tourner après réinstallation, depuis une autre machine saine.\r\n\r\nCe que ça change pour qui s'auto-héberge\r\n\r\nL'incident JDownloader est un exemple éclairant pour qui exploite ses propres services exposés sur Internet — un Forgejo, un reverse proxy, un site personnel. La leçon n'est pas vraiment côté utilisateur (la procédure de détection plus haut suffit), elle est côté opérateur.\r\n\r\nLe CMS de JDownloader n'a probablement pas été ciblé pour ses qualités intrinsèques. C'est un dommage collatéral d'un schéma plus large : tout site qui distribue un binaire avec un nombre significatif d'utilisateurs devient une cible rentable, et le CMS public est souvent la pièce la moins surveillée du dispositif. On sécurise le serveur Git, le pipeline de build, la signature des paquets — et on laisse tourner un CMS qui n'a pas été patché depuis huit mois parce qu'il « ne sert qu'à afficher la page d'accueil ».\r\n\r\nQuelques principes opérationnels qui en découlent.\r\n\r\nSéparer le canal de publication du canal de vérification. AppWork a eu raison sur un point essentiel : leurs mises à jour in-app passent par une infrastructure indépendante du site web, avec signature RSA vérifiée côté client. Quand on auto-héberge, ça se traduit par : ne jamais utiliser le même serveur pour distribuer un binaire et publier son empreinte. Le checksum doit vivre ailleurs — dans un dépôt Git séparé, sur un domaine différent, idéalement sur une infrastructure qu'on n'administre pas soi-même.\r\n\r\nSurveiller la dérive du contenu publié. Une simple vérification quotidienne du hash des pages publiques (un cron qui calcule le SHA-256 des URL critiques et alerte en cas de changement non planifié) aurait détecté la compromission de JDownloader en moins d'une heure. C'est le genre de surveillance qu'aucune solution commerciale ne propose nativement, et qui s'écrit en quinze lignes de bash.\r\n\r\nPatcher le CMS avec la même rigueur que l'OS. L'automatisation des mises à jour applicatives reste sous-investie, surtout pour les outils « périphériques » (CMS, wiki, formulaire de contact). Une mise à jour automatique de niveau correctif n'est pas plus risquée qu'une mise à jour du noyau, et elle évite ce type de scénario.\r\n\r\nAuditer les ACL régulièrement. La faille exploitée ici permettait de modifier les ACL sans authentification. C'est l'équivalent CMS d'un répertoire dans un coin du système. Un audit périodique des permissions sur les pages publiques fait partie du minimum syndical pour un service exposé.\r\n\r\nEn résumé\r\n\r\nJDownloader n'a pas été cassé. Son code source est intact, son infrastructure de build est intacte, ses paquets officiels distribués via Flatpak ou Snap sont intacts, ses mises à jour internes sont intactes. Ce qui a été cassé, c'est le panneau qui dit où aller chercher le binaire.\r\n\r\nC'est une mécanique élégante du point de vue de l'attaquant, et inquiétante du point de vue de l'opérateur. Elle illustre quelque chose que l'incident NPM avait déjà mis en lumière dans un autre registre : la chaîne d'approvisionnement logicielle n'est pas une chaîne, c'est un réseau, et les points faibles ne sont jamais là où on les attend. On peut investir massivement dans la sécurité du code, du build et de la signature ; si la page web qui sert le lien reste un Wordpress non patché derrière un nom de domaine prestigieux, tout cet investissement passe à côté.\r\n\r\nLe rôle de l'opérateur en 2026, ce n'est plus de protéger le code. C'est de protéger chaque maillon qui sert à dire au monde où trouver le code — et de partir du principe que ce maillon-là sera le prochain à céder.\r\n\r\nLiens & sources\r\n\r\nJDownloader site hacked to replace installers with Python RAT malware | BleepingComputer\r\n\r\nRapport d'incident officiel | jdownloader.org\r\n\r\nJDownloader Website Supply Chain Attack | Rescana\r\n\r\nLe site officiel de JDownloader compromis | IT-Connect"},{"uuid":"e0b26900-54db-49c8-9fb7-2fe3a84659b5","slug":"dossiers-remarquables","title":"200 · Répertoires et fichiers remarquables sous Linux","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-08-20 06:58:15","created_at":"2023-08-20 06:58:15","updated_at":"2023-08-20 06:58:15","tags":[],"plain":"La structure de répertoires pour les systèmes d'exploitation Linux et Unix est définit par le standard FHS (Filesystem Hierarchy Standard). Il a pour but de fournir une structure de répertoires pour les différents types de fichiers commune pour toutes les distributions Linux et Unix, afin de rendre les systèmes d'exploitation plus portables et plus faciles à utiliser. Il décrit également les règles de nommage des fichiers et des répertoires, ainsi que les conventions pour les fichiers de configuration et les fichiers de données. La structure de répertoire décrite par le FHS est divisée en plusieurs sections principales :\n/ : la racine de tous les répertoires Depuis le répertoire racine, vous trouverez les répertoires suivants :\n/home : contient les répertoires des utilisateurs,\n/bin : contient les commandes couramment utilisées,\n/boot : contient les fichiers nécessaires pour démarrer le système d'exploitation,\n/dev : contient des fichiers de périphériques,\n/etc : contient les fichiers de configuration,\n/lib : contient les bibliothèques de système et bibliothèques partagées,\n/media : contient des sous-dossiers pour les périphériques de stockage amovibles,\n/mnt : contient des sous-dossiers pour monter des systèmes de fichiers externes,\n/opt : contient des logiciels tiers ou des applications qui ne font pas partie des paquets de distribution standard,\n/run : contient des informations sur les processus en cours d'exécution et les périphériques connectés,\n/sbin : contient les commandes pour les administrateurs système. Peut-être remplacé par .\n/srv : contient les données de service spécifiques,\n/tmp : contient des fichiers temporaires qui sont utilisés par les programmes en cours d'exécution. Peut être remplacer par ou .\n/usr : contient les programmes, les documents et les données utilisateur qui sont utilisés par tous les utilisateurs du système,\n/var : contient les fichiers qui peuvent changer pendant l'exécution du système. Le respect de cette structure de répertoires est important car cela permet d'éviter les conflits de nom, de faciliter la maintenance des systèmes, et de rendre les systèmes d'exploitation plus portables entre les différentes distributions. Répertoires et fichiers remarquables\nIl existe de nombreux répertoires remarquables dans une installation de Linux Fedora, voici quelques exemples. Dans le dossier personnel\nLe dossier personnel (ou répertoire de l'utilisateur) est généralement situé dans le répertoire sur un système Linux. Le nom du répertoire de l'utilisateur est généralement le même que le nom d'utilisateur, par exemple : pour un utilisateur nommé \"john\". Le répertoire de l'utilisateur en cours est représenté par le symbole . Ce répertoire contient généralement des sous-répertoires pour les documents, les images, les musiques, les vidéos et les téléchargements, ainsi que des fichiers de configuration pour les différents programmes utilisés par l'utilisateur. Il est également utilisé comme un espace de travail pour les fichiers et les projets de l'utilisateur. Les utilisateurs ont généralement des autorisations en écriture sur ce répertoire, ce qui leur permet de créer, de supprimer et de modifier les fichiers et dossiers qu'il contient. Cependant, les autres utilisateurs ou les utilisateurs qui se connectent en tant qu'invité n'ont généralement pas accès à ce répertoire. Il existe plusieurs fichiers et répertoires remarquables dans le répertoire personnel d'un utilisateur sur un système Linux, voici quelques exemples :"}] |