Ports Proxmox VE : 8006, 5900-5999, 3128, 5405-5412… lesquels ouvrir dans le pare-feu d'un serveur dédié

Le port par défaut de Proxmox VE : 8006

Le port par défaut de Proxmox VE est le port TCP 8006. C'est là que le service pveproxy sert l'interface web et toute l'API REST de l'hyperviseur, en HTTPS : on s'y connecte avec https://adresse-du-serveur:8006. Par défaut, pveproxy et spiceproxy écoutent sur toutes les adresses de la machine, et le pare-feu intégré de Proxmox est désactivé tant que vous ne l'activez pas au niveau datacenter.

Sur un serveur dédié qui reçoit une adresse IP publique, cela veut dire qu'au premier démarrage la page de connexion de Proxmox, le SSH et quelques services annexes répondent à tout Internet. Ce guide liste les ports réseau que Proxmox VE utilise selon sa documentation officielle, explique à quoi sert chacun, puis montre comment fermer ce qui doit l'être : pare-feu Proxmox au niveau datacenter et nœud, accès au port 8006 réservé à un VPN ou à des IP de confiance, reverse proxy pour changer le port exposé et vérification avec ss. Il complète notre guide sécuriser et mettre à jour Proxmox VE, centré sur les correctifs et l'authentification à deux facteurs.

Liste des ports utilisés par Proxmox VE

La documentation du pare-feu Proxmox (pve-docs 9.2.13, chapitre « Ports used by Proxmox VE ») recense huit ports ou plages de ports. Le tableau ajoute ce qui compte pour un administrateur : qui a réellement besoin d'y accéder, et s'il faut l'ouvrir sur l'interface publique.

Trois autres ports apparaissent souvent dans un ss ou dans la documentation, sans figurer dans cette liste : 85/TCP, où pvedaemon expose l'API sur 127.0.0.1 seulement (injoignable depuis l'extérieur, rien à faire) ; 8007/TCP, l'interface web de Proxmox Backup Server si vous l'installez ; 5403/TCP, le port par défaut du serveur qnetd d'un QDevice, ce petit arbitre externe qui donne le quorum à un cluster de deux nœuds.

Rôle de chaque port, et ce qu'il expose

8006 : l'interface web et l'API complète

Le port 8006 donne accès à tout : création et suppression de VM, stockage, sauvegardes, comptes et permissions. La seule barrière est l'authentification. C'est donc le premier port à restreindre, même avec un mot de passe solide et un second facteur TOTP. Dans un cluster, les nœuds s'appellent aussi entre eux par l'API : quand vous ouvrez dans l'interface une VM hébergée sur un autre nœud, la requête transite d'un nœud à l'autre. Le 8006 doit donc rester joignable entre nœuds, pas depuis le monde entier.

5900-5999 : la console VNC

Quand vous cliquez sur « Console », Proxmox lance pour la VM un processus VNC sur un port libre de la plage 5900-5999, à la demande. Le navigateur ne s'y connecte pas directement : la console noVNC ouvre un WebSocket sur le port 8006, à l'adresse /api2/json/nodes/<nœud>/qemu/<vmid>/vncwebsocket?port=5900&vncticket=…, et pveproxy relaie vers le port VNC. Un membre de l'équipe Proxmox l'a détaillé sur le forum officiel. Conséquence pratique : pour la console web, ouvrir 8006 au poste d'administration suffit. La plage 5900-5999 n'a pas à être joignable depuis Internet.

3128 : le proxy SPICE

Le port 3128 est celui de spiceproxy, utilisé quand vous choisissez SPICE comme affichage et ouvrez la console avec un client comme remote-viewer. Un scan nmap l'étiquette souvent squid-http, parce que 3128 est aussi le port historique du proxy Squid : il n'y a pas de Squid sur votre serveur. Si vous n'utilisez jamais SPICE, personne n'a besoin de ce port ; sinon, réservez-le aux mêmes adresses que le 8006.

22 : SSH, pour vous et pour le cluster

