Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !

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)"

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 !