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 :

services:
 termix:
 image: ghcr.io/lukegus/termix:latest
 ports:
 - "8080:8080"
 volumes:
 - termix-data:/app/data

volumes:
 termix-data:

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 !

Source

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.

Source

Quand on gère un serveur, y'a un truc qui rend dingue, c'est le bruit de fond de ces dizaines de milliers d'IPs qui scannent vos ports, qui tentent du bruteforce sur le port 22, qui cherchent des failles WordPress ou des phpMyAdmin oubliés... et surtout qui font tourner Fail2ban à plein régime dans les logs pour stopper ce qui peut l'être.

Fail2ban est d'ailleurs hyper réactif mais il attend qu'une IP fasse une connerie dans vos logs Apache ou SSH avant de la bloquer. Donc c'est quand même un peu tard.. Alors si on pouvait carrément virer le gros du trafic pourri avant même qu'il arrive à nos services ? Ce serait pas mieux ?

Hé bien c'est exactement ce que fait Data-Shield IPv4 Blocklist , un projet open source qui maintient une liste d'environ 100 000 adresses IP identifiées comme malveillantes. Le principe est simple... on colle l'URL RAW de la liste dans la config de son firewall (genre dans les alias d'OPNsense ou les External Block Lists de Fortinet) et hop, tout ce beau monde est filtré au niveau périmétrique. La liste (un simple fichier texte avec une IP par ligne) est rafraîchie toutes les 6 heures avec une fenêtre de rétention de 15 jours, du coup les IPs qui ne sont plus actives finissent par sortir automatiquement.

Côté compatibilité, c'est plutôt large : OPNsense, Fortinet, Palo Alto, F5 BIG-IP, Stormshield, Synology NAS, BunkerWeb... donc clairement, la plupart des pare-feu et WAF du marché peuvent ingérer la liste directement via une URL. Et pour les équipements un peu anciens qui ont des limites sur le nombre d'entrées, y'a même des listes splittées en paquets de 30 000 IPs.

Le projet est maintenu depuis 2023 par Duggy Tuxy, un CISO qui a visiblement décidé que ses week-ends aussi seraient consacrés à la threat intelligence. Presque déjà 4 000 commits sur le dépôt Git, soit des mises à jour quasiment tous les jours. Et c'est impressionnant car le taux de faux positifs affiché est de moins de 2 par mois, ce qui franchement, pour une liste de cette taille, est plutôt fou.

D'ailleurs, si vous utilisez déjà FireHOL pour vos listes de blocage, Data-Shield peut très bien venir en complément. L'idée c'est d'empiler les couches de défense... blocklist périmétrique au niveau iptables ou nftables en première ligne, puis CrowdSec ou Fail2ban pour le trafic qui passe quand même. Un défense en profondeur donc !

Attention par contre, la liste est pensée uniquement pour le trafic entrant (WAN vers LAN). L'appliquer en sortie bloquerait vos propres connexions légitimes. Et sauf si votre firewall gère le rechargement dynamique, pensez également à automatiser le refresh via un cron toutes les 6 heures.

Et pour assurer une haute disponibilité, le projet est distribué sur 5 miroirs : GitHub, GitLab, jsDelivr CDN, BitBucket et Codeberg. Du coup même si une source tombe, vos firewalls continuent à se mettre à jour.

Bref, si vous cherchez à réduire le bruit sur vos serveurs sans vous prendre la tête, allez, c'est gratuit, c'est sous licence GPLv3 et ça se configure en 2 minutes. Merci à Duggy Tuxy pour le tuyau !

Faut le reconnaitre, 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 DNS, c'est un peu la tuyauterie planquée d'Internet. Tout le monde l'utilise, mais personne ne regarde vraiment ce qui se passe dans les tuyaux... jusqu'à ce que ça pète ou qu'un petit con s'en serve pour exfiltrer des données. Et là, bon courage pour fouiller dans les logs en mode brutasse pour comprendre qui a fait quoi sur votre réseau.

En fait, pour ceux qui se demandent encore qu'est-ce que le DNS (Domain Name System), c'est simplement l'annuaire qui traduit les noms de domaine comme korben.info en adresses IP. Sans lui, on serait tous en train de mémoriser des suites de chiffres à la con.

Et il y a quelques jours, j'ai reçu un mail de Denis, un fidèle lecteur (qui traîne sur le blog depuis 2005, ça nous rajeunit pas !) qui m'a écrit pour me présenter son projet sur lequel il bosse depuis 5 ans : DNS-collector .

DNS-collector, c'est un outil écrit en Go qui sert de "chaînon manquant" entre vos serveurs DNS et votre pile de données. En gros, il capture le trafic DNS, le nettoie, l'enrichit et l'envoie là où vous en avez besoin. C'est l'outil parfait pour ceux qui ont la flemme de se palucher des fichiers PCAP de 4 Go à la main ou de debugger des flux DNStap illisibles.

Le point fort de DNS Collector, c'est sa flexibilité. Côté entrées, ça avale tout : du DNStap via socket Unix ou TCP (le protocole standard utilisé par BIND, Unbound ou PowerDNS), du sniffing réseau classique avec AF_PACKET ou même XDP pour la très haute performance. Attention quand même, pour XDP, apparemment le kernel Linux doit être récent (version 5.x minimum) et les drivers réseau doivent suivre, sinon ça va faire pshitt. Ensuite, par défaut, le bousin écoute pépouze sur le port UDP/6000 en attendant ses flux.