Proxmox s'appuie sur SSH entre les nœuds d'un cluster : la documentation du gestionnaire de cluster exige un tunnel SSH sur le port 22 entre nœuds, et les migrations ouvrent des tunnels SSH entre nœud source et nœud cible. Ne changez donc pas le port SSH d'un nœud en cluster à la légère. Pour l'accès administrateur, appliquez les règles habituelles (clés uniquement, pas de mot de passe root) de notre guide sécuriser SSH sur un serveur Linux, et filtrez la source au pare-feu.

111 : rpcbind, uniquement pour NFS

rpcbind traduit les numéros de programmes RPC en ports. Proxmox en a besoin si vous montez un stockage NFS, sinon il ne sert à rien. Il écoute en UDP et en TCP sur le port 111 : un portmapper exposé à Internet donne des informations sur les services RPC de la machine et peut être utilisé pour de l'amplification UDP. Fermez-le au pare-feu dans tous les cas, et désactivez-le si vous n'utilisez pas NFS (voir plus bas).

5405-5412 et 60000-60050 : le trafic entre nœuds

Corosync, le moteur de communication du cluster, utilise les ports UDP 5405 à 5412. Tous les nœuds doivent se joindre sur ces ports, avec une latence inférieure à 5 millisecondes selon la documentation, qui recommande une carte réseau physique dédiée au trafic du cluster. Les ports TCP 60000 à 60050 servent à la migration à chaud de la mémoire des VM et des disques locaux. Sur un serveur dédié seul, aucun autre nœud n'existe : n'ouvrez ni l'une ni l'autre plage. Dans un cluster, faites passer ce trafic par un réseau privé (VLAN, second port réseau) et jamais par l'interface publique.

Quels ports ouvrir selon votre configuration

La règle tient en une phrase : sur l'interface publique d'un nœud Proxmox, rien de Proxmox ne doit être ouvert à tout Internet. Seuls les services de vos VM et conteneurs (serveur web, serveur de jeu) le sont, et ils sont filtrés par leur propre pare-feu.

Activer le pare-feu Proxmox au niveau datacenter

Le pare-feu de Proxmox VE (pve-firewall, basé sur iptables) se configure à trois niveaux, chacun dans un fichier texte répliqué sur tous les nœuds par le système de fichiers du cluster :

• Datacenter : /etc/pve/firewall/cluster.fw, interrupteur général, politiques par défaut, alias, IPSet et groupes de sécurité ;
• Nœud : /etc/pve/nodes/<nœud>/host.fw, règles propres à un hôte, prioritaires sur celles du datacenter ;
• VM ou conteneur : /etc/pve/firewall/<VMID>.fw, règles de chaque machine invitée.

Tout se règle aussi dans l'interface web, sous Datacenter puis Firewall, et sous chaque nœud puis Firewall. Le pare-feu filtre IPv4 et IPv6.

Étape 1 : déclarer vos adresses d'administration dans l'IPSet management

Proxmox prévoit un IPSet standard nommé management. Les adresses qu'il contient ont le droit d'accéder à l'interface web, aux consoles VNC et SPICE et au SSH de chaque nœud. Il ne s'applique qu'au pare-feu des hôtes, pas aux VM. Le réseau du cluster y est ajouté automatiquement. Créez-le avant toute chose, dans Datacenter puis Firewall puis IPSet, ou directement dans cluster.fw :

# /etc/pve/firewall/cluster.fw
[IPSET management]
# IP fixe du bureau
203.0.113.10
# réseau des clients VPN
10.8.0.0/24

Étape 2 : fixer l'alias local_network sur un serveur à IP publique

Proxmox définit seul un alias local_network à partir de l'adresse du nœud, et s'en sert pour autoriser le trafic du cluster (corosync, API, SSH). Vérifiez sa valeur :

pve-firewall localnet

Sur un serveur dédié, l'adresse publique appartient souvent à un sous-réseau partagé avec d'autres machines du même datacenter. Si la détection automatique retient tout ce sous-réseau, des machines voisines que vous ne contrôlez pas sont traitées comme « locales ». Pour un hôte seul sur un réseau public, la documentation recommande de déclarer explicitement l'adresse IP du serveur :

