Sécuriser et mettre à jour Proxmox VE sur un serveur dédié

Pourquoi sécuriser Proxmox VE est une priorité

Proxmox Virtual Environment (PVE) est l'hyperviseur open source de référence pour les serveurs dédiés sous Linux. Basé sur le système d'exploitation Debian, il permet aux administrateurs de créer et gérer des machines virtuelles KVM et des conteneurs LXC depuis une interface web accessible sur le port 8006. Chaque faille sur cet hyperviseur expose l'ensemble des serveurs virtuels hébergés : données, configurations réseau, accès root au système hôte. Contrairement à un hébergement mutualisé où l'hébergeur gère la couche de virtualisation, sur un serveur dédié sous Proxmox c'est l'administrateur qui est responsable de la sécurité de l'environnement virtuel, du processeur jusqu'à la RAM allouée à chaque VM.

En 2026, trois CVE publiées en juillet ont rappelé que Proxmox VE n'échappe pas aux vulnérabilités critiques. Un script de preuve de concept (PoC) permet d'obtenir un accès root depuis un simple compte non privilégié. Ce tutoriel couvre les mises à jour de sécurité, les CVE récentes à connaître, le durcissement de l'interface web et la configuration du pare-feu intégré. Alternative libre à VMware ESXi pour la virtualisation de serveurs, Proxmox VE requiert le même niveau de vigilance sur les correctifs de sécurité.

Si vous administrez un serveur dédié sous Proxmox VE, appliquer ces mesures réduit la surface d'attaque de votre infrastructure de virtualisation.

Vérifier la version de Proxmox VE installée

Avant toute mise à jour, identifiez la version exacte de Proxmox VE et du noyau Linux en cours d'exécution sur le système d'exploitation Debian sous-jacent. Connectez-vous en SSH à votre serveur dédié et exécutez :

pveversion -v

Cette commande affiche la version de chaque package Proxmox installé : pve-manager, le noyau pve-kernel, qemu-server, pve-firewall et les autres composants. Notez le numéro de version du noyau (ligne pve-kernel) : c'est lui qui détermine si votre serveur est vulnérable à CVE-2026-46242.

Vérifiez aussi les dépôts APT configurés sur votre système Debian :

cat /etc/apt/sources.list.d/pve-*.list

Deux dépôts existent : pve-enterprise (abonnement requis) et pve-no-subscription (accès libre, mises à jour de sécurité disponibles avec un léger décalage). Les correctifs de sécurité critiques sont publiés dans les deux dépôts. Si vous utilisez le dépôt no-subscription, vérifiez que la ligne correspondante est bien active dans la configuration APT de votre serveur.

CVE 2026 à connaître sur Proxmox VE

Trois vulnérabilités publiées en juillet 2026 concernent directement les installations Proxmox VE. Le tableau suivant résume leur impact sur les environnements de virtualisation et les correctifs disponibles (source : forum Proxmox).

CVE-2026-46242 : Bad Epoll (CVSS 7.8)

Bad Epoll est une vulnérabilité de type use-after-free dans le sous-système epoll du noyau Linux. Une condition de concurrence (race condition) dans le chemin de fermeture de fichiers ep_remove() permet à un utilisateur local non privilégié de corrompre la mémoire du noyau et d'obtenir un accès root. Un script de preuve de concept (PoC) exploitant cette faille via des chaînes ROP est public depuis le 6 juillet 2026. Tous les noyaux Linux 6.4 et supérieurs sont concernés. Sur un serveur Proxmox, un attaquant ayant accès à un conteneur LXC ou à une machine virtuelle peut exploiter cette faille pour s'échapper vers l'hôte et prendre le contrôle de tous les serveurs virtuels du noeud. Le correctif a été intégré dans le noyau pve 6.8.12-33-pve pour Proxmox VE 8 et dans le noyau 7.0.14 pour Proxmox VE 9. Un redémarrage du serveur est nécessaire après la mise à jour du noyau.

CVE-2026-51083 : contournement d'accès via cloudinit/dump

Un contrôle d'accès insuffisant dans le package qemu-server permet à un utilisateur authentifié avec des privilèges limités de récupérer les mots de passe hachés via l'API cloudinit/dump. Cette API, utilisée pour générer la configuration cloud-init d'une machine virtuelle, expose les condensats qui peuvent ensuite servir au cassage de mot de passe hors ligne. Le correctif est inclus dans qemu-server 9.1.8 (Proxmox VE 9) et 8.4.8 (Proxmox VE 8). Les administrateurs qui utilisent cloud-init pour provisionner des VM Debian ou Ubuntu doivent mettre à jour ce package en priorité.

CVE-2026-51081 : XSS dans l'interface web

Une faille de type Cross-Site Scripting dans pve-manager permet à un attaquant d'exécuter du code JavaScript dans le navigateur d'un administrateur connecté à l'interface web de Proxmox. L'attaquant peut alors créer des machines virtuelles, supprimer du stockage ou détourner des sauvegardes (backup) avec les droits de la session admin en cours. Le correctif pve-manager a été publié en juillet 2026. Après la mise à jour du package, videz le cache du navigateur pour ne plus charger l'ancienne version de l'interface.

