Audit sécurité de mon homelab : ce que j'ai trouvé après la segmentation VLAN

⚠️ Disclaimer

Ce que je décris ici correspond à ma propre démarche sur mon infrastructure personnelle. Il peut y avoir des erreurs ou des approximations : j’apprends, et c’est précisément pour ça que je fais ce genre d’audit. Ne prenez pas ça comme une référence absolue, mais comme un retour d’expérience honnête.

Pourquoi auditer ce qu’on vient de construire

J’avais passé plusieurs semaines à segmenter mon réseau en 5 VLANs, configurer pfSense, brancher Wazuh, mettre en place du monitoring. Sur le papier, l’architecture était propre. Mais j’avais une question qui traînait : est-ce que tout ça tient vraiment, ou est-ce que je me raconte des histoires ?

Monter une infra sécurisée sans jamais vérifier ce qu’elle expose, c’est un peu comme installer une alarme sans tester si elle se déclenche. Ça m’a semblé être le bon moment pour faire un vrai audit, pas juste une revue de config à la main.

J’ai découpé le travail en 4 blocs distincts : scan réseau avec nmap pour valider l’isolation des VLANs, scan de vulnérabilités avec Greenbone Community Edition, durcissement Proxmox avec les CIS Benchmarks via Wazuh SCA, et revue des règles firewall pfSense. Environ huit heures de travail étalées sur plusieurs sessions.

Bloc 1 : est-ce que mes VLANs s’isolent vraiment ?

La première question était simple : un hôte dans un VLAN peut-il joindre quelque chose dans un autre VLAN sans passer par pfSense ? Pour vérifier ça, j’ai lancé des scans nmap depuis ma VM Kali sur chaque subnet, et j’ai observé ce qui remontait.

L’isolation fonctionnait. Aucun trafic inter-VLAN ne passait en dehors des règles pfSense. Mais les scans ont quand même révélé des choses que j’aurais préféré ne pas voir. Le MikroTik CRS310 exposait telnet (port 23) et FTP (port 21) sur le VLAN de management. Deux protocoles qui transmettent les identifiants en clair. J’avais mis ça de côté à la configuration initiale en me disant “je le ferai plus tard”. Plus tard était arrivé.

J’ai aussi trouvé un hôte inconnu sur le VLAN IoT (192.168.40.110) avec une adresse MAC aléatoire. Probablement un smartphone en train de sonder le réseau. Pas de port ouvert, mais sa présence m’a rappelé que le VLAN IoT restait exposé à ce genre de bruit de fond.

Bloc 2 : Greenbone et les 4 Critical qui ne l’étaient pas vraiment

Greenbone Community Edition fait des scans de vulnérabilités avec une base CVE à jour. J’avais déployé la VM sur le VLAN Lab, configuré les credentials SSH pour les scans authentifiés, et lancé 5 tâches couvrant l’ensemble de l’infra.

Le résultat le plus frappant : 4 vulnérabilités Critical (CVSS 9.8) sur mes nœuds Proxmox. En ouvrant les rapports, la réalité était beaucoup moins dramatique. C’était uniquement des packages Debian non mis à jour : libxml2, libxml-parser-perl, libnss3. Un simple apt update && apt upgrade a tout réglé en cinq minutes. J’ai aussi installé unattended-upgrades pour que ça n’arrive plus.

La galère inattendue, c’était le NAS. Le scanner Greenbone avait déclenché le mécanisme de protection SSH du Synology : trop de tentatives de connexion en peu de temps, et l’IP de la VM Greenbone s’est retrouvée bloquée pour une durée infinie. Il a fallu débloquer manuellement dans DSM, passer la durée de blocage à 1 jour au lieu de l’infini, corriger les permissions SSH qui causaient l’échec du scan authentifié (le home directory kurgran était world-writable à cause des ACL DSM), et relancer le scan. Au final, le NAS était à jour et les seules vraies findings étaient liées à SNMP, une décision volontaire de ma part pour le moment.

Bloc 3 : le score CIS à 38%

