Homelab Phases 4 & 5 : Migration Proxmox, Docker et durcissement sécurité

⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Où j’en étais

Les trois premières phases avaient posé les bases : audit du réseau, configuration pfSense, segmentation VLAN sur MikroTik, migration des équipements terminaux dans leurs zones. J’avais un réseau segmenté en 5 zones, des règles firewall en place, le NAS et les postes dans leurs VLANs respectifs.

Sauf que deux morceaux de l’infrastructure traînaient encore sur l’ancien réseau 192.168.0.0/24 :

• Les trois hyperviseurs Proxmox, toujours joignables sur leurs anciennes IPs, avec des bridges réseau qui ignorent les VLANs
• La stack Docker sur le Mac Mini : Prometheus, Grafana, Loki pointaient vers des IPs qui n’existaient plus

Et côté sécurité, les interfaces d’administration n’avaient qu’un mot de passe. Pas de détection d’intrusion, pas de filtrage DNS.

Ces deux phases couvrent la migration réseau de Proxmox et Docker, puis le durcissement avec Suricata en mode IPS, pfBlockerNG et le 2FA.

Phase 4 : Migration Proxmox et stack Docker

Le problème des bridges Proxmox

Proxmox gère le réseau via des bridges Linux, des interfaces virtuelles qui relient les VMs à la carte réseau physique. Par défaut, l’IP du nœud est directement sur vmbr0, et les trames sortent non taguées. Ça marche très bien pour un réseau à plat. Ça ne marche plus du tout quand le switch attend du trafic tagué 802.1Q sur ses ports trunk.

La solution : créer une sous-interface vmbr0.20 qui force le tag VLAN 20 sur chaque trame sortante. La notation interface.VLANID est une convention Linux standard. C’est exactement ce que pfSense fait de son côté avec igb0.20. Même mécanisme, deux bouts du même câble.

enp87s0 (interface physique)
    └── vmbr0 (bridge sans IP — VLAN aware activé)
            └── vmbr0.20 → IP 192.168.20.x/24 (trafic tagué VLAN 20)

La checklist pré-migration

Avant de toucher quoi que ce soit sur un nœud Proxmox, j’exécute quatre commandes systématiquement :

1
2
3
4

ip addr show      # inventaire de toutes les IPs présentes sur le nœud
ip route show     # détecter les routes parasites vers les sous-réseaux VLAN
bridge link show  # état des bridges
ss -tlnp          # services en écoute

J’ai failli sauter cette étape sur le premier nœud. Grosse erreur.

L’incident : routage asymétrique sur le nœud ASUS

Le premier nœud migré (ASUS NUC 14 Pro+) m’a donné du fil à retordre. Après la configuration, pfSense pouvait pinger le nœud, mais le nœud ne pouvait pas pinger pfSense. Impossible d’accéder au WebUI Proxmox depuis le Mac. Les règles firewall étaient correctes, la config réseau avait l’air bonne.

Le diagnostic :

1
2

ip route show
# → 192.168.10.0/24 dev vmbr2 proto kernel scope link src 192.168.10.1

vmbr2, un bridge créé pour un ancien projet de formation, avait gardé une IP 192.168.10.1 que je n’avais jamais nettoyée. Linux avait créé automatiquement une route directe vers 192.168.10.0/24 via ce bridge. Quand le Mac (192.168.10.100) initiait une connexion TCP vers le nœud, les SYN arrivaient correctement sur vmbr0.20. Mais les SYN-ACK repartaient par vmbr2 au lieu de vmbr0.20. Routage asymétrique. Les connexions TCP ne s’établissaient jamais.

1
2

tcpdump -i any -n port 8006
# SYN entrant sur vmbr0.20, SYN-ACK sortant sur vmbr2 → connexion impossible

La résolution : retirer l’IP de vmbr2 dans /etc/network/interfaces, redémarrer le networking. La route parasite disparaît, les connexions passent immédiatement.

Ce que je retiens de ce bug : ip route show avant toute migration réseau, sans exception. Une route parasite, c’est invisible en fonctionnement normal et catastrophique quand on change de sous-réseau.

Migration des trois nœuds

La procédure est identique sur chaque nœud (ASUS, MINIFORUM, TOPTON dans cet ordre). Je fais un nœud à la fois avec vérification entre chaque.

/etc/network/interfaces :

auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp87s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

auto vmbr0.20
iface vmbr0.20 inet static
    address 192.168.20.94/24    # adapter selon le nœud
    gateway 192.168.20.1
    dns-nameservers 192.168.20.1

Deux choses apprises sur le terrain :