Appliquer les mises à jour sans couper les VM

Sur un serveur Proxmox VE autonome (un seul noeud), les mises à jour de packages via apt ne coupent pas les machines virtuelles ni les conteneurs en cours d'exécution. La RAM et les ressources processeur allouées aux serveurs virtuels ne sont pas affectées pendant l'opération. Seul un redémarrage du serveur est nécessaire si un nouveau noyau a été installé.

Mettre à jour les packages Proxmox

sudo apt update
sudo apt list --upgradable
sudo apt dist-upgrade -y

La commande sudo apt dist-upgrade met à jour tous les packages Proxmox VE, y compris le noyau, qemu-server et pve-manager. Les machines virtuelles et les conteneurs LXC restent en fonctionnement pendant toute l'opération sur le système Debian hôte. Vérifiez ensuite les versions installées :

sudo pveversion -v

Planifier le redémarrage

Si un nouveau noyau a été installé, un redémarrage est indispensable pour l'activer. Sur un serveur de production qui héberge des environnements virtuels critiques, planifiez le reboot pendant une fenêtre de maintenance :

sudo shutdown -r 02:00 "Reboot planifié pour mise à jour noyau Proxmox"

Après le redémarrage, vérifiez que le nouveau noyau est actif et que les machines virtuelles retrouvent leurs ressources (RAM, processeur, stockage) :

uname -r
sudo qm list

Sur un cluster Proxmox à multiples serveurs (noeuds), la procédure permet un redémarrage noeud par noeud sans interruption de service. Activez le mode maintenance sur le noeud à redémarrer pour que la haute disponibilité migre les serveurs virtuels vers un autre noeud, appliquez les mises à jour, redémarrez, puis désactivez le mode maintenance. Répétez pour chaque noeud du cluster.

Automatiser les mises à jour de sécurité

Pour ne pas manquer un correctif critique, configurez unattended-upgrades sur le système Debian du serveur Proxmox. Ce package applique automatiquement les mises à jour de sécurité sans intervention manuelle de l'administrateur. Pour un guide détaillé sur la configuration de ce mécanisme, consultez notre article automatiser les mises à jour de sécurité sur Ubuntu.

Durcir l'accès à l'interface web

L'interface web admin de Proxmox VE écoute par défaut sur le port 8006 en HTTPS, sur toutes les interfaces réseau. Sur un serveur dédié connecté à Internet, ce port est exposé aux scans et aux tentatives de connexion automatisées depuis des adresses distantes. Deux mesures réduisent cette surface d'attaque : la restriction d'accès par IP et l'authentification à deux facteurs.

Restreindre l'accès distant par adresse IP

La méthode la plus efficace consiste à limiter l'accès distant au port 8006 aux seules adresses IP de confiance via le pare-feu intégré de Proxmox (détaillé dans la section suivante) ou via iptables/nftables sur le système Debian hôte. Sur un serveur dédié, vous pouvez aussi placer l'interface web admin derrière un tunnel VPN. Notre guide installer pfSense dans une VM Proxmox explique comment router le trafic d'administration à travers un pare-feu dédié dans une machine virtuelle. Vous pouvez aussi utiliser Tailscale pour créer un réseau privé et accéder à l'interface Proxmox sans exposer le port 8006 sur Internet, en résolvant l'adresse via le DNS interne de Tailscale.

Activer l'authentification TOTP (2FA)

Proxmox VE supporte l'authentification à deux facteurs via TOTP (compatible Google Authenticator, Authy, FreeOTP). Voici comment l'activer pour chaque compte admin :

1. Connectez-vous à l'interface web Proxmox (port 8006).
2. Allez dans Datacenter puis Permissions puis Two Factor Authentication.
3. Cliquez sur Add puis sélectionnez TOTP.
4. Scannez le QR code avec votre application d'authentification.
5. Entrez le code généré pour valider la configuration.
6. Générez et conservez les codes de récupération : après 8 échecs consécutifs, Proxmox désactive les facteurs TOTP du compte.

Chaque connexion à l'interface web demande ensuite le mot de passe et le code TOTP. Appliquez cette configuration à tous les comptes administrateurs ayant accès à l'administration du cluster.

Configurer le pare-feu intégré de Proxmox VE

Proxmox VE intègre un pare-feu à trois niveaux : datacenter, noeud et VM/conteneur. Les règles sont stockées dans /etc/pve/firewall/ et répliquées automatiquement sur tous les noeuds d'un cluster à multiples serveurs. Ce pare-feu filtre le trafic réseau des machines virtuelles et des conteneurs sans installer de package supplémentaire sur le serveur dédié.

Activer le pare-feu au niveau datacenter

Par défaut, le pare-feu Proxmox est désactivé. Pour l'activer depuis la ligne de commande du serveur :

sudo pve-firewall set --enable 1