Wazuh intègre un module SCA (Security Configuration Assessment) qui scanne la machine locale contre des benchmarks de référence. J’avais ciblé le nœud Proxmox principal (ASUS NUC, 192.168.20.94) avec le CIS Debian Linux 12 Benchmark.

Score de départ : 38%. 72 checks passés sur 207.

C’est honnêtement ce à quoi je m’attendais pour une Debian fraîche installée comme hyperviseur. Proxmox n’est pas conçu pour être un serveur durci par défaut, il est conçu pour faire tourner des VMs facilement.

J’ai travaillé section par section : durcissement SSH (PermitRootLogin, MaxAuthTries, les algorithmes MAC), politiques de mots de passe avec PAM (pwquality, faillock, login.defs), installation et configuration de sudo, et enfin auditd.

Sur auditd, j’ai eu une erreur bête qui m’a pris du temps. J’avais mis des commentaires en fin de ligne dans le fichier de règles, du type -w /etc/passwd -p wa -k identity # surveille les comptes. Le parseur auditd ne supporte pas les commentaires inline : il faut que le # soit en début de ligne. Résultat, augenrules --load montrait “No rules” et rien ne se chargeait. Une fois les commentaires déplacés sur leurs propres lignes, tout est passé. 19 règles actives en mémoire noyau, mode immutable -e 2 en dernière position pour empêcher toute modification sans redémarrage.

45 checks sont documentés comme exceptions : le partitionnement séparé de /tmp, /home et /var qui nécessiterait une réinstallation complète, AppArmor risqué sur un hyperviseur Proxmox, et rpcbind qu’on ne peut pas supprimer sans casser Proxmox VE. Des choix qui ont du sens dans ce contexte, pas des oublis.

Bloc 4 : les règles pfSense qu’on oublie

La revue des règles firewall pfSense m’a réservé quelques surprises. J’avais des règles orphelines référençant des alias qui n’existaient plus (192.168.0.x, adressage d’avant la segmentation). Elles ne causaient pas de problème actif, mais elles polluaient la config et rendaient la lecture plus difficile.

J’avais aussi laissé une règle temporaire ouverte : [TEMP] Greenbone scanner qui autorisait la VM scanner à atteindre n’importe quelle RFC1918. Nécessaire pendant le scan, mais à supprimer immédiatement après. Ce genre de règle temporaire qui dure est une source classique de surface d’attaque non voulue.

Le port 9100 (Node Exporter) de pfSense lui-même était accessible depuis le VLAN de management sans restriction. J’ai ajouté une règle de blocage spécifique pour isoler l’accès à Prometheus uniquement.

Ce que j’en retiens

Ce que ça m’a surtout appris, c’est que j’avais une assez bonne impression de mon infra sans en avoir vraiment vérifié le détail. Pas une mauvaise impression, elle est réellement correcte. Mais j’avais laissé des trucs en plan depuis longtemps : telnet sur le MikroTik, des règles pfSense pointant vers des alias disparus, des packages Proxmox pas mis à jour. Rien de catastrophique, rien de complexe. Des choses qu’on ne regarde pas quand on a la tête ailleurs.

Sur la méthode : ce qui prend du temps, c’est de s’astreindre à ne rien corriger pendant la phase de découverte. La discipline de documenter avant de toucher, et de traiter les exceptions honnêtement plutôt que de faire semblant qu’elles n’existent pas.

“Installé” et “durci” ne sont pas le même état. Je savais ça. Maintenant je l’ai vu ligne par ligne.

La suite

Il reste des choses à faire. Les deux autres nœuds Proxmox (MINIFORUM et TOPTON) n’étaient pas allumés pendant l’audit : le SSH hardening et auditd sont à appliquer sur les deux quand ils redémarrent. La communauté SNMP “public” sur le MikroTik, le NAS et pfSense reste en l’état pour l’instant : ça sera traité lors d’une refonte du monitoring SNMP. Et un certificat valide sur le WebFig MikroTik reste à configurer.

Les scripts et configurations de cet audit sont disponibles dans le repo GitHub du projet homelab, dans le dossier audit-securite/.

Configs et scripts sur GitHub.