Règles pare-feu Proxmox pour une VM ou un CT

Votre VM web répond encore, mais vous arrivez au moment où une règle trop large peut ouvrir un service inutile ou couper SSH.

Le pare-feu Proxmox est déjà actif et la question devient précise : faut-il écrire au niveau de la VM, du nœud ou de l’OS invité ?

Pour une VM ou un conteneur, partez de l’invité et de ses flux réels.

Lisez les options de net0, construisez les règles IN, décidez du sort de OUT, puis factorisez uniquement les règles qui méritent un groupe. Les contrôles Proxmox et le test applicatif restent séparés du pare-feu de l’hôte.

Les règles VM/CT Proxmox doivent partir des flux réels de l’invité, puis être factorisées seulement quand elles sont réutilisables.

Fixer la cible avant d’écrire la première règle

Identifiez le VMID, l’interface virtuelle, l’adresse de l’invité et les services réellement exposés. Une VM Debian qui sert HTTP et HTTPS n’a pas les mêmes entrées qu’un conteneur d’administration accessible depuis un bastion.

notez le VMID réel et l’interface net0 ;
listez les ports entrants et les sources autorisées ;
gardez une console ou un accès administrateur à l’hôte ;
vérifiez que le pare-feu Datacenter/Node a déjà été traité.

Les zones ne se remplacent pas entre elles. Datacenter sert notamment aux briques réutilisables, Node concerne l’hôte, et VM/CT filtre les flux vers ou depuis l’invité.

Le pare-feu de Debian reste une couche séparée. La documentation officielle Proxmox VE décrit cette séparation ainsi que les directions IN, OUT et FORWARD.

Si le pare-feu du nœud n’est pas encore activé ou si vous craignez de perdre Web UI ou SSH, arrêtez-vous avant les règles VM et consultez l’activation prudente du pare-feu Proxmox sans perdre l’accès.

Le verrouillage de l’hôte reste hors périmètre ici.

Lire les options de la VM et de son interface

Avant d’écrire, relisez la configuration depuis le nœud Proxmox. Remplacez <VMID> par l’identifiant numérique de votre VM :

qm config <VMID> --current

Contrôlez ensuite, dans la configuration de la VM, enable, policy_in, policy_out, log_level_in, log_level_out et ipfilter.

Chaque interface possède aussi son propre indicateur firewall. L’option générale de la VM ne suffit pas si le flag de net0 reste désactivé.

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1

Ce bloc illustre une entrée restrictive et une sortie encore permissive. Il ne s’agit pas d’un fichier à copier tel quel : adaptez les valeurs à votre VM, puis vérifiez la configuration générée.

ipfilter sert surtout à limiter l’usurpation d’adresse sur l’interface, pas à créer une allowlist HTTP ou SSH.

Autoriser les flux entrants réellement nécessaires

Commencez par les entrées. Pour une VM web, SSH vient généralement d’un bastion ou d’un réseau d’administration.

Les ports 80 et 443 viennent du reverse proxy ou d’une source publique prévue par l’architecture. Une règle d’autorisation doit donc nommer le protocole, le port, la source et l’interface quand ces éléments sont connus.

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0

Dans cet exemple, +admins et +reverse_proxy sont des IPSet définis séparément.

L’adresse documentaire 192.0.2.0/24 peut illustrer un réseau dans un exemple ou une documentation, mais elle ne représente pas votre réseau réel. Remplacez-la par vos sources vérifiées, sans recopier une adresse trouvée dans un tutoriel.

Placez les autorisations spécifiques avant une politique DROP ou REJECT. Un refus global ajouté trop tôt masque la règle utile.

Il transforme un simple oubli en coupure SSH. Faites une lecture de la configuration avant de durcir, puis gardez une console d’hôte disponible.

Décider la politique OUT avant de la rendre stricte

Une sortie autorisée laisse fonctionner DNS, NTP, mises à jour, dépôts APT, supervision ou API externes tant que les autres couches les filtrent.

Une sortie restrictive demande un inventaire précis : le premier paquet DNS bloqué suffit à faire croire que la VM ou son bridge est en panne.

Flux de la VM	Direction	Exemple	Risque sous DROP
SSH d’administration	IN	`+admins` vers 22/tcp	Accès refusé si la source n’est pas listée.
HTTP/HTTPS	IN	`+reverse_proxy` vers 80/443	Le service web devient injoignable.
Résolution DNS	OUT	UDP/TCP 53 vers le résolveur	APT et les appels par nom échouent.
Temps système	OUT	UDP 123 vers la source NTP	L’horloge dérive si aucun autre mécanisme ne prend le relais.
Dépôts et API	OUT	TCP 80/443 vers les destinations prévues	Mises à jour et supervision peuvent s’arrêter.

Je préfère laisser policy_out: ACCEPT pendant l’inventaire, puis passer à DROP avec les sorties documentées une par une.

Ce choix protège la disponibilité du service pendant la construction. Il ne remplace pas une politique sortante si votre environnement impose réellement une liste blanche.

[OPTIONS]
policy_out: DROP

