Sommaire (4 sections)
Le pare-feu de Proxmox a une interface trompeusement simple : une case Firewall sur la carte réseau de chaque machine, cochée par défaut à la création. Cochée = protégé, n'est-ce pas ? Non. Cette case est un interrupteur… qui peut n'être relié à aucun circuit. Nous l'avons constaté sur notre propre parc lors d'un audit : des machines à IP publique, pare-feu « activé », en réalité ouvertes au monde entier. Voici l'anatomie exacte du piège, et comment vérifier chez vous en trente secondes.
Trois niveaux, et une hiérarchie contre-intuitive #
Le pare-feu Proxmox se configure à trois niveaux : datacenter (cluster entier), nœud (chaque hyperviseur), et invité (chaque VM/CT). L'intuition dit que les règles du datacenter « ruissellent » vers tout ce qu'il contient. La réalité du code est autre : les règles du niveau datacenter et du niveau nœud protègent les hyperviseurs eux-mêmes : leur SSH, leur interface d'admin. Elles ne s'appliquent jamais au trafic des invités. Croire qu'une règle datacenter « SSH restreint à nos IP » couvre le parc entier, c'est laisser chaque VM à IP publique exposer son propre SSH au monde.
Le piège : un interrupteur sans circuit #
Pour qu'un invité soit réellement filtré, il faut deux conditions cumulatives : la case firewall=1 sur son interface réseau, et un fichier de règles propre à l'invité (/etc/pve/firewall/<vmid>.fw) contenant au minimum enable: 1 et une politique. La case seule ne fait rien : pas de politique par défaut, pas de blocage implicite, le trafic passe intégralement. Et comme la case est cochée d'office à la création, le parc se remplit naturellement de machines qui affichent un pare-feu sans en avoir un.
# La vérification, depuis un noeud du cluster :
ls /etc/pve/firewall/
# cluster.fw 105.fw 133.fw ...
# Croiser avec les invités qui portent une IP publique :
# toute machine exposée SANS son <vmid>.fw est un trou.
# Et le juge de paix : tester DEPUIS L'EXTÉRIEUR
nmap -Pn <ip-publique-du-guest>Notre audit : 4 machines protégées sur 9 #
Chiffres réels de notre audit interne : sur neuf machines à IP publique, seules quatre avaient un fichier de règles. Cinq « pare-feu activés » ne filtraient rien. Cerise instructive : un fichier de règles actif référençait un invité… supprimé depuis longtemps : le symétrique du piège, la règle sans machine. Deux leçons : ce défaut ne se voit pas dans l'interface (tout a l'air normal), et il ne se détecte que par un audit qui croise la liste des fichiers de règles avec la liste des machines exposées.
La recette complète #
# /etc/pve/firewall/<vmid>.fw : le minimum vital d'un guest exposé
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
[RULES]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443
# SSH : jamais ouvert au monde, restreint à un ipset d'IP d'administration
IN ACCEPT -source +admin-ips -p tcp -dport 22- À la création de toute machine exposée : la carte réseau et son fichier de règles se posent ensemble, jamais l'un sans l'autre. C'est une ligne de check-list, pas un souvenir.
- Les ipsets (définis au niveau datacenter) centralisent les listes d'IP d'administration : une IP change, un seul endroit à modifier.
- À la suppression d'une machine : retirer son fichier de règles : les règles orphelines sont le bruit qui masquera le prochain vrai trou.
- Périodiquement : re-scanner depuis l'extérieur. Un pare-feu se prouve, il ne se suppose pas.
Ce piège est un cas d'école de notre conviction sur la sécurité comme série de détails vérifiés : l'outil est bon, l'interface est claire, et le défaut naît précisément de ce que tout a l'air configuré. L'audit qui l'a débusqué chez nous fait partie de ce que nous appliquons aux infrastructures que nous infogérons. Si vos machines exposées n'ont jamais été scannées depuis l'extérieur, commencez par ça.
