Aller au contenu

Firewall Proxmox : datacenter, nœud, VM, IPset, security groups

Day 1 · DéployerNiveau 2 · OpérerProcédureRédigé · à valider en lab

Objectif : activer le firewall intégré de Proxmox VE sans perdre l'accès aux nœuds, restreindre l'administration aux postes autorisés, puis filtrer les VM avec des security groups réutilisables.

Comment il est organisé

Niveau Fichier (répliqué par pmxcfs) Rôle
Datacenter /etc/pve/firewall/cluster.fw Interrupteur général, IPsets, aliases, security groups, règles communes aux nœuds
Nœud /etc/pve/nodes/<nœud>/host.fw Règles et options propres à un hôte
VM / CT /etc/pve/firewall/<VMID>.fw Règles, options, IPsets de la VM (filtrage par carte réseau)
VNet (SDN) /etc/pve/sdn/firewall/<vnet>.fw Règles forward, backend nftables uniquement

Objets réutilisables :

  • Alias : nom pour une IP ou un réseau (srv-supervision 10.10.0.50). local_network est créé automatiquement.
  • IPset : liste d'adresses. Trois noms sont spéciaux : management (postes autorisés à administrer les nœuds, le réseau du cluster y est ajouté automatiquement), blacklist (bloqué partout), ipfilter-net0 (anti-usurpation d'IP par carte de VM).
  • Security group : jeu de règles nommé, défini au datacenter et appliqué à plusieurs VM (GROUP web).
  • Macro : règle prédéfinie par service (SSH, HTTPS, DNS, Ceph…).

Une fois le firewall du datacenter activé, le trafic entrant vers les nœuds est bloqué, sauf depuis l'IPset management sur 8006 (GUI), 22 (SSH), 5900-5999 (VNC), 3128 (SPICE), 60000-60050 (migration), et Corosync (UDP 5405-5412) sur le réseau du cluster.

Backend nftables en PVE 9

Le firewall historique pve-firewall génère des règles iptables. Un backend nftables, proxmox-firewall, existe : il s'active par nœud (Nœud → Firewall → Options → nftables, paquet proxmox-firewall installé) et nécessite de redémarrer les VM. La documentation officielle le présente encore comme aperçu technologique, non adapté à la production. Sur les clusters livrés par le MSP, on reste sur le backend iptables sauf décision explicite.

Avant de toucher la prod

  • Accès hors bande vérifié (IPMI/iDRAC/iLO) sur chaque nœud : une erreur de règle se corrige en console.
  • IPset management rempli avant d'activer le firewall au datacenter (réseau des postes admin, bastion, supervision, réseau d'administration du MSP).
  • Flux applicatifs des VM inventoriés (qui parle à qui, sur quel port).
  • Fenêtre de maintenance si l'on active la politique DROP sur des VM de production.
  • Copie de /etc/pve/firewall/ : cp -a /etc/pve/firewall /root/firewall-$(date +%F).

Étapes

1. Créer l'IPset management et les aliases

Datacenter → Firewall → IPSet → Create management, puis Add : 10.10.0.0/24 (postes admin), 10.99.0.0/24 (réseau MSP). Datacenter → Firewall → Alias → Add : srv-supervision = 10.10.0.50.

pvesh create /cluster/firewall/ipset --name management --comment "Admin et MSP"
pvesh create /cluster/firewall/ipset/management --cidr 10.10.0.0/24
pvesh create /cluster/firewall/ipset/management --cidr 10.99.0.0/24
pvesh create /cluster/firewall/aliases --name srv-supervision --cidr 10.10.0.50

2. Activer le firewall au datacenter

Datacenter → Firewall → Options : Firewall = Yes. Laisser Input Policy à DROP et Output Policy à ACCEPT. Ouvrir immédiatement un nouvel onglet vers https://pve01:8006 pour vérifier l'accès.

pvesh set /cluster/firewall/options --enable 1
pve-firewall status        # Status: enabled/running

3. Créer un security group et l'appliquer à une VM

  1. Datacenter → Firewall → Security Group → Create web, puis Add : Direction in, Action ACCEPT, Macro HTTPS ; deuxième règle Macro SSH, Source +management.
  2. VM 101 → Hardware → Network Device : case Firewall cochée (c'est le cas par défaut).
  3. VM 101 → Firewall → Insert: Security Group → web.
  4. VM 101 → Firewall → Options : Firewall = Yes, Input Policy DROP, éventuellement IP filter = Yes.

Les règles peuvent être écrites directement dans les fichiers. /etc/pve/firewall/cluster.fw :

[group web]
IN HTTPS(ACCEPT) -log nolog
IN SSH(ACCEPT) -source +management -log nolog

/etc/pve/firewall/101.fw :

[OPTIONS]
enable: 1
policy_in: DROP

[RULES]
GROUP web
IN ACCEPT -source srv-supervision -p tcp -dport 10050 # agent Zabbix

Puis vérifier la compilation : pve-firewall compile | less (ou pve-firewall status).

4. Règles propres à un nœud (optionnel)

Nœud → Firewall → Add, par exemple ouvrir le port SNMP (UDP 161) à srv-supervision sur pve01 seulement. Ne jamais recopier au niveau nœud une règle déjà couverte par management.

Vérifications

pve-firewall status
# Status: enabled/running
pve-firewall localnet
# affiche le réseau local détecté (alias local_network) : il doit contenir le réseau Corosync
iptables-save | grep -c PVEFW      # règles générées (backend iptables)
pvecm status | grep -i quorate     # Quorate: Yes, Corosync non bloqué

Depuis un poste hors management, https://pve01:8006 ne répond plus. Depuis un poste admin, il répond. Depuis le réseau client, HTTPS vers la VM 101 répond, SSH non.

Rollback

GUI ou CLI : pvesh set /cluster/firewall/options --enable 0. Si l'accès réseau est perdu, en console IPMI d'un nœud : éditer /etc/pve/firewall/cluster.fw, mettre enable: 0 dans [OPTIONS], ou en dernier recours pve-firewall stop sur le nœud. Restaurer la copie /root/firewall-AAAA-MM-JJ si besoin.

Pièges vus en support

  • Firewall activé au datacenter avec un IPset management vide ou incomplet : seuls les nœuds du cluster peuvent encore se joindre. Plus de GUI depuis les postes admin.
  • Réseau Corosync ou Ceph sur un sous-réseau non détecté par local_network : perte de quorum ou OSD down. Vérifier pve-firewall localnet et ajouter des règles explicites (macro Ceph) si les réseaux sont séparés.
  • Firewall activé dans les options de la VM mais case Firewall décochée sur la carte réseau : aucune règle appliquée, fausse impression de sécurité.
  • Politique DROP sur une VM sans règle pour la supervision ou la sauvegarde applicative : alertes en cascade.
  • Activation de proxmox-firewall (nftables) en production « pour essayer » : backend en aperçu technologique, à réserver au lab.
  • Le firewall PVE ne protège pas PBS : PBS n'a pas de firewall intégré, il se filtre avec nftables ou un équipement réseau (port 8007).

Quand ouvrir un ticket iTop

Perte d'accès à la GUI de tous les nœuds ou perte de quorum après une modification du firewall : P1 ou P2 selon l'impact production. Conception d'une matrice de flux, firewall SDN/VNet, passage au backend nftables : demande P4, à confier au MSP. Joindre cluster.fw, le .fw de la VM et la sortie de pve-firewall status.

Ouvrir un ticket iTop

Pour aller plus loin