# /etc/pve/firewall/cluster.fw
[ALIASES]
local_network 198.51.100.20 # IP publique du serveur seule

Étape 3 : activer le pare-feu avec une politique d'entrée DROP

Ouvrez d'abord une session SSH sur le nœud et laissez-la ouverte : c'est le conseil de la documentation, et votre filet de sécurité si une règle vous coupe l'accès. Puis, dans Datacenter puis Firewall puis Options, passez Firewall à Yes et réglez la politique d'entrée sur DROP. En fichier, cela donne :

# /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

La documentation ne donne pas de valeur par défaut pour policy_in et policy_out : écrivez-les explicitement, vous saurez exactement ce qui s'applique.

Ce que le pare-feu laisse passer tout seul

Avec une politique d'entrée DROP ou REJECT, Proxmox conserve des règles par défaut pour que le nœud reste administrable et que le cluster fonctionne :

• le trafic sur l'interface loopback, les connexions déjà établies et le protocole IGMP ;
• depuis les hôtes de management : TCP 8006, 5900-5999, 3128, 22 et 60000-60050 ;
• dans le réseau du cluster : UDP 5405-5412 pour corosync et le multicast ;
• les messages ICMP de type 3 (destination injoignable), 4 et 11 (délai dépassé).

Vous n'avez donc pas à écrire de règle pour 8006 ou 22 : remplir l'IPSet management suffit, et tout ce qui n'est pas autorisé est bloqué, rpcbind compris. Un second IPSet standard, blacklist, fait l'inverse : le trafic de ses adresses est rejeté par le pare-feu de chaque hôte et de chaque VM.

Règles au niveau du nœud et des VM

Les règles s'écrivent sous la forme DIRECTION ACTION [OPTIONS], ou DIRECTION MACRO(ACTION) avec une macro comme SSH. Le préfixe + désigne un IPSet. Exemple de host.fw pour un nœud qui publie son interface derrière un reverse proxy sur le port 443 :

# /etc/pve/nodes/pve1/host.fw
[OPTIONS]
enable: 1

[RULES]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

Pour réserver le reverse proxy à vos seules adresses, ajoutez -source +management à ces règles.

Pour les machines invitées, le pare-feu d'une VM ne s'applique que si deux réglages sont actifs : l'option Firewall de la VM (désactivée par défaut) et la case pare-feu de chaque carte réseau virtuelle. Un serveur FiveM dans la VM 101 recevrait par exemple, dans /etc/pve/firewall/101.fw :

[OPTIONS]
enable: 1
policy_in: DROP

[RULES]
IN ACCEPT -p tcp -dport 30120
IN ACCEPT -p udp -dport 30120

Les règles de l'IPSet management ne valent pas pour les VM : chaque invité a les siennes. Pour aller plus loin dans le cloisonnement, notre guide Proxmox SDN et réseaux virtuels montre comment isoler les VM sur des zones et des VNet séparés.

À noter : Proxmox propose aussi proxmox-firewall, une réécriture du pare-feu sur nftables (paquet proxmox-firewall, option nftables: 1 dans le host.fw). La documentation la présente encore comme un aperçu technologique, déconseillé en production. Les règles et les fichiers restent les mêmes.

N'exposer 8006 qu'à un VPN ou à des IP de confiance

IP fixe ou VPN

Si vous administrez depuis une connexion à IP fixe, l'IPSet management fait tout le travail. Avec une IP qui change, ou plusieurs administrateurs en déplacement, passez par un VPN : seul le port du VPN est ouvert sur Internet, et le sous-réseau des clients VPN entre dans l'IPSet management. Trois approches courantes :

• un serveur WireGuard sur une petite VM ou un VPS séparé, avec une interface web de gestion des pairs comme dans notre guide WireGuard Easy ;
• un pare-feu virtuel en VM, qui porte le VPN et route l'administration, comme dans notre guide installer OPNsense dans une VM Proxmox ;
• un réseau maillé sans port entrant, avec Tailscale installé sur le nœud.

