Proxmox Proxmox VE - Protégez votre serveur et les VM avec le pare-feu natif - IT-Connect

[Ldfa]

• IT-Connect
• Publié le 6 mai 2026
• Par Florian BURNEL
• it-connect.fr
• Environ 14 minutes de lecture

Maîtriser le filtrage réseau de votre hyperviseur constitue la première ligne de défense de vos environnements virtualisés. Dans le contexte de Proxmox VE, les administrateurs peuvent compter sur un pare-feu intégré. Il présente l'avantage de permettre une gestion des flux à plusieurs niveaux : datacenter, nœud et ressources (machine virtuelle ou conteneur). Comment s'effectue la configuration du firewall Proxmox VE ? C'est ce que nous verrons dans la suite de cet article.

Retrouvez les autres tutoriels Proxmox VE :

• Débuter avec Proxmox VE : installation et premiers pas
• La configuration du réseau avec Proxmox VE : le guide pour bien débuter
• Proxmox VE : bien débuter avec les conteneurs LXC

Le fonctionnement du pare-feu Proxmox VE

Le pare-feu intégré à Proxmox VE (nommé pve-firewall) est une solution de filtrage basée sur les fonctionnalités natives du noyau Linux, notamment iptables (le module pour nftables est en préversion). Ici, il n'est pas question de déployer une appliance virtuelle assumant la fonctionnalité de firewall. En effet, le pare-feu Proxmox s'exécute directement sur chaque nœud (serveur physique) de l'environnement virtualisé, que ce soit un hôte autonome ou un cluster.

Le système de pare-feu de Proxmox VE est hiérarchique et se divise en trois zones distinctes :

• Le Datacenter (idéal pour un cluster) : définit les règles globales qui s'appliquent à l'ensemble des nœuds de l'infrastructure. C'est ici que l'on crée certains éléments comme les groupes de sécurité (appelés fréquemment Security Groups), les alias d'adresses IP et les listes (IPSets).
• Le nœud (hôte physique) : les règles spécifiques au serveur Proxmox lui-même, notamment pour protéger ses interfaces d'administration (WebUI, SSH).
• La machine virtuelle (VM) ou le conteneur (LXC) : les règles de filtrage spécifiques à une seule ressource et adaptées aux services hébergés par cette même ressource (serveur web, base de données, etc.). À ce niveau, les règles du nœud et du datacenter ne sont pas héritées.

Grâce à ces différents niveaux, les règles peuvent être appliquées au plus près de la source et de la destination du trafic en fonction des besoins. Surtout, Proxmox VE est en mesure de bloquer les flux avant même qu'ils atteignent la ressource, ce qui est avantageux.

Note : Proxmox VE applique les règles de pare-feu sur les nœuds dans un ordre hiérarchique logique, en allant du périmètre le plus éloigné à celui le plus proche. Ce qui donne : Datacenter > Nœud.

Activer le pare-feu sur Proxmox VE

L'activation du pare-feu dans Proxmox VE s'effectue en plusieurs étapes, et surtout, à tous les niveaux. Si le pare-feu n'est pas activé au plus haut niveau, les configurations inférieures ne seront pas appliquées. Autrement dit, pour appliquer des règles au niveau d'une machine virtuelle, vous devez activer le pare-feu au niveau du datacenter, du nœud, puis de la VM.

Attention, si vous activez le pare-feu sans créer de règles en amont, vous perdrez la main sur votre serveur Proxmox VE ! En effet, la politique par défaut consiste à refuser tout le trafic entrant.

Avant d'activer le firewall comme spécifié ci-dessous, vous devez donc commencer par le configurer.

Activation globale (Datacenter)

C'est le prérequis. Dans l'interface web, sélectionnez "Datacenter" dans le menu de gauche, puis naviguez vers "Firewall" > "Options". Modifiez l'option "Firewall" de "No" à "Yes", comme sur l'image ci-dessous. Sans cette action, le service associé au pare-feu reste inactif.

