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

"Merde, le port 8080 est squatté par quoi encore ???"

Si vous touchez un peu à l'auto-hébergement ou que vous gérez plus de trois services sur un serveur, vous avez forcément déjà hurlé cette phrase devant votre terminal. C'est le grand classique... on lance un nouveau conteneur, ça plante, et on finit par passer 20 minutes à faire des netstat ou des lsof pour comprendre qui fait la loi sur le réseau. Bref, c'est le bordel, et c'est exactement là que Portracker entre en scène pour nous sauver la mise.

Développé par Mostafa Wahied, Portracker n'est pas un énième scanner de ports réseau agressif façon Nmap, mais plutôt une vigie interne pour vos machines. C'est un outil auto-hébergé qui va scanner son propre hôte pour cartographier en temps réel (enfin, avec un rafraîchissement périodique réglable, généralement toutes les minutes) tous les services qui tournent et les ports qu'ils occupent. L'idée, c'est d'avoir une vue propre et centralisée pour dégager ce vieux tableur Excel que vous oubliez de mettre à jour une fois sur deux.

Le truc est super bien foutu, surtout pour les fans de Docker. Pour ceux qui se demandent comment ça se passe sous le capot, l'outil fait intelligemment la distinction entre les ports internes d'un conteneur et ceux qui sont réellement exposés sur l'hôte.

Alors oui, ça marche comment pour mapper tout ça ? En gros, ça utilise les API natives pour voir que votre instance Ghost est sur le 2368 en interne mais ressort sur le 8080 à l'extérieur. C'est le genre de truc qui évite bien des migraines quand on commence à empiler 50 conteneurs. Il y a même un support aux petits oignons pour TrueNAS pour les amateurs de NAS costauds.

Côté dashboard, c'est du propre puisqu'on est sur une interface moderne avec React, Tailwind et Shadcn UI, avec un mode sombre (évidemment) et des filtres en live qui répondent au quart de tour.

Mais la vraie force de Portracker, c'est sa capacité à bosser en meute. Vous pouvez connecter plusieurs instances entre elles via un système de "Peers" (en peer-to-peer donc) pour tout centraliser sur un seul tableau de bord. Pratique si vous avez un serveur chez vous, un VPS chez OVH et une vieille machine qui traîne dans un placard. Vous pouvez même organiser ça avec une hiérarchie parent-enfant pour mapper vos machines virtuelles sous leurs hôtes physiques respectifs.

Techniquement, c'est du solide mais ça reste léger : du Node.js avec Express et des WebSockets pour le backend, et une base SQLite (via better-sqlite3) embarquée pour ne pas avoir à se fader la conf d'une base externe. Pour le déploiement, ça se passe via Docker et pour les paranos de la sécurité (je vous vois ^^), sachez que l'outil supporte désormais l'utilisation d'un Docker Socket Proxy (genre celui de Tecnativa). Ça permet d'éviter de filer les droits root sur votre socket Docker à n'importe qui. Et depuis la version 1.2.0, vous pouvez même verrouiller l'accès avec une vraie authentification.

Notez que pour fonctionner correctement et aller fouiller dans les entrailles du système, l'outil a besoin de certaines permissions (les fameuses capabilities Linux). Il lui faudra généralement SYS_PTRACE, et éventuellement SYS_ADMIN si vous le faites tourner sur Docker Desktop ou macOS. C'est le prix à payer pour avoir une visibilité totale sur ce qui se passe dans les tuyaux.

Le projet cartonne pas mal sur GitHub et la communauté est super active donc si vous en avez marre de jouer à cache-cache avec vos ports, c'est clairement l'outil qu'il vous faut pour reprendre le contrôle de vos déploiements sans finir en PLS à chaque conflit de port 80. Et si jamais vous stressez sur la sécurité de vos ports Docker, n'oubliez pas qu'on peut aussi jouer avec les règles iptables pour blinder tout ça, mais ça, c'est une autre histoire !

Merci à AeroStream972 pour la découverte !

Snif, snif sniiiif, c'est la fin d'une époque pour tous les admins système qui ont les mains dans le cambouis depuis plus de deux décennies.

Hé oui les amis, Microsoft vient de décider de débrancher la prise de son vénérable Microsoft Deployment Toolkit (MDT). Adios ce outil né en 2003 (sous le nom de BDD à l'époque) qui nous a sauvés la mise pendant plus de 20 ans pour installer des parcs entiers de bécanes sans y passer la nuit !

Alors pourquoi ce revirement ?

Bon, alors officiellement, c'est pour nous faire passer à des solutions "modernes" mais officieusement, beaucoup y voient une manœuvre pour nous pousser vers le passage à la caisse cloud avec Windows Autopilot et Intune. Forcément, un outil gratuit, local, qui ne remonte quasiment aucune télémétrie (contrairement aux usines à gaz actuelles) et qui permet de faire des masters aux petits oignons sans dépendre d'Azure, ça commençait à faire tache dans le catalogue de Redmond. (oooh yeah !)

Le problème, c'est que pour pas mal de boîtes, Autopilot nécessite des licences spécifiques (M365 Business Premium ou Intune Plan 1) et une connexion internet béton. Hé oui, tout le monde n'a pas envie de dépendre du cloud pour provisionner un poste.

Ça tombe bien, vous me connaissez, je ne vais pas vous laisser tomber. Alors si vous faites partie de ceux qui se retrouvent le cul entre deux chaises, sachez qu'il existe des alternatives sérieuses et surtout gratuites ou open source.

Pour l'imagerie pure et dure (le bare-metal), mon chouchou reste FOG Project . C'est une bête de course open source qui remplace avantageusement la partie imagerie de WDS. Ça gère le boot réseau (PXE), le multicast pour arroser des dizaines de PC d'un coup, et ça permet de capturer et déployer vos images Windows 10 ou 11. Et pour ceux qui veulent du plus classique, Rescuezilla (le clone graphique de Clonezilla) fait aussi un boulot béton pour cloner des disques.

Mais là où ça devient vraiment chouette, c'est pour la configuration post-installation car plutôt que de s'enquiquiner avec des task sequences complexes, je vous conseille de regarder du côté d'Ansible. Oui, ça marche aussi pour Windows via WinRM (le mode standard) ou SSH ! Vous lancez un petit playbook YAML et hop, vos softs sont installés, vos paramètres de sécurité sont appliqués et votre machine est prête à l'emploi. C'est propre, reproductible et ça évite les erreurs humaines.

Pour ceux qui veulent bidouiller leur serveur de boot, n'oubliez pas non plus d'aller voir mon article sur Netboot.xyz qui est une mine d'or pour booter un grand nombre d'OS par le réseau.

Bref, même si Microsoft tente de nous enfermer dans sa cage dorée avec Autopilot, la communauté a déjà tout ce qu'il faut pour qu'on reste maîtres de notre infrastructure. Alors courage les admins !!! Une page se tourne mais les outils qui déchirent sont toujours là !

Source