Cédrix
1 line
50 KiB
JSON
1 line
50 KiB
JSON
[{"uuid":"3e7ef528-6bd0-4fd1-83cb-a0d03ba35949","slug":"npm-le-ver-dans-le-fruit-comprendre-la-faille-systemique-et-repenser-les-pratiques-devops","title":"NPM, le ver dans le fruit : comprendre la faille systémique et repenser les pratiques DevOps","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 13:08","created_at":"2026-05-12 13:08:44","updated_at":"2026-05-12 13:12:42","tags":[],"plain":"À propos de l'article du MagIT « NPM : une nouvelle campagne malveillante souligne une vulnérabilité systémique ».\r\n\r\nNPM expliqué simplement\r\n\r\nQuand on développe une application web moderne en JavaScript ou TypeScript, on ne réécrit jamais tout depuis zéro. On assemble des briques logicielles déjà écrites par d'autres : un module pour parser des dates, un autre pour valider des emails, un troisième pour discuter avec une base de données. Ces briques s'appellent des paquets, et la place de marché centrale qui les distribue s'appelle npm (Node Package Manager).\r\n\r\nConcrètement, dans un projet, on déclare la liste des paquets nécessaires dans un fichier . On lance la commande , et l'outil télécharge automatiquement les paquets demandés… ainsi que tous les paquets dont ces paquets ont eux-mêmes besoin. Un projet « simple » se retrouve souvent à dépendre de plusieurs centaines, voire plusieurs milliers, de paquets en cascade. C'est ce qu'on appelle l'arbre des dépendances.\r\n\r\nLe registre npm héberge aujourd'hui plus de 2,5 millions de paquets. C'est à la fois sa force — un écosystème colossal, une productivité décuplée — et sa faiblesse : la confiance accordée à chaque maillon de la chaîne est implicite, et chaque maillon devient une porte d'entrée potentielle.\r\n\r\nLa faille : ce qui s'est passé\r\n\r\nL'épisode décrit par LeMagIT n'est pas un bug logiciel classique. C'est ce qu'on appelle une attaque sur la chaîne d'approvisionnement logicielle (supply chain attack) : au lieu d'attaquer directement la cible finale, l'attaquant compromet un fournisseur en amont, et laisse la mise à jour légitime faire son travail de propagation.\r\n\r\nLe scénario reconstitué se déroule en plusieurs temps.\r\n\r\n1. Compromission d'un paquet de confiance. Les attaquants sont parvenus à pousser du code malveillant dans des paquets npm largement utilisés, notamment via le détournement du pipeline d'intégration continue de projets connus comme et l'écosystème Checkmarx. L'astuce n'est pas de publier un faux paquet : c'est de modifier un vrai paquet en exploitant les GitHub Actions — les robots qui construisent et publient automatiquement les nouvelles versions.\r\n\r\n2. Vol de secrets à l'installation. Une fois installé sur la machine d'un développeur ou dans un environnement de build, le code malveillant scanne l'environnement à la recherche de variables sensibles : , , , . Tout ce qui traîne dans les variables d'environnement, les fichiers , les configurations cloud.\r\n\r\n3. Auto-propagation. C'est là que l'attaque devient virale. Avec les jetons npm volés, le maliciel se reconnecte au registre npm, récupère la liste des paquets publiés par la victime, et publie automatiquement des versions piégées de ces paquets. Chaque développeur compromis devient un super-propagateur. Socket a identifié une quarantaine de paquets infectés en cascade lors d'une seule vague.\r\n\r\n4. Persistance. Sur les postes touchés, le malware installe un script pour survivre aux redémarrages, et, si nécessaire, exfiltre les données volées dans un dépôt GitHub public créé pour l'occasion.\r\n\r\nLe résultat : un binaire signé, publié sous un nom officiel, à jour, qui passe tous les contrôles de surface — et qui contamine simultanément le poste du développeur et les serveurs de production.\r\n\r\nPourquoi c'est « systémique »\r\n\r\nLe terme employé par LeMagIT est juste. Ce n'est pas un bug isolé, c'est une propriété structurelle de l'écosystème.\r\n\r\nLa confiance est transitive. On fait confiance à , qui fait confiance à , qui fait confiance à , etc. Compromettre un nœud profond et populaire suffit à toucher des millions de projets.\r\n\r\nLa publication est ouverte. N'importe qui peut publier un paquet. Les contrôles existent (provenance, 2FA pour les mainteneurs populaires) mais restent surtout a posteriori.\r\n\r\nLes scripts d'installation s'exécutent automatiquement. Un paquet npm peut déclarer un qui lance du code arbitraire au moment de . C'est pratique, mais c'est aussi un cheval de Troie idéal.\r\n\r\nLes jetons d'API sont partout. Le poste du développeur, les runners CI/CD, les serveurs : tous manipulent des secrets en clair dans des variables d'environnement. Un malware qui s'exécute dans le build n'a même pas besoin d'escalader ses privilèges.\r\n\r\nLes versions sont mutables sur fenêtre courte. Un paquet peut être republié dans les 72 heures suivant sa publication, et un peut retirer une version d'un jour à l'autre.\r\n\r\nAucun de ces points n'est un défaut technique réparable par un patch. Ce sont des choix d'architecture, vieux de plus de dix ans, qui ont accompagné l'explosion de l'écosystème.\r\n\r\nY a-t-il des alternatives ?\r\n\r\nLa question est légitime, mais la réponse honnête est : pas vraiment, et pour de bonnes raisons.\r\n\r\nLes gestionnaires de paquets alternatifs\r\n\r\n, et sont des gestionnaires différents, mais ils tirent leurs paquets du même registre npm. Migrer de à ne change rien à la surface d'attaque : ce sont les mêmes paquets, le même registre, les mêmes mainteneurs.\r\n\r\nCela dit, certains apportent des garde-fous utiles :\r\na introduit l'option , qui refuse d'installer un paquet publié il y a moins de N jours. Une vague d'attaque dure typiquement quelques heures avant détection : attendre 72 heures avant d'installer une nouvelle version élimine la fenêtre dangereuse.\r\nimpose un consentement explicite pour les scripts , là où npm les exécute par défaut.\r\net proposent des lockfiles stricts () qui garantissent que ce qui est installé en CI correspond exactement à ce qui a été testé.\r\n\r\nLes registres alternatifs\r\n\r\nJSR (JavaScript Registry), lancé par les créateurs de Deno, est le seul vrai nouveau registre crédible. Il a été conçu en tirant les leçons des problèmes de npm : TypeScript natif, modules ECMAScript par défaut, pas de scripts d'install, scoring qualité automatique, compatible avec tous les runtimes (Node, Deno, Bun). Mais JSR est complémentaire, pas un remplaçant : il héberge des milliers de paquets, pas des millions. Pour la majorité des dépendances, on continuera de passer par npm.\r\n\r\nLes registres privés — Verdaccio, GitHub Packages, JFrog Artifactory, Sonatype Nexus — ne remplacent pas npm non plus. Ils servent de proxy filtrant : on continue de récupérer les paquets publics, mais à travers un cache d'entreprise où l'on peut bloquer une version, exiger une signature, refuser un mainteneur, ou interdire les paquets publiés depuis moins de X jours. C'est probablement le meilleur compromis disponible aujourd'hui pour une organisation.\r\n\r\nLe verdict\r\n\r\nAbandonner npm en 2026 reviendrait à abandonner JavaScript. La valeur de l'écosystème (2,5 millions de paquets) est trop importante pour qu'on en sorte. Le problème ne se résoudra pas par un changement d'outil ; il se résoudra par un changement de pratiques.\r\n\r\nChanger les pratiques : ce qui doit devenir réflexe\r\n\r\nL'enseignement de cette campagne, et des précédentes (Shai-Hulud, TeamPCP, l'attaque Trivy/KICS), tient en une phrase : la confiance par défaut est morte. Il faut traiter chaque dépendance comme du code hostile par défaut, et le pipeline CI/CD comme une zone de production.\r\n\r\nAu niveau du poste de développement\r\nActiver l'option (ou équivalent) pour différer l'installation des paquets fraîchement publiés.\r\nDésactiver les scripts par défaut, et n'autoriser que ceux explicitement validés.\r\nNe jamais stocker de jetons en clair dans ou les variables d'environnement persistantes. Préférer un gestionnaire de secrets (1Password CLI, , ).\r\nUtiliser des comptes npm séparés pour la publication, avec 2FA matérielle obligatoire.\r\n\r\nAu niveau du dépôt\r\nVerrouiller systématiquement les dépendances (, , ) et installer en mode strict (, ).\r\nMettre en place un audit automatique des dépendances à chaque PR (Socket, Snyk, GitHub Dependabot, ).\r\nPublier ses propres paquets avec provenance npm (signature liée au pipeline GitHub Actions), pour que les consommateurs puissent vérifier l'origine.\r\nTenir à jour un SBOM (Software Bill of Materials) pour savoir exactement ce qui tourne en production.\r\n\r\nAu niveau du CI/CD\r\n\r\nC'est probablement le chantier le plus important.\r\nCloisonner les jetons. Un jeton de publication npm ne doit jamais coexister avec un jeton AWS dans la même étape de pipeline. Un secret par étape, durée de vie minimale, scope minimal.\r\nPréférer les jetons à courte durée de vie (OIDC entre GitHub Actions et le cloud) plutôt que des clés statiques.\r\nAuditer les GitHub Actions tierces. Une action est l'équivalent d'un . Épingler par hash SHA (), pas par tag mutable.\r\nRestreindre les permissions du au strict minimum ( par défaut, ponctuel et justifié).\r\nSurveiller le comportement réseau des runners : un build qui contacte un domaine inconnu doit lever une alerte.\r\n\r\nAu niveau de l'organisation\r\nMettre en place un registre proxy (Verdaccio, Nexus, Artifactory) avec liste blanche/noire de paquets, et l'imposer comme unique source pour tous les projets.\r\nDéfinir une politique de dependency governance : qui peut introduire une nouvelle dépendance, sous quelles conditions, avec quel niveau d'audit.\r\nPrévoir un playbook de révocation : que faire dans l'heure qui suit la détection d'un paquet compromis (rotation de tous les jetons npm/GitHub/cloud, audit des artefacts publiés, communication).\r\n\r\nEn résumé\r\n\r\nNPM n'est pas cassé, il est tel qu'il a été conçu : ouvert, automatique, transitif. Ce qui a changé, c'est la valeur que les attaquants peuvent en extraire — secrets cloud, jetons CI/CD, accès aux pipelines — et la sophistication des campagnes, qui exploitent désormais l'auto-propagation pour atteindre une échelle virale.\r\n\r\nAucune alternative ne supprime le problème, parce que le problème n'est pas npm : c'est l'idée qu'on puisse exécuter en production du code écrit par des inconnus sans jamais le regarder. Le rôle du DevOps en 2026, c'est de bâtir l'infrastructure qui rend cette inspection systématique, économique et inévitable — registres proxy, lockfiles stricts, jetons éphémères, audits continus, isolation des étapes de build.\r\n\r\nOn ne fera pas confiance à moins de gens. On exigera juste que chaque maillon prouve, à chaque exécution, qu'il est bien celui qu'il prétend être."},{"uuid":"4f443bcb-b0d4-47f8-837d-61627e6c94f2","slug":"priorites-et-acces-au-reseau-en-4g-et-5g","title":"Pourquoi le réseau mobile ne s'effondre pas le jour où tout le monde téléphone en même temps","category":"télécom","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-01-06 22:21","created_at":"2026-01-06 22:21:04","updated_at":"2026-05-11 23:40:18","tags":[],"plain":"Un attentat, un séisme, un match du Stade de France, une grande panne d'électricité. Dans ces moments-là, des centaines de milliers de gens dégainent leur téléphone au même instant. Le réseau mobile est dimensionné pour un usage moyen, pas pour un pic massif simultané, et il devrait théoriquement s'effondrer. La plupart du temps, il tient. Pas parfaitement, pas pour tout le monde, mais il tient — et surtout, les appels d'urgence continuent de passer. C'est le résultat d'une série de mécanismes empilés depuis les années 1990, que la 4G a affinés et que la 5G a élargis. Cet article les passe en revue, et termine sur une question qu'on me pose souvent : est-ce que mon forfait à 50 € me donne une place prioritaire dans cette file d'attente ?\r\n\r\nTrois questions, pas une\r\n\r\nQuand une cellule commence à chauffer, l'opérateur doit répondre à trois questions distinctes. Qui a le droit de se connecter ? Une fois connecté, qui passe en premier ? Et quels services doivent absolument continuer à fonctionner, quoi qu'il arrive ?\r\n\r\nLa 2G ne savait répondre qu'à la première. Elle filtrait à l'entrée et basta. La 4G a ajouté la deuxième : une fois admis sur le réseau, votre trafic est traité différemment selon son importance. La 5G ajoute la troisième : elle peut créer des réseaux virtuels parallèles dont certains sont réservés à des usages critiques, totalement isolés des autres.\r\n\r\nLe filtrage à l'entrée\r\n\r\nChaque carte SIM porte un numéro de classe d'accès, hérité du GSM, entre 0 et 15. Les classes 0 à 9 couvrent le grand public — autrement dit nous tous. Les classes 11 à 15 sont réservées : services de secours, autorités publiques, personnel opérateur, usages militaires selon les pays.\r\n\r\nQuand une cellule est surchargée, l'eNodeB (la station de base 4G) diffuse une consigne aux téléphones du secteur : « les classes 0 à 9, vous attendez ». C'est l'Access Class Barring. Concrètement, votre téléphone reçoit ce message et bloque lui-même votre tentative d'appel ou de connexion data, sans même envoyer la demande à la station. C'est élégant parce que ça soulage la station avant même qu'elle ne soit sollicitée. Les classes prioritaires, elles, passent sans encombre.\r\n\r\nUne variante plus dure, l'Extended Access Barring, vise les objets connectés et les usages non urgents. Quand une vraie crise se déclare, l'opérateur peut couper les compteurs intelligents, les alarmes domestiques et autres équipements bavards pour préserver la bande passante humaine.\r\n\r\nEn 5G, ce mécanisme a été refondu sous le nom d'UAC — Unified Access Control, introduit dans la Release 15 du 3GPP. UAC unifie dans un seul cadre ce qui était auparavant éparpillé entre ACB, EAB et d'autres dispositifs spécifiques. Il repose sur deux notions complémentaires. Les Access Identities identifient qui vous êtes : utilisateur lambda, abonné à un service prioritaire type MPS ou MCS, personnel d'urgence, agent opérateur. Les Access Categories identifient ce que vous essayez de faire : appel d'urgence, connexion data normale, SMS, mise à jour de localisation. La combinaison des deux détermine si votre demande passe ou pas. La granularité gagnée par rapport à la 4G est réelle : on peut bloquer un type d'action précis pour un type d'utilisateur précis, par exemple « les abonnés grand public ne peuvent plus initier de nouveaux appels data, mais les SMS et les appels voix continuent ».\r\n\r\nLa priorité une fois connecté\r\n\r\nLà où la 4G a vraiment innové, c'est en introduisant le QCI — QoS Class Identifier. Chaque flux de données qui transite sur le réseau se voit attribuer un numéro entre 1 et 9 (avec quelques valeurs supplémentaires pour des cas spéciaux) qui dit à l'infrastructure comment le traiter.\r\nUsage | QCI | Traitement |\r\n---|---|---|\r\nAppel VoLTE (voix sur LTE) | 1 | Latence minimale, débit garanti |\r\nVisioconférence | 2 | Débit garanti |\r\nSignalisation réseau | 5 | Très haute priorité |\r\nStreaming vidéo | 6 ou 8 | Best effort prioritaire |\r\nWeb et internet général | 9 | Best effort standard |\r\n\r\nQuand la cellule est encombrée, le routeur sait quoi sacrifier en premier. YouTube va ralentir, les pages web vont mettre du temps à charger, mais l'appel téléphonique de votre voisin reste audible. C'est un compromis assumé : on dégrade volontairement les usages secondaires pour préserver les usages critiques.\r\n\r\nLa 5G a transposé ce mécanisme sous le nom de 5QI (5G QoS Identifier) avec davantage de niveaux et une meilleure prise en compte des cas que la 4G gérait mal — notamment les services à très basse latence pour les usines connectées ou la voiture autonome. La voix d'urgence garde son sommet, les données critiques industrielles s'intercalent juste après, le streaming et le web restent en bas de la pile.\r\n\r\nL'isolation par tranches : le network slicing\r\n\r\nC'est l'apport majeur de la 5G en matière de gestion de crise. Au lieu de partager une seule infrastructure entre tous les usages, on peut maintenant la découper logiciellement en tranches — des slices — qui se comportent comme autant de réseaux indépendants, alors qu'ils tournent sur les mêmes antennes et les mêmes câbles.\r\n\r\nUn opérateur peut par exemple maintenir une tranche pour le grand public avec ses millions d'abonnés et son trafic massif, une autre pour les services d'urgence dimensionnée pour rester fluide même quand le reste sature, une troisième pour les objets connectés industriels avec des garanties de latence, et une quatrième pour des opérateurs critiques type SNCF, EDF ou hôpitaux. Chaque tranche a ses propres règles d'admission, ses propres priorités, ses propres garanties de performance. Si la tranche grand public est totalement saturée, celle des secours ne le sait même pas.\r\n\r\nCette isolation est ce qui distingue le plus fondamentalement la 5G des générations précédentes. Avant, tout le monde se battait pour les mêmes ressources, avec juste des priorités différentes pour départager. Maintenant, certaines ressources sont retirées du combat dès le départ.\r\n\r\nRécapitulatif\r\nGénération | Ce qui est contrôlé | Comment |\r\n---|---|---|\r\n2G | L'accès au réseau | Classes d'accès 0-15 |\r\n4G | L'accès + la priorité du trafic | ACB / EAB + QCI |\r\n5G | L'accès + la priorité + l'isolation des services | UAC + 5QI + network slicing |\r\n\r\nTous ces mécanismes restent invisibles tant que tout va bien. Vous ne savez pas qu'ils existent. Vous découvrez leur existence le jour où votre voisin n'arrive plus à charger ses mails alors que les pompiers, eux, continuent de communiquer normalement. Ce jour-là, ce n'est pas de la magie. C'est trente ans d'ingénierie radio qui ont anticipé que ça arriverait.\r\n--\r\n\r\nEt mon forfait premium, alors ?\r\n\r\nQuestion logique à ce stade. Si le réseau sait techniquement prioriser certains flux par rapport à d'autres, qu'est-ce qui empêche un opérateur de faire passer ses abonnés à 50 € devant ceux à 10 € quand les antennes saturent ? La réponse honnête commence par un aveu : techniquement, rien. L'outil existe, il s'appelle Quality of Service (QoS), c'est exactement le mécanisme qu'on vient de décrire. Si demain Orange ou SFR voulaient créer une voie rapide pour leurs abonnés haut de gamme, ils auraient les outils dans la boîte. Pourtant, ils ne le font pas. Pour quatre raisons.\r\n\r\nLa loi européenne l'interdit\r\n\r\nLe règlement (UE) 2015/2120, dit « règlement internet ouvert », oblige les opérateurs à traiter tout le trafic de la même façon, sans discrimination liée à l'expéditeur, au destinataire, au contenu ou à l'application. Il a fêté ses dix ans en novembre 2025, et l'ARCEP a profité de l'anniversaire pour rappeler que c'est l'un des piliers du modèle numérique européen. Les sanctions sont sérieuses : jusqu'à 3 % du chiffre d'affaires de l'opérateur fautif. Un opérateur français qui annoncerait demain « avec notre forfait Premium, vous passez devant les autres » se retrouverait devant l'ARCEP dans la semaine.\r\n\r\nLe règlement laisse quelques portes ouvertes pour les services dits « spécialisés » qui ont besoin d'une qualité garantie — téléchirurgie, voiture connectée. Mais ces exceptions sont étroitement encadrées et ne couvrent absolument pas le confort d'un client haut de gamme qui voudrait charger son Instagram plus vite à 19h.\r\n\r\nAux États-Unis, l'histoire est différente. La FCC a tenté de restaurer la neutralité du net en 2024, mais en janvier 2025 la cour d'appel du sixième circuit a invalidé la décision, jugeant que la FCC n'avait pas l'autorité légale pour reclasser le haut débit comme service public. Avec l'arrivée de Brendan Carr à la tête de la FCC, ouvertement opposé à la neutralité du net, il n'y a aujourd'hui plus de règle fédérale outre-Atlantique. Quelques États (Californie, Washington, New York, Oregon) ont leurs propres lois qui maintiennent le principe, mais à l'échelle du pays, les opérateurs américains pourraient légalement faire ce que leurs homologues européens n'ont pas le droit de faire. Pourtant, ils ne le font pas ouvertement non plus, et la raison renvoie aux trois points suivants.\r\n\r\nC'est commercialement intenable\r\n\r\nImagine la publicité : « Forfait Premium à 50 € — passez devant les pauvres pendant les heures de pointe ». Le slogan ne se vend pas. Les directions marketing savent que dire à la moitié de leurs clients qu'ils sont des citoyens de seconde zone du réseau est le plus court chemin vers une crise de réputation. C'est pour ça qu'on vous vend « plus de Go », « 5G ultra rapide », « roaming inclus dans 110 pays » — des promesses qui sonnent positivement sans jamais dire à personne qu'il est désavantagé.\r\n\r\nL'effet boule de neige serait toxique\r\n\r\nImagine que ça se mette quand même en place. Les riches passent devant. Les antennes restent saturées pour les autres, qui se mettent à payer plus pour échapper à la saturation, ce qui sature encore plus les bas forfaits, ce qui pousse encore plus de gens à monter en gamme. Au bout de cinq ans, on a un réseau à deux vitesses où les forfaits modestes deviennent quasi inutilisables aux heures critiques, et où la connexion mobile correcte devient un service de luxe. Ce n'est plus un service de télécommunications, c'est un système de classes.\r\n\r\nC'est exactement ce que la neutralité du net cherche à empêcher. Pas par idéologie, mais parce qu'on a déjà vu où mène ce genre de spirale dans les pays où elle n'est pas protégée. Certains opérateurs proposent par exemple des forfaits où Facebook et WhatsApp sont gratuits mais où le reste est payant, ce qui revient à dire que le bon internet est celui que l'opérateur a choisi pour vous. Ce n'est plus tout à fait le même service.\r\n\r\nÇa ne résoudrait rien\r\n\r\nQuand un réseau sature, ce n'est pas un problème de répartition entre utilisateurs, c'est un problème de capacité totale. Faire passer Pierre avant Paul ne crée pas un seul bit de bande passante supplémentaire. Ça déplace juste le problème de l'un vers l'autre. La vraie solution, quand une cellule sature trop souvent, c'est d'installer plus d'antennes, de densifier le réseau, de basculer sur une fréquence plus performante ou de passer à la génération suivante. C'est cher, c'est long, ça implique des autorisations administratives et des négociations foncières, mais c'est la seule réponse qui tient la route. Prioriser, c'est rapide, mais ça repousse le mur, ça ne le déplace pas.\r\n\r\nC'est comme si on proposait une voie réservée aux Mercedes sur l'A7 un samedi de chassé-croisé. Techniquement, on peut peindre la ligne au sol et installer les panneaux dans la matinée. Mais cette voie ne réduit pas le bouchon, elle le concentre sur les voies restantes ; elle écorne le principe d'égalité d'accès à l'infrastructure publique ; et elle ne change rien au problème de fond, qui est qu'il y a trop de voitures pour la route disponible. La vraie solution reste la même qu'avant : élargir l'autoroute, ou convaincre une partie des gens de prendre le train.\r\n\r\nLe caveat 5G\r\n\r\nUne nuance honnête pour finir. Le network slicing complique le débat juridique. Un opérateur peut créer des tranches de réseau avec des qualités différenciées en toute légalité quand il s'agit d'usages spécialisés — santé, industrie, transports. La question qui agite régulateurs et juristes depuis plusieurs années est de savoir où finit le service spécialisé légitime et où commence le contournement déguisé de la neutralité du net. L'ARCEP a ouvert ce chantier, et c'est probablement là, plus que dans une revanche commerciale brutale sur les forfaits premium, que se jouera la prochaine bataille.\r\n\r\nMais pour répondre simplement à la question : non, votre forfait à 50 € ne vous donne pas la priorité réseau sur celui de votre voisin à 10 €. Il vous donne plus de data, parfois un meilleur débit théorique, des options en plus. Pas une place dans la file."},{"uuid":"e1e8a0c1-6971-4357-9aaa-7e7a748922f3","slug":"quand-systemd-remplace-cron-pourquoi-et-comment-migrer-ses-taches-planifiees","title":"Quand systemd remplace cron : pourquoi (et comment) migrer ses tâches planifiées","category":"informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2026-06-01 07:56","created_at":"2026-05-12 13:57:29","updated_at":"2026-05-12 13:58:58","tags":[],"plain":"Cron tourne sur Linux depuis 1975. Il a fait son temps pour beaucoup d'usages : voici ce que les timers systemd apportent, et comment basculer sans tout casser.\r\n\r\nPourquoi cron reste partout\r\n\r\n est l'un des plus anciens outils Unix encore en service. Son principe tient en deux idées : un démon qui se réveille toutes les minutes, et un fichier texte — la crontab — où chaque ligne décrit une commande et son moment d'exécution avec cinq champs (minute, heure, jour du mois, mois, jour de la semaine).\r\n\r\n\r\n\r\nCinquante ans plus tard, ça marche. C'est installé partout, c'est documenté à mort, ça tient sur une ligne, et n'importe quel administrateur sait lire . Pour beaucoup de besoins simples — « lancer ce script tous les jours à 2h du matin » — cron reste le bon choix.\r\n\r\nLe problème est que les besoins ont rarement été aussi simples depuis longtemps.\r\n\r\nLes limites de cron qu'on finit toujours par rencontrer\r\n\r\nÀ chaque administration de serveur sérieuse, on retombe sur les mêmes frustrations.\r\n\r\nLa machine était éteinte au moment du job. Cron saute purement et simplement l'occurrence ratée. Si le portable de l'utilisateur dormait à 2h, la sauvegarde quotidienne n'aura pas lieu — point. Le job s'exécutera de nouveau le lendemain à 2h, sans rattrapage, sans alerte.\r\n\r\nLes logs sont dispersés ou perdus. Par défaut, la sortie standard du job est envoyée par mail à l'utilisateur (si est défini et qu'un MTA tourne) ou simplement perdue. Le démon lui-même logue dans syslog quand il démarre un job, mais pas son contenu. Diagnostiquer pourquoi un job a échoué la semaine dernière relève souvent de l'archéologie.\r\n\r\nPas de dépendances. Un job qui doit attendre que le réseau soit monté, qu'un point de montage soit présent, qu'un autre service ait fini son démarrage : cron ne sait pas exprimer ça. La parade habituelle — un ou un suivi d'une boucle d'attente — fonctionne mais reste un bricolage.\r\n\r\nPas de recouvrement entre exécutions. Si un job de 5 minutes en prend 7 ce jour-là, cron lance la prochaine occurrence pile au moment où la précédente tourne encore. Deux instances simultanées d'un script de synchronisation, c'est rarement ce qu'on veut.\r\n\r\nPas de jitter, pas de randomisation. Quand cinquante VMs lancent leur toutes en même temps à 6h25 (l'heure d'anacron par défaut sur Debian), le pic de charge sur l'hyperviseur est garanti. Cron n'offre aucune primitive pour étaler les exécutions.\r\n\r\nPas de visibilité globale. Pour répondre à « quels jobs vont tourner aujourd'hui sur cette machine ? », il faut lire la crontab système, les crontabs utilisateur (), le contenu de , , , etc. Aucune commande ne donne la vue consolidée.\r\n\r\nPas d'isolation, pas de quota. Le job s'exécute avec les privilèges et les ressources du shell qui l'a lancé. Aucune façon native de limiter à 50 % de CPU, à 1 Go de RAM, ou de couper si ça dépasse 10 minutes.\r\n\r\nAucun de ces points ne rend cron inutilisable. Mais accumulés sur une dizaine de jobs critiques, ils transforment l'administration en travail de surveillance permanente.\r\n\r\nCe qu'apporte un timer systemd\r\n\r\nSur toute distribution Linux moderne basée sur systemd (la quasi-totalité, hors BSD, Alpine, Gentoo et quelques cas particuliers), une alternative native existe : les timers. Le principe est différent dès le départ.\r\n\r\nUn timer systemd, c'est deux fichiers au lieu d'une ligne :\r\nUn fichier qui décrit ce qu'il faut faire — exactement comme on décrit un service classique, en mode pour un job ponctuel\r\nUn fichier qui décrit quand le faire — ce sont les règles de déclenchement\r\n\r\nCette séparation entre le « quoi » et le « quand » est plus verbeuse au départ, mais elle débloque tout le reste.\r\n\r\nUne syntaxe d'horaire lisible\r\n\r\nLà où cron oblige à mentaliser , systemd écrit :\r\n\r\n\r\n\r\nEt la commande valide l'expression en montrant la prochaine exécution prévue. Une erreur de jour-de-semaine ou un décalage horaire ne plante pas en silence : on le voit avant de déployer.\r\n\r\nD'autres formes utiles que cron ne sait pas exprimer :\r\n\r\n\r\n\r\nLe support natif des fuseaux horaires est une avancée significative pour qui gère des serveurs distribués géographiquement — cron ignore tout du concept et tourne sur le fuseau du système.\r\n\r\nDu temps relatif, pas seulement du temps absolu\r\n\r\nCron raisonne uniquement en horloge murale (« tel jour, à telle heure »). systemd ajoute le temps monotone, relatif à un événement :\r\n\r\n\r\n\r\n règle proprement le problème des exécutions qui se chevauchent : la prochaine instance se déclenche 6 heures après la fin de la précédente, pas 6 heures après son démarrage. Aucune équivalence simple en cron.\r\n\r\nLe rattrapage des exécutions ratées\r\n\r\nUne seule ligne change tout :\r\n\r\n\r\n\r\nAvec cette option, systemd mémorise la dernière exécution réussie. Si la machine était éteinte au moment prévu, le job se déclenche dès le démarrage suivant (après le éventuel, voir plus bas). Pour un portable, un poste de développement, ou n'importe quelle machine qui n'est pas en service 24/7, c'est une différence majeure de fiabilité.\r\n\r\nDu jitter intégré\r\n\r\n\r\n\r\nLe déclenchement se fait à un instant aléatoire dans la fenêtre . Quand cinquante machines lancent leur mise à jour quotidienne, le pic de charge se lisse au lieu de tomber au même instant. C'est la fonctionnalité que tous les administrateurs de flottes finissent par re-bricoler en cron avec un peu élégant.\r\n\r\nLe logging gratuit dans journald\r\n\r\nTout ce que le service écrit sur stdout et stderr est capturé automatiquement par journald. Une seule commande pour tout consulter :\r\n\r\n\r\n\r\nPas de configuration, pas de redirection à la main, pas de à coller à chaque ligne de crontab. Et accessoirement, journald gère la rotation, la compression et la rétention.\r\n\r\nLes dépendances déclaratives\r\n\r\nDans le fichier , on peut dire au planificateur qu'un job nécessite que le réseau soit prêt, qu'un point de montage soit présent, qu'un autre service ait démarré :\r\n\r\n\r\n\r\nsystemd attend que ces conditions soient remplies avant de déclencher le service. Le job ne tente plus de s'exécuter sur un montage absent ou avant que la résolution DNS soit fonctionnelle.\r\n\r\nLe contrôle des ressources via cgroups\r\n\r\nPuisque chaque exécution passe par un service, on bénéficie de tout l'arsenal cgroups de systemd :\r\n\r\n\r\n\r\nUn job de sauvegarde qui pourrait saturer le disque ne sortira pas de son enveloppe. Cron n'offre rien d'équivalent — au mieux on enrobe la commande dans et , ce qui reste primitif.\r\n\r\nLa vue consolidée\r\n\r\n\r\n\r\nUne seule commande, toutes les exécutions planifiées du système, classées par prochaine échéance, avec date de dernière exécution. La question « qu'est-ce qui tourne automatiquement sur cette machine ? » trouve enfin une réponse en une ligne.\r\n\r\nUn exemple complet, pas-à-pas\r\n\r\nReprenons le job de sauvegarde initial — — et traduisons-le.\r\n\r\n :\r\n\r\n\r\n\r\n :\r\n\r\n\r\n\r\nActivation :\r\n\r\n\r\n\r\nVérifications :\r\n\r\n\r\n\r\nComparé à la ligne de crontab originale, c'est plus verbeux. Mais on a, sans rien ajouter : le rattrapage en cas d'arrêt machine, du jitter pour éviter les pics, l'attente du réseau, des limites de ressources, du logging structuré, et une commande pour tout inspecter.\r\n\r\nQuelques recettes utiles\r\n\r\nTous les jours à 3h sauf le dimanche :\r\n\r\n\r\n\r\nToutes les 15 minutes pendant les heures de bureau :\r\n\r\n\r\n\r\nLe premier lundi de chaque mois à 5h : pas faisable en une seule expression, mais combinable avec une condition qui vérifie la date et sort si ce n'est pas le bon jour. C'est l'une des rares zones où cron reste plus naturel ( + dans le script).\r\n\r\nToutes les six heures à partir du dernier passage (jamais de chevauchement) :\r\n\r\n\r\n\r\nTimer utilisateur, sans : dans , puis :\r\n\r\n\r\n\r\nQuand garder cron\r\n\r\nTout n'est pas à migrer. Cron reste le bon choix dans plusieurs cas :\r\nScripts portables vers BSD, macOS, ou des conteneurs minimaux. systemd n'existe pas dans Alpine Linux, sur les BSD, ni dans la plupart des images Docker légères.\r\nTâches utilisateur très simples sur un serveur partagé, où chaque utilisateur gère sa propre crontab sans privilèges admin.\r\nNotification par mail intégrée : si suivi d'une sortie sur stderr couvre déjà le besoin de monitoring, repasser par journald + un exporter Prometheus est de la sur-ingénierie.\r\nUn job de trente secondes à ajouter sur un serveur existant déjà couvert par cron. Mélanger les deux outils est sans risque — ils coexistent sans interférence — et créer deux fichiers pour un alias unique d'une ligne reste excessif.\r\n\r\nLa meilleure stratégie est rarement migratoire au pas de charge. Elle consiste à utiliser systemd pour toute nouvelle tâche planifiée, et à ne migrer les jobs cron existants que quand ils posent un problème concret : un job raté qu'il fallait rattraper, un log perdu qu'il fallait retrouver, un chevauchement qui a corrompu des données.\r\n\r\nEn résumé\r\n\r\nCron n'est pas obsolète, il est sous-dimensionné pour des besoins modernes. Les timers systemd ne remplacent pas la simplicité d'une ligne de crontab pour un job trivial, mais ils apportent à peu près tout ce qui manque dès qu'une tâche planifiée devient critique : rattrapage, logging, dépendances, isolation, observabilité.\r\n\r\nPour un DevOps qui construit aujourd'hui un nouveau service, le choix par défaut a basculé : commencer en systemd, et n'utiliser cron que par exception justifiée. La verbosité initiale des deux fichiers se rentabilise au premier incident de production qu'on diagnostique en au lieu de fouiller dans des logs disparates.\r\n\r\nEt même sans migrer quoi que ce soit, la commande mérite d'entrer dans le réflexe de tout audit de machine Linux. C'est là que se cache la moitié des tâches planifiées qu'on croit avoir comprises."},{"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":"1ba0f9e1-eb44-44b4-890b-a2526815d9f6","slug":"20230213-le-shell-la-ligne-de-commandes","title":"Le shell : la ligne de commandes","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-13 22:31:30","created_at":"2023-02-13 22:31:30","updated_at":"2023-02-13 22:31:30","tags":[],"plain":"La ligne de commande est un outil puissant pour interagir avec un système d'exploitation, en particulier sous Linux. Elle permet d'exécuter des commandes, de manipuler des fichiers et de contrôler le système sans l'aide d'une interface graphique. Il existe différents types d'options qui peuvent être utilisées pour personnaliser le comportement des commandes en ligne de commande sous Linux. Les options mono-caractère sont des options courtes qui sont précédées d'un tiret simple (-) et peuvent être combinées pour obtenir des effets plus complexes. Par exemple, la commande peut être utilisée avec l'option pour afficher les fichiers et répertoires sous forme de liste détaillée. Les options longues sont des options plus détaillées qui sont précédées d'un double tiret (--) et peuvent inclure des mots entiers pour décrire plus clairement leur fonctionnement. Par exemple, la commande peut être utilisée avec l'option longue pour afficher les fichiers et répertoires sous forme de liste détaillée. Il est également possible de spécifier des arguments qui sont des informations nécessaires à la commande pour accomplir son travail. Les arguments peuvent inclure des noms de fichiers, des répertoires, des noms d'utilisateurs, etc. Enfin, la séparation des options et des arguments peut être faite en utilisant un double tiret (--) pour signaler la fin des options et le début des arguments. En conclusion, la ligne de commande est un outil puissant pour interagir avec un système d'exploitation sous Linux, et il existe de nombreuses options et arguments disponibles pour personnaliser le comportement des commandes. Il est important de comprendre les différences entre les options et les arguments pour utiliser correctement les commandes en ligne de commande.\nVoir l'article complet :"}] |