Les boîtiers KVM IP, c'est le genre de matos qu'on branche dans un rack et qu'on oublie dans un coin pendant des années. Hé bien va falloir vous souvenir de où vous les avez mis les copains parce que des chercheurs d'Eclypsium viennent de retourner de fond en comble 4 modèles populaires... et c'est pas joli joli. A l'intérieur il y on trouvé pas moins de 9 failles, dont une qui score à 9.8 sur 10 en gravité CVSS. Autant dire qu'on n'est plus dans le "petit bug rigolo oh oh" qui fait marrer votre admin sys.

Pour ceux qui débarquent, ces petits appareils dont l'acronyme veut dire "Keyboard Video Mouse", permettent de contrôler un serveur à distance via le réseau, clavier, souris et écran compris, comme si vous étiez physiquement devant la machine. Hyper pratique donc pour gérer un homelab ou une salle serveur, et ça coûte entre 50 et 200 euros sur Amazon. Du coup, y'en a partout !!!

Les chercheurs Paul Asadoorian et Reynaldo Vasquez Garcia ont passé au crible le GL-iNet Comet RM-1, le JetKVM, le Sipeed NanoKVM et l'Angeet ES3 et ça fait mal : authentification manquante sur des fonctions critiques, injection de commandes OS, ports UART qui filent un accès root direct, et des firmwares qu'on peut remplacer sans aucune vérification de signature. En gros, c'est la fête du slip côté sécu !

Le truc vraiment relou avec ce type d'appareils, c'est qu'en fait ils opèrent en dessous de votre OS. Pas d'antivirus, pas d'EDR, rien ne les voit. Un attaquant qui compromet votre switch de contrôle distant peut alors injecter des frappes clavier, booter depuis une clé USB (bye bye le chiffrement de disque et le Secure Boot), contourner l'écran de verrouillage, et planquer une backdoor directement dans le firmware du boîtier. Tout ça sans que votre machine ne bronche car un KVM compromis, c'est pas un stupide gadget IoT de plus sur votre réseau... Là je vous parle vraiment d'un accès direct et silencieux à toutes les machines qu'il contrôle.

Et c'est pas juste théorique puisqu'en 2025, des travailleurs nord-coréens infiltrés dans des boîtes américaines utilisaient des PiKVM et TinyPilot pour contrôler à distance les laptops d'entreprise depuis des "laptop farms". Voilà le genre de scénario qu'on rend possible quand le firmware n'a même pas de signature. C'est un peu comme ces caméras IoT bourrées de failles sur lesquelles un chercheur faisait tourner DOOM... sauf qu'ici, l'attaquant prend le contrôle de vos serveurs, pas d'un flux vidéo.

Et histoire de parfaire le tableau, côté correctifs c'est la jungle intégral !! JetKVM a patché en v0.5.4, Sipeed en v2.3.1, GL-iNet promet un fix en v1.8.1 beta et pour l'Angeet ES3, qui cumule les 2 failles les plus sévères (scores 9.8 et 8.8), y'a aucun correctif prévu. Oupsy oups...

Donc si vous avez un de ces boîtiers qui traîne, voilà ce qu'il faut faire. D'abord isolez-le sur un VLAN de management dédié (jamais sur le réseau principal), coupez-lui l'accès Internet, activez le MFA si c'est supporté, et vérifiez que votre appareil n'est pas exposé publiquement via un scan de votre IP. Mettez également le firmware à jour, sauf si c'est un Angeet... là, franchement, faut débrancher.

Bref, si vous avez un de ces machins dans votre rack, traitez-le comme un point d'accès critique... parce que c'en est un !

Source

Telnet en big 2026... bah oui ça existe encore les amis ! Et surtout c’est toujours aussi troué ! J'en veux pour preuve le daemon telnetd de GNU InetUtils qui vient de se prendre une 2ème faille critique en l’espace de deux mois, et celle-là, elle pique de fou !

Il s'agit de la CVE-2026-32746 , elle permet d’obtenir un shell root sur n’importe quel serveur Linux ou BSD exposant le port 23, et l’attaque se fait avant même que le prompt de login n’apparaisse. Pas besoin de mot de passe, pas besoin de compte. Juste une bonne vieille connexion TCP et un paquet SLC malformé et c'est parti mon kiki !