Mais là où ça devient vraiment balaise, c'est dans le traitement des données. DNS-collector embarque des "Transformers" (rien à voir avec Optimus Prime hein ^^) qui font tout le boulot ingrat à votre place dans le pipeline de traitement. Hop, ça normalise les noms de domaine en minuscules (le fameux qname-lowercase dans le fichier de config), ça ajoute la géolocalisation via GeoIP (genre MaxMind ou IP2Location), et on peut même détecter les trucs louches.

Il peut aussi détecter le tunneling DNS ou les domaines générés par algorithme (DGA) qui sont souvent les signes d'une infection sur une machine. Petit bémol cependant, pour la géolocalisation, pensez à télécharger vos bases GeoIP au préalable (fichiers .mmdb), sinon l'outil va vous faire une petite grimace au démarrage.

Vous pouvez aussi protéger la vie privée de vos utilisateurs en anonymisant les adresses IP via un hachage SHA1 ou du masquage. C'est propre, ça respecte le RGPD, et ça permet de garder des stats utiles (genre le top des ASN consultés) sans fliquer tout le monde. Les données sortent proprement en JSON ou en Protobuf, prêtes à être ingérées.

Une fois que vos données sont propres, vous les envoyez où vous voulez. J'ai choisi de vous citer ClickHouse ou InfluxDB car c'est parfait pour stocker des millions de requêtes sans mettre votre serveur à genoux, mais la liste est longue : Prometheus pour les métriques, ElasticSearch, Kafka, Redis, ou même Slack via des webhooks pour être alerté en temps réel quand un domaine louche pointe le bout de son nez.

Alors si ça vous chauffe, comment récupérer cet outil et le mettre en place ?

Hé bien c'est hyper fastoche comme d'hab puisque le projet est dispo en binaire ou via Docker. Ensuite, vous lancez la commande ./dnscollector -config config.yml, vous branchez vos sources, et roule ma poule. Taaadaaaa ! DNS-collector s'occupera du reste sans vous bouffer toute votre RAM (contrairement à certaines usines à gaz Java qui demandent un sacré paquet de mémoire vive ^^).

Voilà, perso, je trouve l'approche très saine. C'est léger, modulaire et ça répond à un vrai besoin pour les admins sys qui veulent enfin "voir" ce qui transite par leurs serveurs. Le bousin encaisse des milliers de requêtes par seconde sans broncher... enfin sauf si votre serveur est une patate de 2012, là je garantis rien.

Mortecouille, c'est quand même mieux d'avoir des logs lisibles avec un simple tail -f /var/log/syslog, non ? Et d'ailleurs, le projet est déjà adopté par pas mal d'acteurs de la sécu, donc vous pouvez y aller sereinement.

Merci Denis !

Aujourd'hui, on va aller un peu plus loin que les simples bidouilles habituelles car je vais vous présenter Reinstall , un outil qui va peut-être vous changer la vie si vous gérez des serveurs distants.

Vous connaissez la chanson... vous avez un VPS sous Debian et vous voulez passer sous Arch pour faire votre malin. Sauf que pour opérer ce changement, c'est la galère assurée !! Faut passer par l'interface web de l'hébergeur, booter sur une ISO via une console VNC qui rame sa maman, et prier pour que le réseau revienne après le reboot.

Eh bien ça c'est terminé grâce à ce script Reinstall. Vous lui balancez une commande, le script s'occupe de tout, et hop, votre serveur redémarre sur le nouvel OS de votre choix. Pas besoin d'accès IPMI, pas besoin de supplier le support technique, ça marche tout seul.

Et ça supporte pas mal d'OS... Côté Linux, y'a 19 distributions majeures : Alpine, Debian (de 9 à 13), Ubuntu (de 16.04 à 25.10), toute la famille Red Hat (AlmaLinux, Rocky, Oracle), Fedora, Arch, Gentoo, NixOS... Bref, y'a tout ce qu'il faut.

Et le truc qui va plaire à ceux qui font du cloud, c'est également le support de Windows. En effet, le script permet d'installer Windows Vista, 7, 8.1, 10, 11 et même Windows Server 2025.

Et rassurez-vous, il n'utilise pas des images bricolées par on ne sait qui, mais les ISO officielles de chez Microsoft. Lui se content d'injecter automatiquement les drivers VirtIO pour que ça tourne comme un charme sur n'importe quel cloud (AWS, GCP, Oracle Cloud...).

Aussi, le point le plus chiant quand on réinstalle un serveur distant, c'est la config réseau. Si on se loupe, on perd l'accès SSH et c'est fini. Reinstall gère ça intelligemment puisqu'il détecte votre IP (statique ou dynamique), gère l'IPv6, les passerelles exotiques et même les serveurs ARM.

Ce qu'il vous faut avant de tout casser

• RAM : 256 Mo pour Alpine/Debian, 1 Go pour Windows.
• Disque : 1 Go pour Linux, 25 Go minimum pour Windows.
• Accès : Un accès root/admin sur la machine actuelle.
• Temps estimé : Environ 5 à 15 minutes selon la vitesse de connexion de votre serveur.

Un petit avertissement quand même... Ce script ne gère pas les conteneurs type OpenVZ ou LXC. Faut que ce soit une vraie VM (KVM, VMware, Hyper-V) ou un serveur bare-metal.

Le tuto ! Le tuto !

C'est là que ça devient drôle. Pour installer un nouveau Linux (disons Debian 13) depuis votre système actuel, il suffit de faire un petit :

# Télécharger le script
curl -O https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh

# Lancer la réinstallation
bash reinstall.sh debian 13 --password "VotreMotDePasse"

bash reinstall.sh windows --image-name "Windows 11 Enterprise LTSC 2024" --lang fr-fr