Durcir Proxmox VE

Un nœud Proxmox est un hyperviseur, ce qui veut dire que le compromettre n’est pas compromettre un serveur, c’est compromettre d’un coup chaque VM et chaque container qu’il porte. Cela relève l’enjeu des choses ordinaires, l’interface web, l’ouverture de session, le SSH, le pare-feu, parce que chacune est désormais une porte vers tout le parc plutôt que vers une machine. Le durcissement se partage nettement: protéger le plan de gestion qui contrôle tout et comprendre lequel des deux types de charge isole vraiment et lequel est une évasion vers le root de l’hôte qui attend un prétexte.

L’interface de gestion n’est pas un service internet

L’interface web Proxmox écoute sur 8006, arrive avec un certificat auto-signé et répond volontiers à internet, où un nombre surprenant d’entre elles siègent. Elle ne devrait pas. L’interface de gestion appartient à un réseau de gestion atteint par VPN ou via un bastion, jamais exposée directement, le pare-feu n’autorisant 8006 et le SSH du nœud que depuis la plage d’administration:

# Pare-feu datacenter ou nœud: gestion joignable depuis le réseau admin seulement
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 8006
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22
IN DROP

Derrière cela, remplacez le certificat auto-signé par un certificat de votre autorité interne (ou ACME, que Proxmox intègre) pour que les administrateurs cessent de s’entraîner à cliquer à travers les avertissements de certificat, cette habitude qui rend un homme du milieu trivial.

Connexion : pas root et pas sans second facteur

Proxmox authentifie contre des realms et le réflexe est de se connecter en root@pam et de partager le mot de passe. Deux changements comptent. Donnez aux administrateurs des comptes nommés dans un realm approprié, mappés aux rôles Proxmox, pour que les actions soient imputables et que root@pam soit réservé au bris-de-glace plutôt qu’à l’usage quotidien. Et rendez un second facteur obligatoire, parce que l’interface web contrôle tout le parc et qu’un seul mot de passe hameçonné ne devrait pas: Proxmox a du TOTP et du WebAuthn intégrés et la TFA peut être exigée par realm.

Le RBAC est l’autre moitié de l’histoire de connexion. Les rôles Proxmox sont granulaires et cadrés sur un chemin (un pool, une VM, un stockage), de sorte qu’un opérateur qui gère un ensemble de VMs reçoit un rôle sur ce pool et rien au niveau datacenter. Les jetons d’API sont là où cela se défait le plus souvent: un jeton avec PVEAdmin ou les pleins privilèges de root@pam, collé dans une automatisation, est un identifiant pleine-grappe dans un fichier de config. Cadrez chaque jeton sur le rôle et le chemin minimaux dont il a besoin et préférez des jetons séparés par intégration pour qu’on puisse en révoquer un sans casser les autres.

LXC : le container privilégié est la vraie évasion

Proxmox fait tourner deux types de charge à l’isolation très différente et les confondre est l’erreur classique. Une VM KVM est une frontière solide: c’est un vrai noyau invité derrière l’hyperviseur et une évasion invité-vers-hôte est un vrai exploit QEMU/KVM, rare et précieux. Un container LXC partage le noyau de l’hôte, exactement comme Docker, donc la même règle s’applique: un LXC privilégié est une évasion vers le root de l’hôte avec un drapeau de config.

Proxmox met par défaut les nouveaux containers en non privilégié, ce qui mappe le root du container vers un UID hôte non privilégié par un user namespace et ce défaut est le bon. Le durcissement consiste à le garder et à résister au “mets-le juste en privilégié, c’était la seule façon de faire marcher le montage” qui produit la config dangereuse:

# container non privilégié, pas de fonctions risquées
unprivileged: 1
features: nesting=0,keyctl=0

Un LXC privilégié (unprivileged: 0), surtout avec features: nesting=1 ou du passthrough de périphérique, est l’équivalent Proxmox de docker run --privileged: à l’intérieur, atteindre le système de fichiers et les périphériques de l’hôte est routinier. Quand une charge a vraiment besoin de ce niveau d’accès à l’hôte, elle appartient à une VM KVM, où la frontière est réelle, pas à un container privilégié où la frontière est une fiction polie.

Activez le pare-feu

Le pare-feu Proxmox existe aux niveaux datacenter, nœud et VM et il est désactivé par défaut, ce qui veut dire que d’emblée chaque VM peut parler à toutes les autres et au réseau de gestion. Activez-le, default-deny et écrivez les autorisations par VM pour que le réseau invité soit segmenté plutôt que plat:

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

Les règles par VM ne permettent ensuite que les flux dont chaque invité a besoin, ce qui transforme une VM compromise de “peut tout atteindre” en “peut atteindre les deux services qu’on lui a autorisés”. Les zones SDN et les VNets donnent une vraie séparation de tenants par-dessus quand le parc le demande, mais le default-deny par VM est le plancher.

Le cluster et l’hôte en dessous

Un cluster Proxmox se coordonne via Corosync et Corosync devrait avoir son propre réseau dédié, à la fois parce qu’il est sensible à la latence (un lien congestionné cause de faux basculements et du fencing) et parce que le trafic interne du cluster n’a rien à partager avec le trafic invité. La même séparation vaut pour le stockage: Ceph ou le réseau de réplication de stockage est son propre segment 10GbE, autant pour l’isolation que pour le débit qu’il réclame.

Sous tout cela, le nœud est un hôte Debian, donc le durcissement Linux et SSH s’applique pleinement: SSH en clés seules restreint au réseau admin, les mises à jour de sécurité automatiques tenues à jour (le dépôt sans souscription convient pour cela, l’erreur est de faire tourner un nœud non patché pendant des mois) et des sauvegardes chiffrées et testées, parce que les sauvegardes d’un hyperviseur sont une copie de chaque VM qu’il porte et méritent la protection qu’ont les originaux.

Où atterrir

Gardez l’interface 8006 hors d’internet, derrière un VPN ou un bastion et un pare-feu default-deny, avec un vrai certificat. Connectez-vous avec des comptes nommés à second facteur obligatoire, réservez root@pam aux urgences et cadrez chaque rôle et jeton d’API sur le chemin minimal plutôt que de distribuer PVEAdmin. Gardez les containers LXC non privilégiés et envoyez tout ce qui a besoin d’un vrai accès à l’hôte vers une VM KVM, parce que la frontière VM est réelle et celle du container privilégié non. Activez le pare-feu default-deny au datacenter et par VM, donnez à Corosync et au stockage leurs propres réseaux et durcissez l’hôte Debian sous-jacent comme le serveur critique qu’il est. Le nœud détient chaque VM que vous faites tourner; sa sécurité est la leur.

[edit: 2026] L’implémentation Ansible de tout ceci: le rôle proxmox .