J’ai désactivé le firewall Proxmox sur chaque nœud (pvesh set /nodes/[nom]/firewall/options --enable 0). Avoir le firewall natif Proxmox en plus des règles pfSense, ça complique le diagnostic sans apporter grand-chose dans cette architecture. Quand un ping ne passe pas, on ne sait plus lequel des deux bloque.

Autre piège : pfSense ne laisse pas passer l’ICMP par défaut. Les nœuds Proxmox ont besoin de pinger leur gateway pour valider la connectivité, donc il faut ajouter une règle explicite dans les règles VLAN_MGMT. Ça paraît évident après coup, mais j’ai perdu du temps dessus.

Mise à jour de la stack Docker

La migration réseau a un effet de bord direct : tous les services de monitoring pointent vers des IPs en 192.168.0.x qui n’existent plus.

Voici le prometheus.yml mis à jour :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

scrape_configs:
  - job_name: 'pfsense'
    static_configs:
      - targets: ['192.168.20.1:161']      # SNMP pfSense

  - job_name: 'mikrotik'
    static_configs:
      - targets: ['192.168.20.55:161']     # SNMP MikroTik

  - job_name: 'nas'
    static_configs:
      - targets: ['192.168.50.17:9100']    # Node Exporter NAS

  - job_name: 'proxmox'
    static_configs:
      - targets:
        - '192.168.20.93:9100'             # MINIFORUM
        - '192.168.20.94:9100'             # ASUS
        - '192.168.20.95:9100'             # TOPTON

Même mise à jour pour Promtail (les sources de logs). Redémarrage de la stack, puis vérification dans Prometheus > Status > Targets : toutes les cibles doivent passer en UP.

Phase 5 : Durcissement sécurité

Vue d’ensemble

Internet → [pfSense WAN]
               ├── Suricata IPS — analyse et bloque les menaces réseau
               ├── pfBlockerNG — filtre les IPs et domaines malveillants
               └── [VLANs segmentés — Phases 1-4]
                        ├── VLAN_MGMT — Proxmox ×3 (2FA TOTP)
                        └── VLAN_SERVICES — NAS Synology (2FA TOTP)

Suppression de Squid Proxy

Premier chantier : virer Squid Proxy Server. Il était installé mais jamais configuré intentionnellement. Un service qui tourne sans qu’on sache exactement pourquoi, c’est une surface d’attaque gratuite.

Sans inspection SSL (ce qui nécessite une PKI interne pour ne pas casser les applis mobiles), Squid ne faisait que dupliquer ce que pfBlockerNG allait faire mieux via le filtrage DNS. J’ai désinstallé Squid Proxy Server, Squid Reverse Proxy, SquidGuard et ClamAV via le Package Manager. Aucune règle firewall n’en dépendait, donc pas de casse.

Déploiement de pfBlockerNG

pfBlockerNG fait deux choses : du blocage IP (listes de menaces au niveau firewall) et du DNSBL (filtrage DNS, les domaines malveillants sont interceptés avant même qu’une connexion ne s’établisse).

Le truc important que j’ai appris : préparer la whitelist avant d’activer quoi que ce soit. Avant le premier Force Reload, j’ai listé tous les services actifs dans le homelab et whitelisté leurs domaines (Synology, Proxmox, Docker Hub, GitHub, Apple, Ring, Netatmo). Un domaine critique absent de la whitelist au moment de l’activation, ça crée une panne silencieuse très pénible à diagnostiquer.

Listes DNSBL que j’ai configurées :

Les listes de blocage IP s’appliquent sur WAN en entrée, et sur tous les VLANs sauf VLAN_MGMT en sortie. Les équipements d’administration n’initient pas de connexions vers internet, donc les exclure évite tout blocage accidentel.

Calibrage et activation de Suricata en mode IPS

C’est l’étape qui m’a pris le plus de temps. Suricata tournait déjà en mode IDS depuis plusieurs mois, passif, sans blocage, en accumulant des données.

J’avais 109 105 alertes sur 6 mois. Voici ce que ça donnait une fois trié :

94% du volume, c’était du bruit. Un comportement matériel normal lié au checksum offload de la carte réseau, qui génère des fausses alertes en masse. Si j’avais activé le mode IPS sans ce calibrage, j’aurais eu des blocages massifs d’IPs légitimes dans les premières heures.

Un point qui m’a causé de la confusion au début : SID Mgmt et Suppress, c’est pas la même chose.

• SID Mgmt (via disable.conf) désactive une règle globalement. C’est pour le bruit permanent et structurel.
• Suppress désactive une règle pour une IP ou un réseau spécifique. C’est pour les faux positifs contextuels, quand la règle est pertinente en général mais pas pour un hôte donné.

Configuration IPS que j’ai retenue :

