2. Le pare-feu Proxmox

Jusqu'ici, tout peut parler à tout : une VM web atteint la base de données, un conteneur de test joint l'interface d'administration. Le pare-feu intégré décide qui a le droit de parler à qui. Ce chapitre en présente le modèle et les pièges ; l'atelier 1 le met en œuvre.

2.1 Un pare-feu distribué, organisé en zones

La configuration du pare-feu est rangée dans /etc/pve, donc répliquée sur tous les nœuds, mais chaque nœud applique lui-même les règles qui le concernent. Il le fait par iptables (service classique pve-firewall) ou par nftables (nouveau service proxmox-firewall). Trois zones, chacune avec ses règles :

2.2 Ce qui doit être activé pour qu'une règle s'applique

Le pare-feu est désactivé à l'installation : pve-firewall status répond Status: disabled/running. Le service tourne mais n'applique rien. Pour qu'une règle agisse, plusieurs interrupteurs doivent être levés, différents selon la zone (chacun vérifié sur le lab en l'éteignant seul) :

Le pare-feu du nœud n'intervient pas dans le filtrage des invités, contrairement à ce que demandent beaucoup de supports.

Les politiques décident du sort de ce qu'aucune règle ne nomme : policy_in, policy_out (ACCEPT, DROP, REJECT) et policy_forward pour le transit. DROP jette sans réponse ; REJECT renvoie un refus, mais révèle la machine. La règle d'exploitation : politique DROP, puis une règle ACCEPT par flux nécessaire.

Où voir le pare-feu sur votre cluster :

2.3 Écrire les règles : syntaxe, macros, ordre

Une règle s'écrit DIRECTION ACTION [OPTIONS], par exemple IN ACCEPT -p tcp -dport 8006 -source 10.44.1.0/24. Un | en tête la désactive.

Les macros regroupent protocole et ports sous un nom (une centaine, man pve-firewall) : IN SSH(ACCEPT). Quelques-unes :

Deux comportements doivent être connus, parce qu'ils trompent à coup sûr :

• L'ordre compte, et les nouvelles règles arrivent en tête. Les règles sont évaluées de haut en bas, la première qui correspond décide. Une règle créée par l'API ou l'interface est insérée en position 0 : après deux créations successives, la seconde apparaît au-dessus de la première dans le fichier.
• Une règle créée par pvesh sans --enable 1 est désactivée. Vérifié sur le lab : pvesh create /cluster/firewall/rules --type in --action DROP --macro Ping écrit |IN Ping(DROP) dans cluster.fw — le | initial signifie « désactivée », et la règle n'apparaît dans aucune chaîne. L'interface, elle, coche Enable par défaut.

Le pare-feu est à états (stateful) : accepter une connexion entrante accepte aussi ses réponses. Aucune journalisation par défaut : on l'active par zone (log_level_in) ou par règle (-log), et on la lit dans Firewall → Log.

2.4 Nommer les adresses et réutiliser les règles

Trois objets, définis au Datacenter (Datacenter → Firewall), évitent de répéter une adresse dans vingt règles :

Un groupe de sécurité se définit une fois dans cluster.fw et s'applique à autant d'invités qu'on veut ; le modifier modifie la protection de tous :

# /etc/pve/firewall/cluster.fw
[group web]
IN Web(ACCEPT)
IN Ping(ACCEPT) -source +admins

# /etc/pve/firewall/101.fw
[OPTIONS]
enable: 1
policy_in: DROP

[RULES]
GROUP web
IN SSH(ACCEPT) -source +admins

Le groupe web ouvre le web à tous et le ping aux seuls membres de l'IP set admins ; la VM 101 l'applique par une ligne, GROUP web. Si l'équipe d'administration change d'adresse, on modifie l'IP set : toutes les règles suivent.

Deux IP sets ont un rôle réservé. management regroupe les adresses autorisées à administrer les hôtes (le réseau local du nœud y est mis d'office, rien d'autre). blacklist regroupe les adresses jetées par chaque hôte et chaque invité.

2.5 Activer le pare-feu sans se couper l'accès

Avec une politique d'entrée DROP au Datacenter, Proxmox ouvre d'office certains ports, depuis l'IP set management seulement. Ce sont l'interface web (8006), SSH (22), SPICE (protocole de console à distance, 3128), les consoles (5900-5999), la migration (60000-60050), et Corosync sur le réseau du cluster.

Si vous administrez depuis un autre réseau (VPN — Virtual Private Network, réseau privé virtuel —, autre site), l'activation vous coupe. pve-firewall localnet affiche le réseau que Proxmox considère comme local : celui de votre vmbr0.

Via l'interface : Datacenter → Firewall → Options → Firewall → Yes, après avoir vérifié Datacenter → Firewall → IPSet → management.

Équivalent CLI (Dans le Shell du nœud) :

# Une ouverture explicite d'abord — toujours --enable 1, sinon la règle est créée désactivée
pvesh create /cluster/firewall/rules --type in --action ACCEPT --macro SSH \
  --source 10.99.0.0/24 --enable 1 --comment "SSH depuis le VPN d'administration"
pvesh set /cluster/firewall/options --enable 1   # puis seulement : activer
pve-firewall status   # l'état du pare-feu

Résultat attendu : aucune sortie pour les deux premières commandes, puis Status: enabled/running.

Pour un invité, même principe dans son propre fichier, et le troisième interrupteur : la case Firewall de sa carte.

# /etc/pve/firewall/101.fw — un serveur web, administré depuis un seul réseau
[OPTIONS]
enable: 1
policy_in: DROP

[RULES]
IN Web(ACCEPT)
IN SSH(ACCEPT) -source 10.44.1.0/24

2.6 Diagnostiquer

pve-firewall status (actif ? configuration valide ?), pve-firewall localnet (réseau local), pve-firewall simulate (tel flux passerait-il ?, sans envoyer de paquet), et Firewall → Log.

Une règle « ne fait rien ». Elle est désactivée (`.

Règle posée au Datacenter pour protéger une VM, sans effet. Les règles du Datacenter filtrent les nœuds : la règle doit aller dans le pare-feu de l'invité, ou dans un groupe de sécurité.

Règles de VNet sans effet. Moteur nftables non activé sur le nœud, ou invités non redémarrés depuis.

Plus d'accès à l'interface après activation. Poste hors du réseau local et absent de l'IP set management → console, enable: 0.

Un service répond « refusé » au lieu de ne pas répondre. Ce n'est pas le pare-feu : le paquet est passé et rien n'écoute. Un silence (délai dépassé) signe un DROP.

• 📖 Documentation Proxmox — Firewall
• 📖 Guide d'administration — pare-feu, zones, macros, nftables
• 📖 Proxmox VE : configurer le pare-feu — IT-Connect
• 🎥 Configuration complète du firewall Proxmox en atelier, avec le SDN (vidéo)

À retenir : le pare-feu Proxmox est distribué (configuration dans /etc/pve) et désactivé à l'installation. Il agit par zones : l'hôte, les invités, les VNets.

Une règle ne s'applique que si tous ses interrupteurs sont levés (Datacenter, invité, case firewall=1 sur la carte). On écrit les règles d'accès avant d'activer une politique DROP, et on nomme les adresses (alias, IP sets, groupes de sécurité).