[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest depots
OUT ACCEPT -p tcp -dport 443 -dest depots

Les noms dns_interne, ntp_interne et depots doivent pointer vers vos adresses ou groupes réels. La syntaxe des ports multiples et des alias doit être relue avec la version installée de Proxmox avant application.

Factoriser les règles répétables avec un Security Group

Un Security Group devient utile quand plusieurs VM ou conteneurs partagent la même fonction.

Proxmox le définit au niveau cluster, puis la configuration de chaque invité l’appelle dans sa section [RULES]. Le groupe ne s’applique à aucune VM tant que vous ne l’avez pas inséré dans ses règles.

# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserver

Gardez dans le groupe les règles réellement communes. Une exception propre à une VM reste dans /etc/pve/firewall/<VMID>.fw. Cette séparation évite de modifier tous les invités pour corriger un seul port d’administration.

Nommer les sources avec IPSet et alias

Les IPSet regroupent des adresses ou des réseaux ; les alias donnent un nom lisible à une adresse ou à un réseau.

Les règles peuvent les utiliser en source ou en destination. Vous relisez ainsi +admins ou dns_interne sans devoir interpréter une suite d’IP à chaque passage.

# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53

[IPSET admins]
192.0.2.10

[IPSET reverse_proxy]
192.0.2.20
192.0.2.21

Les adresses 192.0.2.10, 192.0.2.20 et 192.0.2.21 sont des placeholders de documentation. Un IPSet se référence avec le préfixe +, par exemple -source +admins.

Sans ce préfixe, Proxmox lit le nom comme une adresse ou un alias et la règle ne correspond pas à l’intention.

Ne confondez pas ipfilter-net0 avec une allowlist applicative.

Cet IPSet attaché à l’interface aide à empêcher le spoofing d’adresse source. Il ne décide pas qui peut ouvrir le port 443 de votre application.

Lire l’ordre des règles avant de durcir la policy

Une règle de groupe ou une règle locale n’a d’effet que si elle est lue à l’endroit attendu. Placez les correspondances précises avant le refus général et relisez la configuration après chaque changement.

Ordre lu	Exemple	Risque si placé trop bas
1. Source et port précis	SSH depuis `+admins` vers 22/tcp	Le bastion est bloqué par la policy.
2. Groupe réutilisable	`GROUP webserver`	Les ports web restent fermés sur cette VM.
3. Sorties documentées	DNS, NTP, dépôts	Le service démarre puis perd ses dépendances.
4. Policy par défaut	`DROP` ou `REJECT`	Tout flux oublié tombe ici.

La documentation officielle décrit la syntaxe IN/OUT, les options --source, --dest, --dport et --iface, ainsi que l’insertion d’un Security Group.

Utilisez la forme correspondant à votre version, puis contrôlez la configuration compilée au lieu de supposer que le groupe est actif.

Activer un log ciblé pendant le test

La journalisation Proxmox est désactivée par défaut pour le trafic filtré. Les options log_level_in et log_level_out activent les logs standard de la VM/CT, visibles dans Firewall → Log.

Le niveau ajouté au log sert à identifier le paquet : il n’augmente pas automatiquement le nombre de paquets journalisés.

[OPTIONS]
log_level_in: info
log_level_out: nolog

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log info

Activez le niveau uniquement pendant le test du flux qui vous intéresse, puis remettez nolog si le volume devient bruyant.

Une journalisation globale permanente complique la lecture des vrais refus et augmente le bruit opérationnel.

Attention : un log vide ne prouve pas qu’un service fonctionne. Il faut encore vérifier la règle, la réponse de l’application et le chemin réseau depuis la source réelle.

Compiler, tester et prévoir le retour arrière

Commencez par la lecture de l’état du pare-feu sur le nœud :

pve-firewall status
pve-firewall compile

pve-firewall status relit et compile les règles : un avertissement de syntaxe reste un problème à corriger avant le test réseau.

pve-firewall compile permet de regarder la configuration générée.

La documentation officielle de pve-firewall décrit aussi pve-firewall simulate, qui peut aider à simuler une source, une destination, un port et un protocole, mais ne prouve ni le routage du noyau ni le fonctionnement de l’application.

Le contrôle final doit partir de la source autorisée, puis d’une source qui doit être refusée si vous pouvez l’utiliser sans risque :

SSH depuis l’IP d’administration attendue avec ssh -v ;
HTTP ou HTTPS depuis le reverse proxy avec curl -I https://<IP_VM> ;
DNS, NTP et APT depuis la VM si policy_out est restrictive ;
lecture du journal Proxmox pendant la fenêtre de test, puis retour à nolog.

Ne présentez pas ces commandes comme un test déjà effectué : elles forment votre protocole de validation.

Un résultat attendu est une connexion autorisée qui répond, un flux interdit qui échoue et une trace cohérente avec la règle examinée.

Si une règle coupe la VM, retirez cette règle ou désactivez temporairement le pare-feu de cette VM/CT.

Remettez policy_out: ACCEPT si DNS, NTP ou les mises à jour cassent.

N’utilisez pas pve-firewall stop comme retour arrière normal : cette commande retire les règles Proxmox de l’hôte et peut laisser le serveur sans protection.

Garder les limites visibles

Une VM sans adresse IP, un bridge absent ou un VLAN mal transporté ne se répare pas avec une règle firewall.

Si la règle semble correcte mais que l’invité n’a pas d’IP, passez au diagnostic réseau d’une VM Proxmox, du bridge à l’invité : rétablir le réseau de la VM.

Pour un problème côté hôte, le guide créer un bridge Proxmox sans perdre l’accès au serveur traite la couche adaptée.

Le backend nftables proxmox-firewall reste marqué comme tech preview dans la documentation PVE 9.2.11.

Les exemples ci-dessus restent centrés sur le backend stock pve-firewall. Si votre environnement utilise IPv6, vérifiez aussi NDP et les adresses IPv6 au lieu de conclure depuis un test IPv4 seul.