Gardez un accès de secours qui ne dépend pas du VPN (une IP fixe dans management, ou la console hors bande du serveur si vous en disposez) : une VM VPN arrêtée ne doit pas vous fermer la porte de l'hyperviseur qui l'héberge.

Une seconde barrière dans pveproxy

Indépendamment du pare-feu, pveproxy lit des listes de contrôle d'accès dans /etc/default/pveproxy. Avec POLICY="allow" et DENY_FROM="all", seules les adresses de ALLOW_FROM obtiennent une réponse :

# /etc/default/pveproxy
ALLOW_FROM="127.0.0.1,203.0.113.10,10.8.0.0/24"
DENY_FROM="all"
POLICY="allow"

systemctl restart pveproxy.service spiceproxy.service

Gardez 127.0.0.1 si un reverse proxy local relaie l'interface, et ajoutez les adresses des autres nœuds dans un cluster, puisqu'ils se parlent aussi par l'API. Le même fichier accepte LISTEN_IP, pour n'écouter que sur une adresse précise (celle du VPN, par exemple) ; la documentation le déconseille sur un cluster.

Changer le port exposé avec un reverse proxy

Proxmox ne prévoit pas de changer le port de pveproxy, et son wiki demande de ne pas modifier cette configuration. Pour publier l'interface sur le port 443 avec un nom de domaine, on place un reverse proxy nginx devant, sur le nœud lui-même. Installez-le avec apt install nginx, supprimez le site par défaut (/etc/nginx/sites-enabled/default), puis créez /etc/nginx/conf.d/proxmox.conf :

server {
    listen 80 default_server;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name pve.example.com;

    ssl_certificate     /etc/pve/local/pve-ssl.pem;
    ssl_certificate_key /etc/pve/local/pve-ssl.key;

    location / {
        proxy_pass https://127.0.0.1:8006;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_buffering off;
        client_max_body_size 0;
        proxy_connect_timeout 3600s;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        send_timeout 3600s;
    }
}

Les en-têtes Upgrade et Connection sont indispensables : sans eux, le WebSocket de la console noVNC et du shell ne passe pas. client_max_body_size 0 lève la limite de taille pour l'envoi d'images ISO. Si vous avez obtenu un certificat Let's Encrypt avec le client ACME de Proxmox, il se trouve dans /etc/pve/local/pveproxy-ssl.pem et pveproxy-ssl.key : utilisez ces deux fichiers à la place.

Comme les certificats vivent dans /etc/pve, monté par le service pve-cluster, nginx doit démarrer après lui. Ajoutez une surcharge systemd :

systemctl edit nginx.service

[Unit]
Requires=pve-cluster.service
After=pve-cluster.service

nginx -t && systemctl restart nginx

Ouvrez ensuite le port 443 dans le host.fw (règle montrée plus haut) et laissez le 8006 réservé à l'IPSet management. Le trafic de nginx vers 127.0.0.1:8006 passe par la loopback, toujours autorisée. Un reverse proxy change le port visible, pas le niveau de sécurité : la page de connexion reste exposée. Restreignez le 443 à vos adresses si vous le pouvez, gardez le second facteur TOTP, et voyez notre guide nginx en reverse proxy pour les réglages TLS. La console SPICE ne passe pas par ce proxy : elle continue d'utiliser le port 3128.

Vérifier les ports en écoute avec ss et le pare-feu

Sur le nœud : ss

La commande ss liste les sockets en écoute avec le processus qui les détient :

ss -tulpn

-t et -u pour TCP et UDP, -l pour les sockets en écoute, -p pour le processus, -n pour garder les numéros de port. Sur un nœud Proxmox, attendez-vous à voir pveproxy sur le 8006 et spiceproxy sur le 3128 (sur toutes les adresses, sauf si vous avez réglé LISTEN_IP), pvedaemon sur 127.0.0.1:85, sshd sur le 22, rpcbind sur le 111 en TCP et UDP, et corosync si le nœud fait partie d'un cluster. Pour cibler un port :