En fait, le bug se planque dans le handler SLC (Set Local Characters) du code source C de telnetd. Ainsi, quand un client ouvre une socket TCP sur le port 23, y’a une phase de négociation d’options avant l’authentification. L’attaquant envoie alors un paquet SLC contenant un nombre anormal d'octets, et ça déclenche un buffer overflow de type out-of-bounds write dans la mémoire du processus. Et boom, exécution de code arbitraire avec les privilèges root ! Et ça, ça donne un score CVSS de 9.8 sur 10 soit quasi la note maximale !

Toutes les versions de GNU InetUtils telnetd jusqu’à la 2.7 sont touchées. Toutes vulnérables, et pour le moment, aucun patch n’est disponible à ce jour. C’est la boîte de cybersécurité israélienne Dream, via son chercheur Adiel Sol, qui a découvert le pot aux roses et publié l’advisory le 11 mars dernier. Le patch officiel du mainteneur GNU est attendu pour le 1er avril (et non, c’est pas un poisson).

Ça craint surtout qu'il y a à peine 2 mois, une autre faille critique dans le même daemon, la CVE-2026-24061 (aussi scorée 9.8), avait déjà été divulguée. Et celle-là, la CISA l’a depuis ajoutée à son catalogue de vulnérabilités activement exploitées dans la nature. Ça me rappelle carrément la faille RCE dans cups-browsed l’an dernier... Ces vieux services réseau, c’est dingue comme ça revient régulièrement.

systemctl stop telnet.socket && systemctl disable telnet.socket

iptables -A INPUT -p tcp --dport 23 -j DROP

Faut le reconnaître, la doc et qui plus est, la doc réseau, c'est un peu le parent pauvre du homelab. Tout le monde sait qu'il faudrait la tenir à jour sur un petit wiki tout mignon mais personne le fait parce qu'on n'est pas cinglé et qu'on aime trop la vie pour ça. Heureusement, pour nous aider, y'a maintenant Scanopy qui est un outil open source qui scanne automatiquement votre réseau pour générer une topologie interactive incroyable qui se met à jour toute seule !

Pour l'installer, deux lignes suffisent :

curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
docker compose up -d

Le chiffrement complet du disque, tout le monde vous dit que c'est la base. LUKS sous Linux, BitLocker sous Windows, FileVault sous macOS... sauf que personne vous dit quoi faire quand votre serveur reboot à 3h du mat et qu'il attend sagement sa passphrase.

Là, vous êtes coincé !!!!

Parce que oui, le truc vicieux avec le chiffrement intégral, c'est qu'au démarrage, le système ne peut pas lire le disque tant que vous n'avez pas tapé le mot de passe. Du coup, si votre machine est dans un datacenter ou chez un hébergeur, ben... faut se déplacer physiquement. Et ça c'est bien relou !!!

La solution, c'est d'embarquer un serveur SSH directement dans l' initramfs (oui, le mini OS qui tourne AVANT votre vrai système, sur le port 22). En gros, votre machine boot, charge l'initramfs, lance un serveur SSH... et vous n'avez plus qu'à vous connecter à distance pour taper la passphrase. Comme ça le disque se déverrouille et le boot continue. Voilà quoi, c'est simple la vie quand on lit Korben.info !! loool

L'initramfs, c'est quoi exactement ?

Alors pour ceux qui débarquent, l'initramfs c'est une archive compressée dans /boot/initramfs-linux.img qui contient un système Linux minimal. Son boulot, c'est de préparer le terrain avant de passer la main au vrai OS, genre charger les modules noyau, détecter le matériel, monter les systèmes de fichiers... et dans notre cas, demander la passphrase LUKS. Genre un second OS, mais en version bonsaï !

Installer Dropbear dans l'initramfs

Dropbear , c'est un serveur SSH ultra-léger (environ 110 Ko) parfait pour l'initramfs. L'article de jyn qui m'a inspiré pour cet article , recommande Arch Linux avec mkinitcpio, mais sachez que sous Debian/Ubuntu le paquet dropbear-initramfs fait le même boulot avec update-initramfs.

Sur Arch, vous installez mkinitcpio-systemd-extras puis vous modifiez /etc/mkinitcpio.conf pour ajouter les hooks réseau et Dropbear :

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck systemd-network dropbear)