Par défaut, la politique d'entrée (Input Policy) est définie sur "DROP", ce qui signifie que tout trafic entrant non explicitement autorisé par une règle est bloqué. La politique de sortie (Output Policy) est généralement sur "ACCEPT", ce qui veut dire que tous les flux sortants sont autorisés.

Ce type de manipulation peut être effectué également en ligne de commandes :

pvesh set /nodes/pve-01/firewall/options -enable 0

D'une manière générale, toute la configuration peut être effectuée via la ligne de commande et l'édition de fichiers.

Activation sur un nœud (hôte)

Même après l'activation au niveau Datacenter, chaque nœud dispose de son propre interrupteur. Sélectionnez votre nœud (par exemple "pve-01"), allez dans "Firewall" > "Options" et assurez-vous que le paramètre "Firewall" est bien activé, comme pour le niveau Datacenter.

Activation sur une VM ou un conteneur

Pour filtrer les flux entrants et sortants au niveau d'une machine virtuelle (ou d'un conteneur), deux conditions doivent être remplies :

• Dans la section "Firewall" > "Options" de la VM, le pare-feu doit être sur "Yes".
• Au niveau de la carte réseau virtuelle (Hardware > Network Device), la case "Firewall" doit être cochée dans les paramètres de l'interface réseau. Si cette case est décochée, la carte réseau ignore totalement les règles de filtrage, même si le pare-feu de la VM est activé.

Voici l'option à laquelle je fais référence au niveau des paramètres de l'interface réseau de la VM :