Vous pouvez aussi l'activer depuis l'interface web : Datacenter puis Firewall puis Options puis Firewall: Yes. Avant d'activer le pare-feu, assurez-vous d'avoir ajouté une règle autorisant le SSH (port 22) et l'interface web admin (port 8006), sinon vous perdez l'accès distant au serveur.

Règles de base recommandées

Ajoutez les règles suivantes au niveau du noeud pour sécuriser l'accès d'administration tout en autorisant le trafic des serveurs virtuels. Ces règles s'éditent dans /etc/pve/nodes/VOTRE-NOEUD/host.fw ou via l'interface web sous Node puis Firewall :

[RULES]
IN ACCEPT -source 203.0.113.0/24 -p tcp -dport 22 -log nolog
IN ACCEPT -source 203.0.113.0/24 -p tcp -dport 8006 -log nolog
IN DROP -p tcp -dport 8006 -log nolog

Remplacez 203.0.113.0/24 par votre plage d'adresses IP d'administration. La première règle autorise le SSH depuis vos IP, la deuxième autorise l'interface web, et la troisième bloque tout autre accès distant au port 8006. L'ordre des règles est important : Proxmox les évalue de haut en bas.

Pour un durcissement plus large de votre serveur dédié (SSH, utilisateurs, partitions), consultez notre guide premiers réglages de sécurité sur serveur dédié.

Vérifier l'état du pare-feu

Après activation, contrôlez que les règles sont bien appliquées sur le système :

sudo pve-firewall status
sudo pve-firewall localnet
sudo iptables -L -n | head -40

La commande pve-firewall status confirme que le service est actif. iptables -L -n affiche les chaînes de filtrage générées par Proxmox. Si vous hébergez des serveurs de jeu dans vos machines virtuelles, ajoutez des règles au niveau VM pour autoriser les ports nécessaires (par exemple 30120 pour FiveM, 25565 pour Minecraft). Pour un pare-feu au niveau du système d'exploitation avec nftables, consultez notre guide configurer nftables sur un serveur Linux.

Bonnes pratiques de sécurité complémentaires

Au-delà des mises à jour et du pare-feu, plusieurs mesures renforcent la sécurité d'un serveur Proxmox VE sur hardware dédié. Ces recommandations s'appliquent que votre infrastructure héberge un environnement de virtualisation à usage personnel ou un cloud privé pour des clients.

• Backup réguliers sur stockage distant : configurez les sauvegardes Proxmox (vzdump) vers un stockage externe, un NAS distant, un second serveur dédié ou un espace de stockage objet. En cas de compromission, un backup récent permet de restaurer les machines virtuelles sans perte de données. Consultez notre guide sauvegardes et haute disponibilité sur serveur dédié.
• Surveillance des journaux : les tentatives de connexion échouées sont enregistrées dans /var/log/pveproxy/access.log et dans le journal systemd. Les administrateurs doivent surveiller ces logs régulièrement ou configurer un script d'alerte automatique.
• Séparation des réseaux virtuels : isolez le réseau d'administration Proxmox du réseau des VM avec des VLAN ou des bridges distincts. L'interface web et le SSH d'administration ne doivent pas transiter par le même réseau virtuel que le trafic des serveurs virtuels.
• Certificats TLS et DNS : remplacez le certificat auto-signé de Proxmox par un certificat Let's Encrypt ou un certificat de votre autorité interne. Proxmox VE intègre un client ACME pour automatiser le renouvellement. Associez un nom de domaine DNS dédié à l'interface admin plutôt que d'utiliser l'adresse IP brute.
• Mise à jour du firmware et du hardware : sur un serveur dédié, les mises à jour du BIOS/UEFI et du BMC/IPMI corrigent aussi des vulnérabilités du hardware. Profitez d'une migration vers Proxmox VE 9 pour mettre à jour le firmware du serveur.
• Scripts d'automatisation : utilisez les helper scripts Proxmox VE pour installer et maintenir des services dans des conteneurs LXC. Ces scripts simplifient le déploiement tout en appliquant des configurations sécurisées par défaut.

Conclusion

Sécuriser Proxmox VE sur un serveur dédié se résume à trois axes : appliquer les mises à jour de sécurité dès leur publication sur le système Debian hôte (noyau, qemu-server, pve-manager), restreindre l'accès distant à l'interface web admin par IP et par 2FA TOTP, et activer le pare-feu intégré avec des règles strictes pour protéger les environnements virtuels. Les CVE de juillet 2026 (Bad Epoll CVSS 7.8, cloudinit/dump, XSS pve-manager) montrent que même un hyperviseur open source reconnu n'est pas à l'abri : les administrateurs de serveurs dédiés sont les premiers responsables de la sécurité de chaque machine virtuelle, de la RAM et du processeur qu'ils partagent entre leurs VM. Un serveur Proxmox non mis à jour est un serveur compromis en attente. Dimensionner correctement votre serveur Proxmox ne suffit pas : il faut aussi le maintenir.