Attention, l'ordre des hooks compte. Le réseau doit être configuré AVANT Dropbear, sinon votre serveur SSH démarre sans interface réseau. Pas super utile donc !

Configurer le réseau dans l'initramfs

Ensuite faut créer un fichier de config réseau dans /etc/systemd/network-initramfs/. En fait, c'est du systemd-networkd classique, donc si vous avez déjà configuré ça, c'est pareil. Un simple fichier .network avec DHCP fait le job en Ethernet (et pour un serveur, c'est clairement recommandé). Pour les plus paranos, une IP statique marche aussi, sauf que faudra pas oublier de la mettre à jour si vous changez de réseau.

La touche Tailscale

Après si votre serveur est derrière un NAT ou un firewall, bah... le SSH classique ne passe pas. Du coup, jyn a eu la bonne l'idée d'embarquer Tailscale dans l'initramfs aussi. Comme ça, la machine rejoint votre réseau privé Tailscale dès le boot, même avant le déchiffrement du disque.

Vous lancez setup-initcpio-tailscale, ça vous donne un lien d'authentification sur login.tailscale.com et c'est réglé. Après faut penser à configurer les ACL Tailscale pour que SEULE votre machine d'admin puisse se connecter à l'initramfs car OUI ON NE LAISSE PAS UN PUTAIN DE SSH ouvert sur un système pré-boot sans protection, HEIN ?? HEIN ?? Donc faites ça !!

Les précautions de sécurité

Vous vous en doutez, y'a quand même quelques pièges à éviter. D'abord, les clés SSH de Dropbear dans l'initramfs (stockées dans /etc/dropbear/) doivent être DIFFÉRENTES de celles d'OpenSSH dans /etc/ssh/. Parce que l'initramfs n'est pas chiffré (bah oui, il doit tourner avant le déchiffrement), donc ces clés sont techniquement accessibles à quelqu'un qui a un accès physique au disque.

Ensuite, attention, limitez ce que Dropbear peut faire. Pas de shell complet, juste la commande systemd-tty-ask-password-agent qui sert uniquement à taper la passphrase. Comme ça, même si quelqu'un arrive à se connecter, il ne peut rien faire d'autre.

Et désactivez aussi l'expiration des clés Tailscale pour la machine initramfs via --auth-key avec un token non-éphémère, sinon votre serveur va se retrouver éjecté du réseau au pire moment.

Reconstruire et tester

Une fois tout configuré, un petit mkinitcpio -P pour reconstruire l'initramfs et c'est bon. Si ça ne marche pas du premier coup, vérifiez les logs avec journalctl -b. Mais attention, testez ça sur une VM ou une machine avec accès console (IPMI, iDRAC, KVM-over-IP) d'abord, parce que si le réseau de l'initramfs ne monte pas, votre serveur devient une brique inaccessible... et là, c'est le vrai drame de votre vie qui commence (et la découverte de France Travail) !

Au prochain reboot, votre serveur va donc démarrer, charger l'initramfs, se connecter à Tailscale, lancer Dropbear... et attendre patiemment que vous tapiez la passphrase depuis votre canapé.

Si vous gérez des serveurs chiffrés à distance, c'est le genre de setup un peu touchy à la base mais qui change la vie. Comme ça, plus besoin de supplier / soudoyer / menacer (chacun sa technique) le technicien du datacenter d'astreinte de brancher un clavier ^^.

Découvrir le tuto complet de Jyn ici !

Si vous bossez sur des serveurs distants, vous connaissez cette douleur... D'un côté, vous avez votre terminal local aux petits oignons, vos alias, vos plugins... et hop, un petit ssh root@serveur et vous vous retrouvez avec un shell tout pourri, tout basique. Mais c'était sans compter sur Joknarf qui a pondu TheFly , un gestionnaire de plugins shell qui téléporte votre environnement via SSH ou sudo en un instant.

Le principe est pas bête du tout vous allez voir. En fait, vous installez vos plugins et dotfiles dans ~/.fly.d/ sur votre machine, et quand vous lancez flyto user@serveur, tout est empaqueté et envoyé dans /tmp/.fly.$USER/ distant. Prompt perso, alias, fonctions... tout débarque avec vous, un peu comme un sac à dos pour votre shell.

Et le truc bien, c'est que ça ne modifie RIEN sur le serveur distant car tout vit dans /tmp, donc quand vous vous déconnectez... pouf, tout a disparu. Pas de fichier qui traîne, pas de .bashrc modifié donc c'est plutôt safe pour les environnements de prod où vous ne voulez pas laisser de traces.

Ça marche avec bash, zsh et même ksh (pour les nostalgiques). L'installation, c'est un curl en une ligne (à relire comme d'hab), ou alors brew, dnf, paquets .deb... y'a le choix. C'est du pur shell POSIX, donc y'a ZÉRO dépendance externe. Attention par contre, si votre ~/.fly.d/ dépasse 128 Ko, ça risque de ramer sur des connexions un peu lentes.

Ah et y'a aussi flyas pour faire pareil en sudo (attention, ça téléporte aussi vos plugins, donc vérifiez que ça colle avec votre politique de sécu), et flysh pour switcher de shell sans perdre vos réglages. Et puis flypack génère une archive auto-extractible pour avoir un script shell qui s'installe tout seul. Pas mal donc aussi pour partager votre config.

Côté plugins, c'est pas Oh My Zsh avec ses 350+ plugins, mais y'a l'essentiel. Un prompt custom (nerdp), un historique amélioré (redo), de la navigation de répertoires (seedee)... et shell-ng qui regroupe le tout d'un coup. Perso, c'est bien suffisant je trouve.

D'ailleurs si vous êtes du genre à customiser votre shell au millimètre, TheFly s'intègrera bien dans votre workflow. En plus c'est sous licence, open source, et ça tourne sur Linux, macOS et même SunOS (bon ok, je sais, quasi personne utilise SunOS en 2026 mais bon...).

Voilà, comme ça si vous gérez une dizaine de serveurs au quotidien, ça vous fera gagner un paquet de temps !

Amusez-vous bien !

Vous avez vu le bazar chez VMware depuis que Broadcom a racheté la boîte ? Les prix qui flambent, les licences qui changent tous les quatre matins, les clients historiques qui reçoivent des factures multipliées par je sais pas combien... C'est la panique générale dans les DSI !

Et pendant ce temps-là, y'a une boîte française basée à Grenoble qui se frotte les mains. Pas par schadenfreude hein, mais parce qu'ils bossent depuis 2012 sur une alternative open source à VMware. Vous l'aurez compris, je parle de Vates et de leur stack complète baptisée Vates VMS.

J'ai donc eu l'occasion de mettre les mains dans le cambouis avec leur lab de test la semaine dernière. Ils m'ont prêté 3 serveurs HPE Moonshot rien que pour moi, avec accès VPN, et carte blanche pour faire mumuse. J'avoue, au début je pensais galérer avec la config réseau... Eh bah non. J'installe XCP-ng en une dizaine de minutes, je configure le VLAN qui va bien, et c'est parti.

Mais avant, je vous propose de poser un peu les bases pour ceux qui débarquent. Vates VMS, c'est une suite complète qui comprend XCP-ng (l'hyperviseur bare-metal de Type 1, basé sur Xen... oui oui, le même Xen qui fait tourner AWS depuis des lustres) et Xen Orchestra (l'interface web pour tout gérer). Le tout en 100% open source, hébergé par la Linux Foundation.

Et là vous allez me dire "ouais mais open source, c'est souvent la version bridée avec les vraies features payantes". Eh bien non, chez Vates c'est différent ! En fait, tout est dispo gratos sur GitHub. Leur modèle économique repose sur le support et l'accompagnement, et pas sur des licences à la c*n facturées au core ou au socket. Un prix fixe par serveur physique, point barre. Comme ça y'a pas de surprise sur la facture, ni de calculette à sortir quand vous ajoutez de la RAM.

D'ailleurs, ils viennent de sortir Xen Orchestra 6, entièrement réécrit en Vue.js. Et pour l'avoir testé, je peux vous dire que l'interface est vraiment fluide, moderne, et surtout pensée pour qu'on s'y retrouve sans avoir besoin d'un doctorat en VMwarologie. Vous gérez vos VMs, vos backups, vos migrations, votre monitoring... tout ça depuis un navigateur sur n'importe quel OS.

Et y'a même XO Lite, une version ultra-légère embarquée directement dans XCP-ng pour les opérations de base. Bon, faut pas s'attendre à tout gérer avec ça car c'est vraiment pour le dépannage quand vous n'avez pas accès au serveur principal. Mais c'est pratique quand vous êtes en déplacement et qu'il faut redémarrer une VM en urgence.

Pour les boîtes qui veulent se barrer de VMware, ils ont également développé des outils de migration V2V. Ça fonctionne pour 90% des usages VMware existants (attention quand même aux configs exotiques avec du vSAN ou des plugins proprio, là faut prévoir un peu plus de boulot). Et l'architecture est suffisamment proche de VMware pour que la transition se fasse sans tout réinstaller from scratch.

Côté fonctionnalités avancées, y'a également XOSTOR pour ceux qui veulent faire de l'hyperconvergence. C'est leur SAN virtuel basé sur DRBD qui transforme vos disques locaux en stockage partagé avec réplication et haute disponibilité. Comme ça, plus besoin de SAN externe hors de prix, puisque vos serveurs XCP-ng deviennent un cluster de stockage distribué.

Pour les DevOps, c'est aussi la fête ! Terraform, Pulumi, Ansible, API REST, CLI... tout y est. J'ai pas eu le temps de tester Terraform en profondeur, mais le provider XO existe bien sur le registry HashiCorp. Ils ont même un projet Pyrgos pour déployer Kubernetes directement depuis Xen Orchestra. Bref, c'est cloud-native ready.

Perso, ce qui m'a vraiment convaincu durant mes tests, c'est qu'on n'a pas 15 outils différents avec lesquels jongler. J'ai bien sûr testé la création de VM, les snapshots, les backups incrémentaux... tout passe par la même interface. Un seul éditeur qui maîtrise toute la stack, de l'hyperviseur jusqu'aux sauvegardes, c'est quand même le kiff. Sans oublier la doc qui est claire comme de l'eau de roche et le support répond vraiment (enfin pour ceux qui prennent un contrat, sinon y'a la communauté qui est plutôt active sur le forum).

Côté références, ils ont plus d'un millier de clients dans le monde entier. Même la NASA utilise les outils de Vates (hé ouais quand même, c'est la classe !), sans oublier des universités, des hôpitaux, l'ANSSI... C'est du sérieux !