• Mode : Legacy Mode (Suricata détecte, pfSense bloque via table firewall)
• Block Offenders : activé
• Kill States : activé (ça ferme les connexions TCP existantes de l’IP bannie)
• Which IP to Block : SRC, parce que sur WAN, l’attaquant est toujours en source
• Remove Blocked Hosts Interval : 1 heure, pour éviter les bans indéfinis sur faux positifs
• EVE JSON Log : activé, c’est le format standard pour ingestion SIEM (Wazuh plus tard)

2FA sur Proxmox et NAS Synology

Application TOTP : Authy

Le choix pragmatique. Sauvegarde chiffrée dans le cloud, multi-appareils, gratuit. J’ai envisagé du self-hosted (2FAuth, Ente Auth) mais ça crée un problème circulaire : l’appli TOTP tourne dans une VM, et on a besoin du TOTP pour accéder à la VM. Si elle tombe, on est verrouillé hors de toute l’infrastructure.

Proxmox (×3 nœuds)

Proxmox distingue deux types de comptes : root@pam (compte Linux système, realm PAM) et clement@pve (compte Proxmox uniquement, realm PVE). Les deux nécessitent une configuration 2FA séparée.

Ce que j’ai fait sur chaque nœud :

1. Création d’un compte dédié clement@pve avec droits Administrator. Je n’utilise plus root au quotidien.
2. Activation TOTP sur clement@pve via Datacenter > Permissions > TFA
3. Activation TOTP sur root@pam aussi
4. Scan du QR code dans Authy, sauvegarde des codes de secours dans le gestionnaire de mots de passe
5. Validation en fenêtre privée avant de fermer la session principale

Un piège à connaître : le realm doit être sélectionné correctement à la connexion. Si on se trompe, les messages d’erreur ne disent pas que c’est un problème de realm. On cherche ailleurs pendant un moment.

NAS Synology

DSM propose le 2FA via Secure SignIn. J’ai choisi la méthode TOTP compatible Authy, sans dépendance aux serveurs Synology (le mode push nécessite leurs serveurs). Scan QR, codes de secours, validation, même routine.

Le cas pfSense : pourquoi j’ai abandonné

pfSense CE 2.8.1 n’a pas de TOTP natif (contrairement à pfSense Plus). J’ai étudié la solution FreeRADIUS. Le problème : elle impose de remplacer le mot de passe fort de 40 caractères par un PIN à 4 chiffres. C’est une régression, pas une amélioration.

Le 2FA ne vaut que ce que vaut son facteur le plus faible. Ajouter un deuxième facteur en affaiblissant le premier, ça n’a pas de sens. J’ai préféré garder le mot de passe fort et prévoir Authelia comme reverse proxy d’authentification en Phase 6.

Résultat final

Ce que j’en retiens

ip route show avant chaque migration réseau sur un nœud Linux. Point. Une route parasite ne se voit pas en fonctionnement normal. Elle ne se manifeste que quand on change de sous-réseau, et à ce moment-là on ne pense plus à vérifier les routes.

Le calibrage IDS doit précéder l’activation IPS. J’avais 6 mois de logs disponibles, ça aurait été stupide de ne pas les exploiter avant de passer en mode blocage. En entreprise comme en homelab, activer l’IPS sans analyse préalable, c’est la garantie de bloquer des hôtes légitimes dans les premières heures.

Abandonner FreeRADIUS pour pfSense, c’est pas un échec. La solution était techniquement plus complexe et moins sécurisée que ce qu’elle remplaçait. Savoir renoncer à une approche qui dégrade la sécurité, c’est une compétence en soi.

Et dernier point : une migration VLAN ne touche pas que le réseau. Elle invalide toutes les configs applicatives qui référencent des IPs. Prometheus, Promtail, les jobs de backup, le stockage NAS dans Proxmox… Tout doit être passé en revue après chaque migration.

La suite

La prochaine grosse étape, c’est Authelia avec LLDAP pour avoir une authentification centralisée SSO + 2FA devant toutes les interfaces web (pfSense, Proxmox, Grafana). C’est la vraie réponse au problème du 2FA pfSense.

En parallèle, je prévois de remplacer QuickConnect Synology par WireGuard pour l’accès distant, de déployer Wazuh comme SIEM (Suricata est déjà configuré pour envoyer ses logs en EVE JSON), et de lancer Greenbone/OpenVAS pour du scan de vulnérabilités interne.

Code source et documentation technique : Repo GitHub, Projet Segmentation Homelab, configs Proxmox, prometheus.yml, calibrage Suricata, procédure 2FA, troubleshooting

Articles connexes :

• Phase 1-3 : Audit et segmentation VLAN avec pfSense et MikroTik