Connexion
C'est la fin d'une époque. Le noyau Linux, le cœur du système qui pilote le matériel et les communications, s'apprête à supprimer le support d'AppleTalk, ce vieux protocole réseau qu'Apple utilisait dans les années 80 et 90 pour faire dialoguer ses Mac entre eux avant que TCP/IP, le langage commun d'internet, ne s'impose partout.
À l'époque, c'était plutôt malin: vous branchiez deux machines et une imprimante, et elles se trouvaient toutes seules, sans la moindre configuration, du plug-and-play avant l'heure à un moment où monter un réseau relevait encore du casse-tête réservé aux initiés.
Aujourd'hui, plus grand monde ne parle ce dialecte. Il en subsiste quelques traces dans Bonjour, la techno maison qui détecte automatiquement imprimantes et appareils sur un réseau local, mais le protocole d'origine, lui, est mort depuis longtemps.
Près de 4000 lignes de code vont donc disparaître avec la version 7.2 du noyau, et Apple avait lui-même enterré AppleTalk dès 2009, du temps de Mac OS X Snow Leopard. Autant dire que le préavis a été large.
Le plus étonnant, c'est ce qui a déclenché le grand ménage. Ce n'est pas vraiment l'abandon par les utilisateurs, mais une vague de correctifs générés par intelligence artificielle qui a fini par saturer la liste de diffusion des développeurs réseau.
Depuis quelques mois, des outils basés sur des grands modèles de langage, balancent automatiquement des "corrections" de bugs sur du code que personne n'avait réclamé, pour un protocole que plus aucun matériel ne fait tourner.
Et chaque proposition, même inutile, mobilise un humain qui doit la lire, la tester et vérifier qu'elle ne casse rien ailleurs, du temps précieux soustrait au vrai travail de mainteneurs déjà débordés par les contributions légitimes.
C'est Jakub Kicinski, qui supervise toute la pile réseau du noyau, qui a fini par trancher: plutôt que de faire éplucher par ses équipes des patchs pondus en série par des machines pour réparer une techno morte, il a préféré retirer AppleTalk d'un seul geste.
Et il n'en est pas à son coup d'essai. Au cycle précédent, pour Linux 7.1, il avait déjà passé à la trappe ARCnet, l'ISDN, la radio amateur et toute une collection de vieux pilotes réseau oubliés, soit près de 138 000 lignes effacées d'un coup, dans ce qu'il a lui-même baptisé la "LLM-pocalypse".
Le code d'AppleTalk ne finit quand même pas tout à fait à la poubelle, puisqu'il rejoint AX.25 et la radio amateur dans un dépôt GitHub mis de côté, pour les rares curieux qui voudraient encore bidouiller avec.
Bref, c'est une première: des contributions automatisées qui font retirer du code encore fonctionnel. L'IA ne crée pas toujours. Parfois, elle déblaie.
Source : Phoronix
Vous connaissez le duo Prometheus et Grafana ? C'est le grand classique pour surveiller ses serveurs, mais configurer tout ce bazar et le garder propre, c'est vite l'enfer. Alors pour ceux qui veulent juste garder un oeil sur leur homelab plutôt que de perdre le peu de cheveux qu'il leur reste à configurer Grafana durant des heures, j'ai trouvé pour vous Beszel .
Beszel est un outil de monitoring de serveurs ultra-léger et surtout super simple à mettre en place. Le projet est tout récent et développé en Go, ce qui permet d'avoir des binaires minuscules et une consommation de ressources ridicule
Donc si vous cherchez un outil de monitoring Linux self-hosted aussi simple à prendre en main que Kula dont je vous ai déjà parlé, ça vaut le coup d'aller jeter un oeil.
La mécanique de Beszel repose sur deux morceaux, à savoir le hub et l'agent. Le hub, c'est l'interface web construite au-dessus de PocketBase, qui sert de tableau de bord centralisé quant à l'agent, lui, il tourne discrètement sur chaque machine à surveiller et remonte les métriques au hub. "Discrètement", ça veut dire qu'il consomme à peine 10 à 15 Mo de RAM donc c'est parfait pour le faire tourner sur une vieille machine ou un tout petit Raspberry Pi sans que ça tousse-tousse !
Le truc vraiment cool aussi, c'est la gestion native des conteneurs Docker. Au lieu de simplement suivre l'état général comme avec un outil de suivi des processus classique (je pense à pstop par exemple), il liste chaque conteneur et affiche sa consommation individuelle en CPU, mémoire et réseau. Donc pour tous ceux qui auto-hébergent des dizaines de services, c'est un pur bonheur.
Côté métriques, y'a aussi tout ce qu'il faut pour ne rien louper. L'outil permet de suivre la consommation CPU, la mémoire (incluant le swap et le ZFS ARC), l'espace disque, les entrées/sorties réseau, la moyenne de charge et même la température des composants. En 15 secondes, tout s'affiche proprement.
Il gère aussi des trucs plus poussés comme la santé des disques via les données S.M.A.R.T., l'état de la batterie et même la consommation de vos cartes graphiques Nvidia, AMD ou Intel. Attention, pour le S.M.A.R.T. et le GPU par contre, il faudra que vous installiez les utilitaires système correspondants sur la machine hôte (smartmontools, nvidia-smi...) pour que l'agent puisse remonter les infos.
Et la configuration ? Hé bien c'est un simple fichier docker-compose.yml et voilà c'est plié !
Lors du premier lancement du hub, vous devrez vous créer un compte administrateur, puis cliquer sur "Ajouter un système", et l'interface vous génèrera une clé publique. Il suffira ensuite de filer cette clé à votre agent via sa variable d'environnement (dans son docker-compose.yml, par exemple) et les deux copains commenceront à causer. C'est pas plus compliqué que ça ! Même un notaire pourrait le faire ^^.
Le hub intègre également une gestion multi-utilisateur bien foutue puisque chaque utilisateur peut avoir accès à ses propres machines, tandis que l'administrateur peut décider de partager certains systèmes. Si vous voulez sécuriser le tout, l'outil supporte aussi de nombreux fournisseurs OAuth2 et OIDC comme Google, GitHub ou Keycloak, et vous pouvez même couper complètement la connexion par mot de passe.
Beszel s'occupe aussi des sauvegardes automatiques de vos données de surveillance, en local ou directement sur un stockage compatible S3. Et pour les alertes, pas de panique, car l'outil est compatible avec Shoutrrr . Cela vous permettra de configurer des notifications par Discord, Telegram, Teams ou mail si le CPU s'affole ou si un disque commence à saturer.
Par contre, si vous cherchez un outil d'analyse de logs complet ou de détection de bug réseau ultra-précis, laissez tomber car c'est pas la "mission de vie" de Beszel. Sauf si bien sûr, vous le couplez avec un autre outil. Après pour le reste, c'est parfait.
Vous pouvez tester la version v0.18.7 en vous rendant sur le site officiel .
Oliver Sieber, un chercheur de chez Exodus Intelligence, vient de publier l'exploit complet d'une faille qui tient dans un seul caractère. C'est la CVE-2026-23111, planquée dans nf_tables, c'est à dire au bout du noyau Linux qui filtre les paquets réseau. Un bug discret donc, qui transforme un compte tout pourri, sans le moindre privilège, en compte root sur la machine... et qui vous fait sortir d'un conteneur au passage.
Le scénario, vous le connaissez si vous traînez ici depuis un moment. Un utilisateur qui dispose d'un compte sans droit particulier sur une machine Linux (y compris parce qu'il a exploité une autre faille avant, dans une appli web par exemple) lance l'exploit, et se retrouve avec les pleins pouvoirs. Pas de vecteur distant, rien à cliquer : c'est l'arme qu'on dégaine une fois le pied dans la porte. Que ce soit un shell avec des droits limités, un conteneur compromis, un compte de service... tout y passe et hop, root sur l'hôte !
Le bug lui-même, c'est ce qu'on appelle un use-after-free, c'est à dire que le noyau réutilise un bout de mémoire qu'il a déjà libéré, et forcément ça part en vrille. Exodus a titré son analyse complète "Off By !", un clin d'œil au classique off-by-one des développeurs, sauf qu'ici le coupable c'est un test inversé. Un caractère de trop, une condition qui dit l'inverse de ce qu'elle devrait, et voilà. Et le correctif, lui, tient en une seule ligne.
Le fameux caractère : le ! qui inversait le test dans nft_map_catchall_activate(). Le correctif le retire, et c'est tout (commit 8fdb05de).
La faille a d'ailleurs été reproduite deux fois, par deux équipes qui ne se sont pas concertées. Exodus l'a validé sur Debian Bookworm, Debian Trixie, Ubuntu 22.04 et 24.04. FuzzingLabs avait sorti sa propre version dès avril, par un chemin complètement différent, et l'avait fait tourner sur RHEL 10 juste avant le Pwn2Own de Berlin. Bref, ça marche, c'est bien documenté, et c'est public.
Mais le pire, c'est le calendrier de tout ce merdier puisque le patch a été mis à dispo le 5 février. Ensuite, y'a eu l'exploit de FuzzingLabs publié le 16 avril, suivi d'un write-up détaillé d'Exodus le 8 juin. Autrement dit, ça fait des mois que le correctif existe et des semaines que le code d'exploitation traîne dans la nature.
La seule chose qui vous sépare donc d'un compte root offert à n'importe qui, c'est d'avoir mis à jour ou pas.
Et cette faille s'ajoute à une sacrée série de failles root-local sur Linux ce printemps. Y'a eu Copy Fail , y'a eu Dirty Frag et sa variante Fragnesia ... à chaque fois le même refrain, un compte sans droit qui finit root sur une install standard. C'est devenu presque routinier, et Synacktiv pointe une raison plutôt pertinente en nous expliquant que c'est à cause (ou grâce ^^) aux outils d'IA qui décortiquent les patchs pour en sortir un exploit rapidos, qui marche direct avant même que la correction soit déployée partout.
Du coup, qu'est-ce que vous devez faire ?
Hé bien le plus simple d'abord, c'est de mettre à jour le noyau et vous rebootez. Ubuntu a corrigé 22.04, 24.04 et 25.10, Debian a patché Bookworm et Trixie (avec un backport en 6.1 pour Bullseye), et Red Hat, SUSE et Amazon Linux ont suivi. Comme la version corrigée exacte dépend de votre distrib, jetez donc un œil à l'advisory qui correspond à la vôtre.
Si vous gérez une machine où tournent des utilisateurs ou des workloads pas franchement de confiance, vous pouvez également couper le chemin d'attaque sans attendre le patch. La faille a besoin des user namespaces non privilégiés, un mécanisme qui laisse un process lambda se bricoler son propre bac à sable avec des droits root à l'intérieur.
Et nf_tables comme ces namespaces, sur la plupart des desktops et pas mal de serveurs, c'est actif par défaut, donc oui, sans le patch vous êtes probablement exposé.
Pour les désactiver, le plus universel c'est user.max_user_namespaces=0 : un sysctl -w user.max_user_namespaces=0 pour tout de suite, et la même ligne dans un fichier genre /etc/sysctl.d/99-userns.conf pour que ça tienne au reboot.
Ça marche sur toutes les distros mais c'est radical, ça coupe tous les user namespaces, même ceux de root. Sur Debian et les vieilles Ubuntu, t'as plus fin avec kernel.unprivileged_userns_clone=0 qui ne vise que les non-privilégiés. Et sur Ubuntu 24.04, bonne nouvelle, c'est déjà restreint par défaut via AppArmor. Attention quand même, ça peut casser des trucs qui s'appuient dessus, genre le bac à sable de Chrome ou Flatpak.
À faire en connaissance de cause, donc.
La parade en vrai : une fois les user namespaces non privilégiés coupés, un compte lambda qui tente d'en créer un (le prérequis de l'exploit) se fait jeter sur un "No space left on device".
Après la bonne nouvelle, c'est que d'après les chercheurs, aucune exploitation dans la nature pour cette faille précise n'a été constaté à ce jour. Après comme sa cousine Copy Fail, elle, a déjà atterri au catalogue des failles activement exploitées de la CISA, ne traînez pas trop. Bref, comme d'hab padpanik, vous mettez à jour, vous rebootez, et on n'en parle plus.
Il y a des failles qui réclament un arsenal de hacker chevronné, et puis il y a HTTP/2 Bomb, qui se contente de quelques kilo-octets pour faire vaciller des serveurs parmi les plus utilisés de la planète. Dévoilée le 2 juin sous la référence CVE-2026-49975, elle s'attaque à HTTP/2, le protocole qui transporte une bonne partie des pages que vous consultez chaque jour.
Le résultat ressemble à une mauvaise blague. Une poignée d'octets envoyés au bon endroit, et la mémoire vive du serveur se met à enfler jusqu'à engloutir des dizaines de gigaoctets en quelques secondes, jusqu'à ce que la machine ne réponde plus à personne.
On parle ici d'une attaque par déni de service, un DoS dans le jargon, dont le but n'est pas de dérober quoi que ce soit mais d'asphyxier le serveur. Rien de bien neuf, donc, sauf que l'ampleur du désastre, elle, l'est totalement.
Toute l'astuce tient dans le mariage de deux mécanismes connus depuis des lustres. HTTP/2 sait compresser les en-têtes des requêtes pour éviter de répéter cent fois la même chose, et c'est précisément cette générosité que l'attaquant retourne contre le serveur, en faisant référence des milliers de fois à un en-tête glissé une seule fois, si bien que la machine réserve de la mémoire à tour de bras pour quelque chose qui, au départ, ne pèse presque rien. C'est le principe de la bombe de décompression, ce fichier piégé minuscule qui se déplie en montagne de données dès qu'on l'ouvre.
Et comme si ça ne suffisait pas, l'attaquant fait mine de ne pas pouvoir recevoir la réponse, ce qui interdit au serveur de boucler sa tâche et de relâcher ce qu'il a accumulé. Quelques octets envoyés de loin en loin, et la connexion reste ouverte indéfiniment. C'est diabolique de simplicité.
Les chiffres, eux, font carrément peur. Sur Envoy, les chercheurs ont mesuré un rapport de plus de 5 000 pour 1, avec 32 Go engloutis en une dizaine de secondes, là où Apache craque en moins de vingt secondes et nginx comme IIS en moins d'une minute. Une simple connexion domestique à 100 Mb/s peut donc mettre à genoux une infrastructure entière.
Le plus déroutant dans cette histoire, c'est que les deux ingrédients de la recette traînaient en accès libre depuis des années. Il aura fallu attendre l'équipe de Codex, et le chercheur Quang Luong, pour avoir l'idée de les mélanger et constater les dégâts.
Du côté des correctifs, tout le monde n'est pas logé à la même enseigne. nginx a réagi avec sa version 1.29.8 et une nouvelle option pour brider les en-têtes, Apache a corrigé dans mod_http2 2.0.41, mais Microsoft IIS, Envoy et Cloudflare Pingora attendaient encore leur rustine au moment de la divulgation.
Bref, vieille recette, ingrédients connus, mais cocktail dévastateur. Si vous gérez un serveur en HTTP/2, allez vérifier vos versions avant qu'on ne teste la recette à votre place.
Source : The Hacker News
Une mise à jour récente du noyau Linux a cassé le support de certains adaptateurs Bluetooth MediaTek, ceux qui sont intégrés aux puces Wi-Fi qu'on trouve sur beaucoup de cartes mères modernes.
Le résultat : votre clavier sans fil, votre souris ou votre casque Bluetooth ne se connectent plus après la mise à jour. Pour les utilisateurs Linux, c'est le genre de régression franchement pénible, pour rester poli.
Al Williams raconte sur Hackaday avoir traqué le problème jusqu'à un fichier précis du noyau : btmtk.c, le pilote qui gère les puces Bluetooth MediaTek. Deux lignes de code suffisent à contourner le problème. Sa rustine consiste à remplacer une fonction de gestion d'erreur par une instruction qui marque la sortie comme "non terminée" et continue. C'est pas génial sur le papier, mais ça fait remarcher le matériel le temps qu'un correctif officiel arrive en amont.
Le problème, c'est que ce n'est pas un simple paramètre à changer. Il faut récupérer les sources du noyau, installer la boîte à outils de compilation, patcher la ligne concernée, recompiler juste le module problématique, l'installer dans /lib/modules, et rebooter.
Deux lignes. Pour un développeur Linux, c'est la routine. Pour un utilisateur lambda qui a juste envie que sa souris remarche, c'est franchement relou.
Al teste sa rustine sur OpenSUSE Tumbleweed (une distribution Linux à mises à jour continues), mais la procédure marche aussi sur Debian, Ubuntu et la plupart des autres distros, avec quelques ajustements de chemins. Il insiste : c'est temporaire. Le bug est connu des développeurs du noyau, et le correctif définitif devrait remonter dans les prochaines versions stables.
Le truc un peu naze, c'est que Bluetooth sur Linux a longtemps eu la réputation d'être un cauchemar. La situation s'était nettement améliorée ces dernières années avec BlueZ (la pile Bluetooth officielle de Linux) et le support natif dans la plupart des distros. Voir une régression d'envergure refaire surface en 2026 sur du matériel grand public, ça refait grincer des dents les vieux Linuxiens qui pensaient avoir refermé ce chapitre.
Et puis ça illustre bien le modèle de développement du noyau. Les régressions arrivent parce que le code évolue très vite et que tout le matériel ne peut pas être testé en permanence. Quand ça pète, la communauté patche. Quand le patch est validé, il remonte. C'est lent, mais ça finit toujours par marcher. Le truc, c'est qu'entre les deux, vous restez avec votre clavier Bluetooth en rade .
Si vous êtes touché par le problème, l'article complet d'Al Williams sur Hackaday donne toutes les commandes pas à pas . Le fix est documenté ligne par ligne, ça prend une trentaine de minutes pour quelqu'un qui est très à l'aise avec un terminal.
Source : Hackaday
Une faille planquée pendant 9 ans dans le noyau Linux, voilà ce que les chercheurs de
Qualys
viennent de déterrer. Son petit nom, c'est ssh-keysign-pwn ou DirtyDecrypt (CVE-2026-46333 pour les intimes), et elle permet à n'importe quel utilisateur local sans privilèges de passer root, de lire votre /etc/shadow et de piquer les clés SSH privées de votre serveur.
Et ce bug dormait là depuis novembre 2016, c'est-à-dire depuis la version 4.10 du kernel. Personne ne l'avait jamais vu et autant vous dire que 9 ans, en cybersécu, c'est une éternité !!
Le truc se cache dans une fonction au nom barbare, __ptrace_may_access(). En gros, quand un processus privilégié abandonne ses droits, y'a une micro-fenêtre, le temps d'un battement de cils, où il reste "accrochable" via ptrace. Vous combinez ça avec l'appel système pidfd_getfd() et hop, vous récupérez les fichiers ouverts d'un process root.
Et l'exploit disponible vise des binaires SUID que tout le monde a sur sa machine, genre ssh-keysign, chage, pkexec ou accounts-daemon.
Du coup, première chose à faire : vous mettez à jour, genre rapidos ! Linus Torvalds a poussé le correctif et si vous ne pouvez pas patcher tout de suite, faut taper la commande sysctl -w kernel.yama.ptrace_scope=2 qui a pour effet de refermer la porte en attendant.
Niveau distros, ça touche à peu près tout le monde, d'Ubuntu 14.04 jusqu'à la 26.04, en passant par Debian, Fedora et toute la famille Red Hat.
Et le plus gênant, c'est que ssh-keysign-pwn, c'est la 4e faille kernel en moins de trois semaines. On a eu CopyFail , Dirty Frag début mai, puis Fragnesia juste après, et maintenant celle-ci. Aïe aïe aïe ! Je commence à me lasser, sérieux ^^.
Le noyau Linux prend cher en ce moment et comme les exploits fonctionnels sont déjà publics, le compte à rebours est lancé pour tous ceux qui traînent !
Alors après tout le monde va vous parler des cybercriminels et des serveurs compromis, et c'est vrai, faut patcher. Mais pour moi, ce genre de faille, c'est aussi une clé qui sert aux bidouilleurs pour reprendre la main sur leur propre matériel. Votre routeur verrouillé, votre objet connecté que le fabricant a laissé tomber depuis quelques années, ce bon vieux NAS dont plus personne ne livre de firmware... une faille comme ça, c'est parfois le seul moyen de le faire revivre !
Bref, faites vos mises à jour. Et gardez en tête que ces mêmes failles qui font flipper les sysadmins, ce sont aussi celles qui redonnent vie au matos verrouillé qui n'avait pas d'autre avenir que de finir à la déchetterie.
Vous ne le savez peut-être pas mais votre serveur Linux embarque plusieurs milliers de modules kernel et pourtant, il n'en utilise que quelques centaines à peine. Tout le reste ça prend la poussière et ça peut vous exposer à des problèmes de sécurité. Hé bien c'est exactement à ces modules inutiles que Jasper Nuyens, le fondateur de Linux Belgium, vient s'attaquer avec son outil ModuleJail .
Ce script lit /proc/modules pour savoir ce qui tourne vraiment sur votre machine, et considère ensuite cet ensemble comme étant intouchable. Par contre, pour tout le reste il ajoute une ligne install <module> /bin/true dans /etc/modprobe.d/modulejail-blacklist.conf.
Comme ça si un jour quelque chose essaie de charger un de ces modules endormis, c'est modprobe qui exécutera /bin/true à la place... et il ne se passe rien !!
C'est malin, hein ? Vous pouvez installer ModuleJail via le script dispo sur la page Github ou grâce aux paquets .deb et .rpm si vous préférez. Et ensuite, pour vérifier que c'est bien en place, un petit modprobe -n -v module_banni devrait vous répondre install /bin/true.
En tout cas, je trouve que ModuleJail tombe très bien parce que la chasse aux failles kernel est clairement en train de changer d'échelle. Je pense notamment à tous ces outils de scan assistés par IA qui débusquent à la chaine des bugs d'élévation de privilèges planqués dans le code depuis des années.
Le script propose 3 profils via le flag -p, minimal pour le strict nécessaire, conservative par défaut (serveur classique plus drivers VM courants) et desktop qui garde WiFi, Bluetooth, audio et vidéo. Vous pouvez aussi ajouter votre propre whitelist.
Et la règle d'or non négociable, c'est de le lancer quand la machine est dans un état stable, avec tous les services démarrés, et tous les disques montés. Car oui, ModuleJail ne devine rien, mais se contente de photographier ce qui tourne à l'instant T. Donc sur un système à moitié démarré, ce serait un peu couillon qu'il bannisse un module dont vous aurez besoin plus tard.
Après pour tout ce qui est compilé en dur dans le kernel (le fameux =y de la config) ça reste là, donc une faille dans le cœur du noyau façon
Dirty Cow
, ça n'y changera rien du tout. Et si vous branchez une webcam six mois après, son module sera déjà banni donc faudra pas oublier de retirer sa ligne du fichier ou relancer le script avec une whitelist, car un simple modprobe ne suffira pas !
Donc c'est pas forcement le pied pour un Linux Desktop mais pour un parc de serveurs en prod qui ne bougent pas, c'est une petite couche de sécurité en plus.
Nginx, c'est ce logiciel discret qui sert les pages d'environ un site populaire sur trois sur la planète. Quand vous chargez une page web, il y a une bonne chance que ce soit lui qui vous l'envoie.
La société DepthFirst AI, spécialisée dans la recherche de failles assistée par intelligence artificielle, vient d'y trouver un trou de sécurité, et il est plutôt balèze : présent dans le code depuis 2008. Soit environ 18 ans de service sans que personne ne le remarque.
La faille (référencée CVE-2026-42945, le système de numérotation officiel des vulnérabilités) est notée 9,2/10 sur l'échelle de gravité, ce qui la classe en critique. Concrètement, elle vit dans un module précis de nginx qui gère la réécriture d'URL, et elle se déclenche quand deux instructions de configuration ("rewrite" et "set") sont utilisées en même temps.
C'est un débordement de mémoire tampon, c'est-à-dire que des données débordent dans une zone qu'elles ne devraient pas occuper. Quand on contrôle ce débordement, on peut faire planter le serveur, voire dans certains cas exécuter son propre code à distance sur la machine.
Pour le déni de service (DoS), c'est-à-dire faire tomber le serveur, l'exploitation est démontrée et fonctionne. Pour l'exécution de code à distance, c'est plus délicat : les chercheurs y arrivent uniquement quand une protection mémoire appelée ASLR est désactivée, ce qui n'est pas le cas par défaut sur les systèmes modernes. Bonne nouvelle relative, donc, mais ça reste à prendre très au sérieux.
Côté correctifs, les versions à installer sont nginx Open Source 1.31.0 ou 1.30.1, et NGINX Plus R36 P4 pour les clients commerciaux. Toutes les versions précédentes depuis 0.6.27 sont vulnérables, donc autant dire à peu près tout ce qui tourne en production aujourd'hui.
Si vous administrez un serveur, c'est le moment de regarder ce qui tourne dessus et de patcher rapidement. Les exploits publics ont une fâcheuse tendance à apparaître quelques jours après les divulgations de ce genre.
Le détail qui pique, c'est la méthode de découverte. DepthFirst AI utilise l'intelligence artificielle pour faire de l'analyse de code à grande échelle, en cherchant des motifs suspects que des outils classiques ne repèrent pas. Le fait qu'une faille planquée dans nginx depuis dix-huit ans soit sortie comme ça donne une idée de ce qui dort encore dans tout le code qu'on utilise au quotidien.
Source : Bleeping Computer
OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.
ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.
La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.
C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.
Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.
Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.
Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.
Source : Phoronix
Si vous cherchez une alternative à Termius qui ne vous coûte pas une petite couille, je crois que j'ai trouvé ce qu'il vous faut !
C'est vrai qu'il y a quelque chose de carrément agréable à pouvoir ouvrir un navigateur depuis n'importe quelle machine et retrouver tous ses serveurs, fichiers et tunnels au même endroit... Et Termius fait ça très bien, sauf que la fonctionnalité la plus utile, à savoir la synchro entre appareils, c'est payant !
Et c'est ça la raison d'être de Termix qui propose exactement ça mais en open source, en gratos et à héberger vous-même !
Termix, c'est donc une plateforme de gestion de serveurs accessible depuis le navigateur. On y retrouve un terminal SSH complet, de la gestion de fichiers distants, des tunnels SSH inversés, et depuis la v2.0 sortie en mars dernier, le support RDP, VNC et Telnet.
En clair, ça couvre à peu près tout ce dont on a besoin pour piloter une infra depuis un seul endroit. Petit détail à noter quand même, le RDP/VNC/Telnet n'est pas inclus par défaut, donc il faut ajouter un second conteneur guacd au compose. Rien de compliqué, mais à savoir avant de se lancer.
Le terminal SSH supporte jusqu'à 4 panels simultanés comme ça plutôt que de multiplier les sessions, vous regroupez au même endroit. Le gestionnaire de fichier est aussi très sympa avec du drag & drop dans les deux sens, la modification de fichiers distants directement dans le navigateur... Et y'a aussi une gestion des conteneurs Docker intégrée, un Network Graph pour visualiser les connexions entre hôtes, et un système de snippets de commandes pour éviter de retaper les mêmes commandes à longueur de journée.
Ce qui change par rapport aux autres alternatives web, c'est surtout sa dispo sur toutes les plateformes. L'accès web est évidemment central, mais il existe aussi des apps natives pour Windows, Linux, macOS (App Store, DMG ou Homebrew selon vos préférences), iOS/iPadOS et Android.
Tout se synchronise ensuite via le conteneur self-hosted comme ce que permet Termius, à la différence près que vous hébergez vous-même le système.
Côté sécurité et gestion d'équipe, Termix intègre du RBAC, de l'OIDC, du 2FA, et stocke les données dans une SQLite chiffrée.
Pour tester en local, le docker-compose de base ressemble à ça :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
services:
termix:
image: ghcr.io/lukegus/termix:latest
ports:
- "8080:8080"
volumes:
- termix-data:/app/data
volumes:
termix-data:
Attention à la config réseau avant tout puisque le port 8080 par défaut est souvent filtré ou déjà occupé donc changez ça dans le compose si besoin. Ajoutez ensuite le conteneur guacd si vous voulez le RDP/VNC/Telnet (je vous laisse aller lire la doc).
Après l'interface est fonctionnelle mais pas aussi léchée que Termius. Y'a pas de passkeys, et pas de support ed25519-sk pour les clés de sécurité hardware.
Pour une utilisation personnelle ou une petite équipe qui gère de l'infra linux, c'est largement suffisant, cela dit. Bref, si Termius c'est pas fait pour vous parce que c'est encore des sousous à sortir, sachez que Termix est là pour vous.
Merci Letsar pour le lien !
Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !
KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !
C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.
KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.
Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):
bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"
Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.
Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.
Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.
Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.
Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.
Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !
Le déploiement Docker c'est comme ça :
docker run -d --name kula --pid host --network host
-v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest
Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.
Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...
Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.
Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !
Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.
Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.
Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.
C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.
Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !
478 binaires Unix peuvent servir à devenir root sur un système mal configuré.
C'est ce que recense GTFOBins , le projet open source monté par Emilio Pinna et Andrea Cardaci, qui est devenu LE bookmark obligatoire de tout pentester Linux.
Ce ne sont pas des exploits, hein, mais juste des fonctions parfaitement légitimes de programmes installés partout, et qui dans le bon contexte (genre un bit SUID oublié, qui fait tourner un binaire avec les droits du propriétaire, souvent root) permettent de spawner un shell, lire un fichier protégé, ou grimper d'un cran dans la hiérarchie des privilèges. Petit rappel quand même, faut déjà avoir un pied sur la machine, ce n'est pas une porte d'entrée magique depuis Internet.
Une fois sur leur site, vous tapez le nom d'un binaire dans le moteur de filtre (ou vous cliquez sur une fonction), et hop, vous tombez sur les commandes exactes à recopier-coller, et c'est plié en moins de dix secondes.
Par exemple, si votre cible a un sudo find sans mot de passe, le site vous donne sur un plateau d'argent sudo find . -exec /bin/sh \; -quit.
Un mawk qui tourne en SUID root ? Direct, mawk 'BEGIN {system("/bin/sh")}' et bonjour le shell privilégié. Un vim mal configuré (compilé avec le support Python ou Lua, ce qui est le cas dans la plupart des distros desktop) ? La page documente comment l'utiliser via :py ou :lua pour exécuter du code arbitraire et retomber sur ses pattes.
C'est donc la fin des recherches désespérées sur StackOverflow à 3h du matin pendant un CTF...
La philosophie de ce projet est claire... on ne casse rien, on détourne juste l'usage prévu. Le hic, c'est que la frontière entre détournement et exploitation est mince quand un sudoers mal écrit donne accès à un binaire trop puissant.
Les 478 binaires sont rangés selon 11 fonctions et 4 contextes d'exécution. Côté fonctions, vous avez : Shell (228 binaires permettent de spawner un shell, oui presque la moitié du catalogue), File-read (199), File-write (84), Inherit (71), Upload (34), Download (32), Command (30), Reverse-shell (21), Privilege-escalation (14), Library-load (11), et Bind-shell (7). Côté contextes : Unprivileged, Sudo, SUID, et Capabilities.
Et sur la page d'un binaire, chaque case du tableau vous dit super clairement "voilà comment t'en sors selon ce que tu as sous la main".
Les champions toutes catégories ce sont les langages interprétés et les shells eux-mêmes. zsh, socat, ruby, python, php, node, lua plus bash, tous cumulent 7 fonctions différentes chacun. C'est logique, dès que vous avez un interpréteur sous la main vous pouvez faire à peu près tout (lire, écrire, exécuter, ouvrir une socket).
D'ailleurs c'est pour ça que les sysadmins paranoïaques tirent une tête bizarre quand on leur dit qu'on a installé Python sur un serveur de prod sans cas d'usage explicite. Pfff... je les comprends, un Python qui traîne sur un serveur Debian avec un sudo NOPASSWD au-dessus, c'est game over en trois lignes.
Y'a un autre détail que je trouve cool également, c'est l'intégration
MITRE ATT&CK
. Chaque fonction du site est mappée à une technique du framework officiel, accessible via /mitre.json.
Donc pour les blue teams qui veulent justifier une règle de détection en réunion, c'est tout simplement cadeau !! Et pour ceux qui automatisent leurs scans, l'API JSON complète est dispo sur /api.json, du coup vous pouvez parser les 478 entrées avec un jq ou un petit script Python pour générer des règles de monitoring custom.
Bref, GTFOBins c'est aussi un cadeau pour les défenseurs, à condition de retourner la logique du projet. Voilà, ça vaut le coup d'y passer dix minutes par mois sur un audit.
Pour les Windowsiens qui se sentent oubliés, sachez que l'équivalent existe et s'appelle LOLBAS (Living Off The Land Binaries And Scripts), bien suivi par les analystes Windows depuis 2018. Même philosophie, même format, même utilité, juste appliqué aux exécutables Microsoft signés que Windows installe par défaut.
Les deux projets se citent mutuellement et forment ensemble la cartographie communautaire des techniques de Living Off The Land cross-OS. Si vous bossez sur les deux côtés du fossé, gardez les deux onglets ouverts en permanence ^^ !
Maintenant si l'angle élévation de privilèges via shell restreint vous intéresse, j'avais déjà couvert une vieille faille sudo qui permettait carrément de sortir d'un chroot , et plus largement la bibliothèque Payloads All The Things qui complète bien GTFOBins sur tout ce qui est exploitation web et post-exploitation. Les deux projets sont complémentaires, GTFOBins se concentre sur les binaires Unix et les abus locaux de fonctionnalités légitimes (shells, transferts, lectures, élévation conditionnelle), PayloadsAllTheThings ratisse plus large côté exploitation web.
Côté admin, le réflexe utile, à vrai dire c'est de lister vos binaires SUID avec find / -perm -4000 -type f 2>/dev/null, vérifier /etc/sudoers plus les fichiers /etc/sudoers.d/* avec sudo -l, puis de passer chaque candidat dans le filtre GTFOBins.
Si une entrée matche, c'est qu'il y a une fuite potentielle à boucher. Attention quand même, l'absence dans GTFOBins ne valide pas une règle sudo ou un SUID custom (wildcards, variables d'env, paths inscriptibles peuvent toujours créer un chemin d'évasion). Bref, c'est à faire avant de filer le moindre sudo NOPASSWD à quelqu'un !
L'interface web de Proxmox (l'outil de virtualisation que tout bon homelabber connaît), c'est bien... pour UN serveur. Dès que vous commencez à empiler les nodes et les clusters, ça devient vite le bazar avec 15 onglets ouverts. PegaProx , c'est tout simplement un dashboard open source qui unifie tout ça dans un seul écran. Et vous allez voir, le truc cool, c'est que ça gère aussi les clusters XCP-ng !
L'interface de PegaProx - une vue unifiée de tous vos clusters Proxmox et XCP-ng
Concrètement, vous branchez tous vos hyperviseurs sur cette interface web (port 5000) et hop, vous avez la vue complète. VMs, conteneurs, métriques de perf... tout remonte en temps réel via Server-Sent Events. Du coup, plus besoin de jongler entre les interfaces de chaque node pour savoir quel serveur rame.
Côté fonctionnalités, accrochez-vous les amis parce que pour une beta, c'est déjà bien garni ! Migration live de VMs entre nodes, gestion du stockage Ceph, consoles navigateur via noVNC et xterm.js, et même de la migration cross-hypervisor entre ESXi, Proxmox VE 8.0 et XCP-ng (encore expérimental côté ESXi, mais ça avance). Y'a aussi des règles d'affinité pour placer vos VMs, du rolling update avec évacuation automatique, et des alertes sur les seuils CPU/RAM/disque. Pour une beta, c'est assez dingue ce qu'ils ont déjà mis dedans.
Côté sécurité, c'est pas en reste non plus. Y'a du RBAC avec 3 rôles (Admin, Operator, Viewer, pas plus pas moins), du TOTP pour le 2FA, de l'intégration LDAP et OIDC compatible Active Directory, Entra ID, Keycloak ou Google Workspace, du chiffrement AES-256-GCM pour stocker les credentials en base, et même du scan de CVE via debsecan. Autrement dit, ils ont pensé aux admins sérieux. Pour ceux qui ont déjà configuré un provider OIDC sur leur homelab , ça se branche directement.
Pour l'installer, le plus simple c'est Docker. Un docker compose up -d, 30 secondes d'attente, et c'est plié.
Mais y'a aussi un script de déploiement automatique, un repo APT communautaire maintenu par gyptazy, ou le classique git clone + pip pour les puristes. Une fois lancé, vous pointez votre navigateur sur https://votre-ip:5000, et un assistant vous accueille avec les identifiants par défaut (pegaprox/admin, à changer immédiatement bien sûr). L'interface est dispo en 5 langues : français, anglais, allemand, espagnol et portugais.
D'ailleurs, si vous utilisez déjà ProxMenux pour administrer votre Proxmox en terminal, les deux sont en fait complémentaires. Disons que ProxMenux couvre l'admin système en ligne de commande, alors que le dashboard apporte la vue unifiée multi-clusters en web. Initialement j'aurais dit que c'était redondant, mais non, ça se marie plutôt bien. Et y'a même un système de plugins avec un portail client pour vos utilisateurs et une page de statut publique à la StatusGator.
Attention c'est comme je vous le disais, encore une beta. L'OIDC avec Authentik par exemple, ça fonctionne pour le login mais les groupes ne remontent pas encore correctement (retour d'un lecteur qui l'utilise au quotidien).
Par contre si vous n'avez qu'un seul serveur Proxmox, honnêtement c'est un peu overkill, l'interface native suffit largement. Quelques glitchs traînent ici ou là, et l'API Token pour se connecter à la place de root n'est pas super bien documenté. Mais le projet avance vite donc c'est plutôt bon signe !
Bref, ça promet pas mal. Merci à Maxime pour la découverte !
Linus Torvalds a officialisé Linux 7.0 le 12 avril, et le passage à la version 7 a d'ailleurs été expliquée. Torvalds a dit dans son mail de release qu'il préférait simplement incrémenter le numéro majeur quand les mineures dépassaient la dizaine, histoire de ne pas se retrouver avec un Linux 6.23. Pas de révolution philosophique, juste du bon sens de mainteneur donc.
Derrière cette numérotation, le noyau embarque quand même un paquet de nouveautés qui vont directement impacter les utilisateurs AMD, Intel et ARM64, sans parler d'une petite révolution côté système de fichiers XFS.
La grosse annonce, c'est surtout le nouveau daemon xfs_healer, géré par systemd, qui surveille en temps réel les erreurs de métadonnées et les I/O fautifs. Quand il détecte un problème, il déclenche automatiquement la réparation pendant que la partition reste montée et utilisée, ce qui évite de démonter, de booter sur un live USB ou de croiser les doigts pendant un xfs_repair manuel.
Pour un serveur en prod, c'est énorme. XFS rattrape (et dépasse) ce que Btrfs et ZFS proposaient depuis des années sur ce terrain.
Côté Intel, les TSX (Transactional Synchronization Extensions) sont activées par défaut. Sur un CPU 10e génération ou plus récent, ça donne un léger boost sur les charges multithread. Le support de Nova Lake progresse aussi, et le noyau intègre les premiers bouts de Crescent Island, l'accélérateur IA maison d'Intel qui vise les datacenters.
AMD n'est pas oublié, avec de nouveaux blocs IP graphiques activés pour les futures Radeon. Côté ARM64, le kernel gère désormais les chargements et stockages atomiques de 64 octets, un ajout bas niveau qui profitera aux workloads concurrents. Et pour les amateurs de cartes ARM, le décodage vidéo matériel arrive sur toute une série de single-board computers Rockchip.
Ubuntu 26.04 LTS tournera sur Linux 7.0, donc tous les réglages de performance et de stabilité apportés par ce noyau seront directement exploités dans la prochaine LTS. Du coup, choisir Ubuntu cette année a du sens si vous avez du matos récent.
Dans son message de release, Linus évoque aussi la place grandissante de l'IA dans l'écriture de patches noyau. Il ne tranche pas, il observe. On sent qu'il y réfléchit sans vouloir se mouiller pour l'instant.
Bref, pas de révolution, mais le XFS auto-réparant justifie l'upgrade à lui seul pour qui tient vraiment à ses données.
Source : Techspot
Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.
Enfin !
Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.
D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.
Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers
USBGuard
pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !
Mais alors pourquoi lancer ça maintenant ?
Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.
Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme
USBRip
(un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.
On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !
Bref, va falloir garder un œil là-dessus.