ss -tlnp 'sport = :8006'

Une colonne d'adresse locale 0.0.0.0, * ou [::] signifie « toutes les interfaces » : c'est alors le pare-feu qui décide qui passe. Notre guide lister les ports en écoute avec ss détaille la lecture de la sortie.

Côté pare-feu : pve-firewall

pve-firewall status
pve-firewall compile | less
pve-firewall simulate --source 192.0.2.50 --dport 8006

status relit et compile toutes les règles et signale les erreurs. compile affiche les règles générées. simulate calcule le sort d'un paquet : par défaut, il part de l'extérieur (--from outside) vers l'hôte (--to host) en TCP. Testez une adresse qui ne figure pas dans management : la réponse doit être un refus. Évitez pve-firewall stop en production : la commande retire toutes les règles iptables de Proxmox et laisse l'hôte sans protection.

Depuis l'extérieur : nmap

Le test qui compte se fait depuis une machine extérieure dont l'IP n'est pas dans management (un autre serveur, une connexion mobile) :

nmap -Pn -p 22,3128,5900,8006 198.51.100.20
sudo nmap -sU -p 111 198.51.100.20

Précisez toujours les ports : un scan nmap sans -p se limite aux ports les plus courants et ne teste pas le 8006. Les ports doivent apparaître filtered, pas open.

Désactiver rpcbind si vous n'utilisez pas NFS

Fermé au pare-feu, rpcbind ne répond plus à l'extérieur, mais un service inutile reste un service de trop. Sans stockage NFS, vous pouvez l'arrêter, ainsi que son socket systemd qui le relancerait à la première connexion :

systemctl disable --now rpcbind.service rpcbind.socket

Réactivez-le (systemctl enable --now rpcbind.socket) avant d'ajouter un stockage NFS.

Erreurs fréquentes avec les ports Proxmox

• Activer le pare-feu avant de remplir l'IPSet management : avec une politique DROP et une IP d'administration hors du réseau local détecté, vous perdez l'interface web et le SSH. Gardez une session SSH ouverte pendant l'activation.
• Oublier l'IPv6 : le pare-feu filtre les deux protocoles. Si vous administrez en IPv6, ajoutez aussi votre adresse IPv6 dans management.
• Laisser local_network détecter un sous-réseau public entier : fixez-le sur l'adresse du serveur, comme le recommande la documentation pour un hôte seul.
• Faire passer corosync par Internet : en plus d'exposer 5405-5412, la latence d'un lien public dépasse vite les 5 ms exigées, et le cluster perd le quorum. Utilisez un réseau privé.
• Croire qu'un port non standard protège : déplacer l'interface sur 443 ou sur un port exotique ne la cache pas aux scanners. Seul le filtrage par source réduit vraiment la surface d'attaque.
• Oublier la case pare-feu de la carte réseau : des règles écrites pour une VM restent sans effet si l'interface réseau virtuelle n'a pas son propre drapeau pare-feu activé.

Pour le reste du durcissement d'un hôte (comptes, SSH, mises à jour), voyez notre guide premiers réglages de sécurité d'un serveur dédié, et pensez aux sauvegardes hors du nœud : un pare-feu bien réglé ne remplace pas une copie de vos VM ailleurs.

En résumé

Proxmox VE écoute par défaut sur le port 8006 pour l'interface web et l'API, 3128 pour SPICE et 22 pour SSH, utilise 5900-5999 pour les consoles VNC relayées par le 8006, 111 pour rpcbind, et réserve 5405-5412 (corosync) et 60000-60050 (migration) au trafic entre nœuds. Sur un serveur dédié à IP publique, aucun de ces ports n'a à être ouvert à tout Internet : activez le pare-feu au niveau datacenter avec une politique DROP, mettez vos IP ou votre réseau VPN dans l'IPSet management, fixez local_network sur l'IP du serveur, puis vérifiez avec ss -tulpn, pve-firewall simulate et un nmap lancé de l'extérieur.