L'utilisation combinée des trois niveaux offre une grande flexibilité et s'inscrit dans le principe de défense en profondeur. Les règles définies au niveau du Datacenter sont évaluées avant celles du nœud. Cela permet de créer une règle globale (par exemple : bloquer une adresse IP malveillante sur l'ensemble du cluster) qui sera héritée et appliquée partout, tout en laissant la liberté à chaque nœud ou VM d'avoir ses propres règles locales.

Mise en pratique avec un cas concret

Afin de bien comprendre la mécanique de ce pare-feu, configurons deux scénarios fréquents.

Scénario 1 : sécurisation de l'hôte Proxmox

L'objectif est de protéger l'hyperviseur lui-même. Vous pourriez alors imaginer créer un ensemble de règles de pare-feu pour limiter l'accès à l'interface d'administration web (port 8006) et au SSH (port 22), uniquement depuis une ou plusieurs adresses IP de confiance.

1. Allez sur le nœud ciblé, puis "Firewall" > "Add" pour créer une règle.
2. Direction : in (flux entrant)
3. Action : ACCEPT (accepter)
4. Interface : ici je précise vmbr0, à savoir le bridge par défaut sur Proxmox VE. Selon votre infrastructure, il peut s'avérer utile de spécifier un autre nom d'interface.
5. Source : si vous mettez rien, tout le monde sera autorisé, donc vous pouvez restreindre à un hôte ou à une machine si besoin.
6. Macro : sélectionnez SSH. Les macros remplissent automatiquement le protocole et le port de destination, ce sont comme des règles prédéfinies pour les services les plus communs. La liste des macros est disponible sur cette page.
7. Ajoutez un commentaire (important pour documenter).
8. Activez la règle en cochant l'option "Enable".
9. Ajoutez la règle avec le bouton "Add".

Pour autoriser également l'accès sur l'interface Web, répétez l'opération en choisissant cette fois-ci le port de destination manuel 8006 (avec le protocole TCP). Voici un exemple :

En définissant ces règles et en laissant la politique par défaut sur DROP, toute autre adresse IP tentant de se connecter à l'interface de gestion sera rejetée. D'ailleurs, tous les autres flux à destination de votre hôte seront rejetés d'une façon générale (mais pas à destination des VM).

Je vous encourage à peaufiner cette liste de règles, notamment si vous êtes en cluster, car il y a d'autres ports à autoriser. La liste des différents services et des ports associés est disponible dans la documentation de Proxmox VE. Pour les règles spécifiques aux clusters, vous pouvez ajuster la source pour autoriser uniquement le trafic entre les nœuds.

• Interface Web : 8006 (TCP)
• Console Web VNC : 5900-5999 (TCP, WebSocket)
• SPICE proxy : 3128 (TCP)
• SSH: 22 (TCP)
• rpcbind : 111 (UDP)
• sendmail : 25 (TCP, outgoing)
• Trafic Corosync pour le cluster : 5405-5412 UDP
• Live Migration : 60000-60050 (TCP)

Scénario 2 : sécurisation d'une machine virtuelle

Prenons une VM (ID 100) hébergeant un serveur web Linux. Nous voulons rendre les sites accessibles en HTTP/HTTPS. Voici comment procéder.

1. Allez sur la VM 100, "Firewall" > "Add".
2. Créons la règle Web :
   • Direction : in
   • Action : ACCEPT
   • Macro : Sélectionnez la macro Web. Elle permet d'autoriser les ports 80 et 443 en TCP, ce qui correspond à notre besoin.
   • Source : laissez la source vide (ce qui équivaut à n'importe quelle adresse, soit 0.0.0.0/0).
3. Créez la règle, mais pensez à l'activer et à ajouter un commentaire.

Ce qui donne :

Vous remarquerez que nous n'avons pas spécifié de nom d'interface : ce n'est pas nécessaire lorsque la règle s'applique à une machine virtuelle. Par contre, veillez à activer le pare-feu au niveau de la VM et de l'interface réseau de celle-ci.

Désormais, cette machine est joignable sur deux ports : 80 et 443. Tous les autres flux sont bloqués (souvenez-vous de la politique par défaut appliquée aux flux entrants). Si vous souhaitez vous connecter en SSH à cette VM, créez une seconde règle. Dans ce cas, il est judicieux de limiter les sources (un sous-réseau bien spécifique, l'IP d'un poste d'administration, etc.).

Voici un exemple :

Voilà, vous savez désormais comment créer des règles de pare-feu sur votre serveur Proxmox VE. Mais, pour être efficace dans l'administration et la maintenance de ces règles de pare-feu, il me semble judicieux de s'intéresser à certaines fonctionnalités proposées par PVE.

Note : appliquez le principe du moindre privilège lorsque vous réfléchirez à votre règle.

Security Groups du firewall Proxmox VE

Proxmox VE permet de créer des Security Groups au niveau du Datacenter. Un Security Group dans Proxmox VE fonctionne comme un modèle de règles de pare-feu centralisé et réutilisable.

Imaginez que vous administrez une dizaine de serveurs web : au lieu de configurer manuellement l'ouverture des ports 80 (HTTP) et 443 (HTTPS) sur chaque machine virtuelle de façon isolée, vous créez un unique groupe nommé "Web_Rules" au niveau global (Datacenter). Ensuite, vous n'avez plus qu'à "insérer" ce groupe dans les paramètres de pare-feu de chaque machine concernée.

L'avantage principal est la simplification de la maintenance : si vous devez un jour autoriser un nouveau port pour vos applications web, il vous suffit de modifier ce Security Group une seule fois pour que la mise à jour se déploie instantanément sur l'ensemble des serveurs virtuels qui y sont liés.

Pour en créer un nouveau : Datacenter > Firewall > Security Group > Create. Donnez-lui un nom, par exemple "Web_Rules".

Puis, sélectionnez-le sur la gauche pour ensuite ajouter une règle de pare-feu dans ce groupe. Ici, on crée une règle toute simple pour autoriser les flux entrants HTTP/HTTPS en sélectionnant la macro Web.

Quand c'est fait, il ne reste plus qu'à appliquer ce Security Group à une ressource. Pour cela, vous n'avez qu'à sélectionner la VM, à cliquer sur l'onglet "Firewall" puis choisissez "Insert: Security Group".

Ici, vous n'aurez qu'à le sélectionner pour créer une règle qui va reprendre toutes celles intégrées au Security Group. Pensez à cocher l'option "Enable" également.

Si par la suite vous modifiez les règles de ce Security Group, les ressources qui l'utilisent hériteront de cette modification. Ainsi, vous pouvez rendre vos configurations plus facilement homogènes.

Les alias avec le firewall Proxmox VE

Dans le pare-feu de Proxmox VE, les Alias et les IPSets sont deux autres outils conçus pour simplifier la gestion de vos adresses réseau, mais ils répondent à des besoins différents.

Un Alias fonctionne comme un contact dans votre répertoire téléphonique. Au lieu de saisir manuellement une adresse IP (comme 192.168.1.50) dans vos règles de pare-feu, vous lui donnez un nom user-friendly, par exemple "PC_Florian". Un Alias ne peut contenir qu'une seule adresse IP ou un seul sous-réseau. Vous pouvez donc aussi créer un alias pour disposer d'un objet faisant référence à un sous-réseau (un VLAN, par exemple).

Son but premier est d'améliorer la lisibilité et la maintenance : si l'adresse IP de votre administrateur change un jour, il vous suffit de mettre à jour l'Alias à un seul endroit pour que toutes les règles qui l'utilisent soient automatiquement actualisées.

Pour créer un alias : Datacenter > Firewall > Alias > Add. Vous devez nommer l'alias et spécifier l'adresse IP correspondantes (/32 pour un hôte unique).

Par la suite, quand vous créez une règle de pare-feu, vous pouvez sélectionner cet alias en tant que source ou destination. Par exemple :

Les IPSet avec le firewall Proxmox VE

Un IPSet (ensemble d'IP), en revanche, s'apparente à une liste de diffusion ou un groupe de contacts. Il est conçu pour regrouper plusieurs adresses IP, de multiples sous-réseaux, ou même des Alias sous une étiquette unique (par exemple "Postes_administration" ou "Blacklist_IP").

Son atout : le pare-feu utilise une structure de données très optimisée dans le noyau Linux (table de hachage). Ainsi, vérifier si un trafic entrant correspond à l'une des 10 000 adresses IP contenues dans un IPSet se fait de manière quasi instantanée, ce qui serait impossible si vous deviez créer 10 000 règles de pare-feu individuelles.

Vous pourrez ensuite associer l'IPSet à une règle de firewall, sur le même principe que l'affectation d'un alias.

En résumé :

• Utilisez un Alias pour identifier une ressource unique dont l'IP pourrait changer à l'avenir (vous modifierez l'Alias et toutes les règles liées seront mises à jour).
• Utilisez un IPSet dès que vous devez appliquer une politique réseau identique à un groupe, une liste ou une plage hétérogène de plusieurs machines.

La journalisation du firewall

La journalisation (logging) est utile pour le débogage et l'audit de sécurité. Sur chaque règle, vous avez la possibilité de définir un niveau de log (info, warning, err, etc.). Il est judicieux d'activer les logs sur les règles de type "DROP" pour identifier d'éventuelles problèmes. Attention toutefois à ne pas journaliser l'intégralité du trafic valide au risque de saturer l'espace disque de vos nœuds.

Le niveau de log par défaut est déterminé au niveau de chaque noeud et de chaque ressource (VM/CT). Vous pouvez définir un niveau de log différents pour les flux entrants et les flux sortants.

Ensuite, au niveau de chaque règle, vous pouvez aussi faire un choix spécifique. Vous devez cocher la case "Advanced" pour faire apparaître l'option nommée "Log level".

Pour consulter l'activité du pare-feu d'une ressource spécifique (ici, la machine virtuelle 100 (Debian-12)) :

1. Sélectionnez la ressource concernée dans l'arborescence de gauche.
2. Déroulez le menu "Firewall".
3. Cliquez sur la sous-section "Log"

En haut de l'écran, Proxmox propose deux boutons pour gérer l'affichage des logs :

• Live Mode : C'est le mode actif par défaut. Il affiche les flux en temps réel. Dès qu'un nouveau paquet est traité et journalisé par le pare-feu, la ligne apparaît instantanément à l'écran.
• Select Timespan : ce mode permet de filtrer les logs sur une période précise en utilisant les champs Since (Depuis) et Until (Jusqu'à).

L'écran principal affiche les logs bruts générés par le composant du pare-feu (iptables ou nftables). Prenons le temps de décomposer les informations essentielles que contient une ligne :

100 6 tap100i0-IN 06/May/2026:10:56:25 +0200 ACCEPT: IN=fwbr100i0 [...] SRC=192.168.1.73 DST=192.168.110.12

Voici quelques explications :

• 100 : l'identifiant (ID) de la machine virtuelle concernée.
• tap100i0-IN : indique l'interface virtuelle impliquée (l'interface réseau 0 de la VM 100) et la direction du trafic. Ici IN signifie qu'il s'agit d'une règle de trafic "Entrant" (vers la VM).
• 06/May/2026:10:56:25 +0200 : l'horodatage exact de l'événement.
• ACCEPT : c'est l'action prise par le pare-feu. Ici, le trafic a été autorisé. (Vous pourriez y voir DROP pour un trafic bloqué silencieusement ou REJECT pour un trafic rejeté).
• IN=... OUT=... PHYSIN=... : ces champs décrivent le parcours complexe du paquet à travers les différents ponts (bridges) virtuels internes de Proxmox (fwbr, fwln) avant d'atteindre l'interface de la VM (tap).
• MAC=... : l'adresse MAC source et destination.
• SRC=192.168.1.73 : l'adresse IP source (l'ordinateur ou le serveur qui a initié la connexion).
• DST=192.168.110.12 : l'adresse IP de destination (en principe, vous verrez ici l'adresse IP de votre machine virtuelle).

Forcer la désactivation du firewall Proxmox VE

En cas de mauvaise manipulation vous bloquant l'accès à l'interface web (WebUI), il est nécessaire d'intervenir directement en ligne de commande depuis la console locale du serveur (via un KVM, un accès console physique...). Pour désactiver le pare-feu au niveau du Datacenter, éditez le fichier de configuration principal :

nano /etc/pve/firewall/cluster.fw

Au sein de ce fichier, localisez la section [OPTIONS] située au tout début. Modifiez la directive enable: 1 en remplaçant le 1 par un 0 (enable: 0), puis sauvegardez le fichier (avec Ctrl+O puis Ctrl+X sous nano). Proxmox détectera automatiquement ce changement et désactivera le pare-feu, vous rendant ainsi l'accès !

L'autre solution consiste à stopper temporairement le pare-feu via l'exécution de cette commande :

pve-firewall stop

Cette commande coupe le processus de pare-feu sur le nœud actif. C'est une solution de secours pratique pour récupérer la main le temps de corriger la règle fautive - ou manquante - dans l'interface graphique. Une fois votre configuration réparée, n'oubliez pas de relancer le service avec la commande pve-firewall start ou de réactiver le pare-feu depuis l'interface web.

Conclusion

Le pare-feu intégré de Proxmox VE est une solution complète, performante et distribuée, adaptée à la protection des environnements virtualisés. Sa gestion à trois niveaux (Datacenter, Nœud, VM) permet de créer des politiques de sécurité fines, granulaires et facilement maintenables (souvenez-vous des IPSet, Alias et Security Group), que vous gériez un serveur isolé ou un cluster.

En appliquant une politique de blocage par défaut, en utilisant les groupes de sécurité et les macros, et en ciblant les flux nécessaires au bon fonctionnement de vos services, vous disposez d'un filtrage cohérent sans toucher au pare-feu de l'OS de vos VM ou conteneurs.

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

Afficher l’article complet