Cédrix
1 line
39 KiB
JSON
1 line
39 KiB
JSON
[{"uuid":"cf6f24c0-6d6f-4c69-b901-0ada82c66f46","slug":"se-connecter-a-un-reseau-wifi","title":"Se connecter à un réseau Wifi","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2022-02-05 10:34:42","created_at":"2022-02-05 10:34:42","updated_at":"2022-02-05 10:34:42","tags":[],"plain":"Les extraits de codes suivants ont été testés avec un Espressif ESP8266 / ESP 12F soudé sur une carte NodeMcu V3. Un connexion Wifi Client permet d'indiquer à l'ESP de se connecter à un réseau Wifi, désigné dans notre code par la variable wifissid, utilisée par la méthode WiFiMulti.addAP. Il est également possible d'indiquer un mot de passe en tant que second paramètre (). Voilà le résultat dans le moniteur série de l'application Arduino IDE**."},{"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":"910e2c3d-93f1-4af5-816c-4bc489cb0abe","slug":"fixing-seagate-7000-11-hard-drive","title":"Réparer un disque dur HS","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:06:24","created_at":"2020-04-17 18:06:24","updated_at":"2020-04-17 18:06:24","tags":[],"plain":"Vous êtes sur le point de jeter votre disque dur qui ne veut plus fonctionner :\nWindows ne veut pas voir le disque dur\nLe BIOS ne détecte pas le disque dur Les arrêts/démarrages de l'ordinateur ne change rien au problème : le disque dur est perdu, invisible ! Pourtant, vous l'entendez, le moteur fonctionne, les têtes cliquettent au démarrage... tout vous semble correctement fonctionner. Si vous possédez un Maxtor ou un Seagate, vous avez sûrement essayé les outils :\nSeaTools pour Windows\nSeaTools pour DOS - le DOS est intégré dans l'image bootable. Mais rien y fait, même l'utilitaire SeaTools ne voit rien. Et pourtant vous avez bien pensé à basculer de AHCI à IDE dans le gestion des disques du BIOS. Il reste encore un moyen. Vous êtes surement tombé sur le bug du BSY State. Concrètement, il s'agit d'un mode dans lequel le micrologiciel (firmware) du disque dur n'arrive plus à se sortir. Ce bug empêche le BIOS de détecter le disque dur, et donc, empêche tous les accès de l'ordinateur, y compris Windows, Linux... Pour que le micrologiciel puisse se sortir de la boucle infernale du BSY State, il va falloir modifier les informations S.M.A.R.T.. Ces informations sont écrites dans les premiers secteurs du disque dur. <note warning>Avec un Maxtor STM3500320AS, je viens d'avoir tous ces symptômes :\ndisque non reconnu dans le BIOS\ndisque non détecté avec une interface USB\npas de bruit suspect à l'arrêt et au démarrage du disque\n</note> La méthode que je vais vous détailler et non destructive si vous suivez toutes les instructions, sans mauvaise manipulation. Prérequis\nLe disque dur possède trois interfaces :\nune interface pour une alimentation SATA\nune interface pour des transfert des données SATA\nune interface série/limiteur de taux de transfert Il va falloir accéder au micrologiciel du disque dur par le port série. Si vous n'avez pas de port série sur l'ordinateur, il va falloir trouver un adaptateur USB/Série appelé également USB/TTL. Pour ma part j'ai utilisé un Arduino Uno qui intègre un convertisseur USB/TTL avec une puce Atmega16U2. La puce 16U2 est programmée avec des pilotes standards COM USB, et il n'est pas nécessaire d'installé un pilote PC pour y accéder. Le bornier série du disque dur est assez étroit et il a fallu que j'adapte des connecteurs pour qu'il y ait un contact propre et sans risque de court-circuit. Pour éviter les courts-circuits j'ai ajouté de la gaîne thermorétractable. Étant donné que le disque dur est sorti de son logement standard, je n'ai plus d'alimentation électrique pour permettre de le faire fonctionner. J'ai utiliser une alimentation fournie avec un kit de connexion de disque dur USB 2.0 to SATA/IDE. <note important>Je récapitule le matériel nécessaire :\n3 câbles de connexion - entre le convertisseur USB/TTL et le disque dur\nconvertisseur USB/TTL - Arduino pour moi\nalimentation électrique SATA\ntourne vis TORX T5\nfeuille épaisse\n</note> Préparation\nJe vais utiliser Putty, comme logiciel de communication série qui a l'avantage d'être disponible sous Windows et Linux. Putty Je prépare l'Arduino pour que les PIN0 et PIN1 deviennent une image parfaite du port USB. La manipulation est toute simple et ne demande aucune programmation dans l'Arduino. Relier le port RESET à la masse (GND) de l'Arduino. Ensuite, il suffit de raccorder le convertisseur au disque dur et le convertisseur à l'ordinateur. Sur l'Arduino :\nla broche 0 correspond au RX et \nla broche 1 au TX. Sur le disque dur, PCB vu du dessus, \nla broche 2 correspond à la masse, \nla broche 3 au RX et \nla broche 5 au TX Relier les 3 fils (masse, TX et RX) entre l'Arduino et le disque dur. Vérification\nAprès avoir connecté le câble USB, l'Arduino se met en route et est tout de suite reconnu par le système. Sous Linux, vous pouvez vérifier qu'un port tty a bien été ajouté en tapant la commande : voici le réponse : La ligne qui nous intéresse contient la phrase , et le résultat qu'il faut retenir est . Cette indication va nous permettre d'indiquer à Putty sur quel canal dialoguer. Configurer Putty pour communiquer sur le port /dev/ttyACM0, avec une vitesse de 38400 Ouvrir un session Putty sur le port série. Ensuite, alimenter le disque dur et au bouts de quelques secondes, le résultat suivant apparait : Ce code indique bien que le disque dur est dans un état BSY (Busy). Réparer\nLa réparation va se dérouler en 3 temps :\nisoler le micrologiciel des données SMART\ndétruire la partition contenant les données SMART\nrecréer la partition des données SMART 1. Hors alimentation, convertisseur déconnecté de l'ordinateur, démonter le PCB et insérer entre le PCB et les connecteurs des têtes la feuille d'isolation. Celle-ci doit pouvoir être retirée lorsque le PCB sera de nouveau en place. Revisser uniquement les deux vis de droite afin de ne pas bloquer la feuille entre le PCB et le connecteur. Lancer le session Serial de Putty et connecter le convertisseur à l'ordinateur, alimenter le PCB du disque dur. Au bout quelques secondes, appuyez sur Réponse : Accéder au level 2 en tapant Le moteur du disque dur s'arrête et réponse : Attendez au moins 20 secondes pour que le disque dur s'arrête. Normalement, il s’arrête au bout de 10 secondes, mais il vaut mieux être prudent. Nous allons informer le micro logiciel d'un arrêt du moteur en tapant la commande Ayant isolé les têtes de lecture, le micrologiciel répond : <note important>Manipulation délicate, mais réalisable Enlever minutieusement le papierentre le PCB et le connecteur des têtes de lecture. Replacer les 3 vis en veillant à ne pas faire court circuit avec le PCB.\n</note> 2. On demande au moteur de démarrer en tapant la commande Le micrologiciel nous répond : Maintenant, nous accédons au level 1 en tapant la commande Réponse : Maintenant, il faut effacer les secteurs du SMART en tapant la commande Réponse : \nRéponse : Vous pouvez arrêter l'alimentation SATA et attendre une vingtaine de seconde avant de mettre de nouveau l'alimentation électrique du SATA. 3. Appuyer de nouveau sur les touches pour revenir en mode édition. Réponse ; Il faut réécrire les informations SMART avec la commande . Réponse : Attendez bien ce message pour pouvoir de nouveau arrêter l'alimentation. Vous pouvez dès à présent brancher votre disque dur à son emplacement prévu et vérifier que tout fonctionne bien. Après ces opérations, je vous invite fortement à effectuer une sauvegarde de vos documents et de jeter ce disque dur. Quelques liens\nhttps:www.guillaume-leduc.fr/surveillez-la-sante-de-vos-disques-sous-linux-avec-smartmontools.html\nhttps:fr.wikipedia.org/wiki/Self-Monitoring,AnalysisandReportingTechnology"},{"uuid":"0bba1ad7-e4cb-49a6-9467-fcfac2e09a93","slug":"deuxiemes-pas-devops-durcir-et-fiabiliser-un-serveur-debian","title":"Deuxièmes pas DevOps : durcir et fiabiliser un serveur Debian","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-06-08 07:00","created_at":"2026-05-12 23:01:34","updated_at":"2026-05-13 22:53:46","tags":{"logiciels":["Fail2ban","Debian"]},"plain":"Une fois le système de base configuré (dépôts, mises à jour, , identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.\r\n\r\nSécuriser l'accès SSH\r\n\r\nSSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.\r\n\r\nPasser à l'authentification par clé\r\n\r\nLes mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.\r\n\r\nCôté poste de travail, on génère une paire de clés modernes :\r\n\r\n\r\n\r\nL'algorithme est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire () facilite l'identification de la clé quand on en gère plusieurs.\r\n\r\nOn copie ensuite la clé publique sur le serveur :\r\n\r\n\r\n\r\nCette commande dépose la clé publique dans côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.\r\n\r\nDésactiver la connexion root et les mots de passe\r\n\r\nUne fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est :\r\n\r\n\r\n\r\nLes directives importantes à positionner (ou décommenter) sont :\r\n\r\n\r\n\r\nLa première interdit toute connexion directe en via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via . La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.\r\n\r\nOn recharge ensuite le service pour appliquer les changements :\r\n\r\n\r\n\r\nImportant : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.\r\n\r\nPour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.\r\n\r\nMettre en place un pare-feu\r\n\r\nPar défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent : (le successeur officiel d', bas niveau et puissant) et (une surcouche pensée pour la simplicité). Pour démarrer, est le bon compromis.\r\n\r\n\r\n\r\nLa logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :\r\n\r\n\r\n\r\nSi SSH écoute sur un port non standard, remplacer par (ou le port choisi). Oublier cette étape avant un est un grand classique du verrouillage involontaire.\r\n\r\nPour les services web, on ouvrira typiquement les ports 80 et 443 :\r\n\r\n\r\n\r\nL'état du pare-feu se vérifie avec :\r\n\r\n\r\n\r\nSur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.\r\n\r\nAutomatiser les correctifs de sécurité\r\n\r\nLes failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement chaque matin sur dix machines. Le paquet applique automatiquement les mises à jour du dépôt .\r\n\r\n\r\n\r\nLa configuration se trouve ensuite dans . Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.\r\n\r\nQuelques options qui méritent l'attention dans ce fichier :\r\n: à régler sur si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou si l'on préfère les piloter à la main. La directive permet alors de choisir l'horaire.\r\n: pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.\r\n\r\nLe bon réflexe consiste à vérifier de temps en temps les logs dans pour s'assurer que tout se déroule sans heurts.\r\n\r\nSoigner les détails opérationnels\r\n\r\nQuelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.\r\n\r\nFail2ban surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :\r\n\r\n\r\n\r\nLa configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans .\r\n\r\nLogwatch ou journalctl méritent qu'on s'y attarde. Sur une Debian récente, est l'outil central pour consulter les logs systemd :\r\n\r\n\r\n\r\nPrendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.\r\n\r\nUn swap raisonnable, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.\r\n\r\nEt après ?\r\n\r\nAvec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.\r\n\r\nComme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif."},{"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."}] |