Et pour les administrations françaises qui doivent passer par les marchés publics, Vates est référencé chez CAIH, CANUT et UGAP. Du coup pas besoin de monter un appel d'offres complexe, vous pouvez commander directement via les catalogues. Et si vous vous demandez comment ça se compare à ESXi ou à Proxmox , sachez que l'architecture est vraiment proche de VMware (donc migration facilitée), mais avec la philosophie open source en plus.

Alors oui, c'est un article sponsorisé, mais sincèrement si vous êtes sur VMware et que vous regardez vos factures arriver avec des sueurs froides depuis le rachat par Broadcom, ça vaut vraiment le coup de jeter un œil. C'est français, c'est open source, c'est maintenu par une équipe d'une centaine de personnes et ça fait très bien le taf.

Y'a même un essai d'un mois pour tester avant de se décider, histoire de ne pas acheter chat en poche (oui c'est une vraie expression du XVe siècle que je viens de découvrir alors je vous la transmets, faites en bon usage).

Bref, si la souveraineté numérique et l'indépendance technologique c'est votre truc (ou si vous en avez juste marre de vous faire racketter), allez voir ce qu'ils proposent , c'est top !

Proxmox, c'est génial pour la virtualisation... sauf que configurer des VMs, des conteneurs LXC, le GPU passthrough et les sauvegardes à la main, ça finit par nous coller de grosses cernes sous les neuneuils ! Trop de commandes les amis !! Heureusement, un dev a eu la bonne idée de tout coller dans un menu interactif bash !

ProxMenux , c'est donc un outil open source qui vous ajoute une commande menu dans le terminal de votre serveur Proxmox. Vous tapez ça et vous avez alors un joli menu en mode texte qui vous propose toutes les opérations courantes sans avoir à retenir 45 commandes différentes. Et c'est compatible Proxmox VE 8.x et 9.x.

L'installation tient en une seule ligne bash.

bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)"