Durcissement Proxmox VE : la checklist commentée

Avant de commencer

Commencez par un état des lieux : le guide de l’audit de sécurité Proxmox VE donne les commandes pour relever comptes, droits, tokens, pare-feu et dépôts. Cette checklist part de ce relevé et dit quoi changer.

Gardez une session SSH ouverte sur un nœud pendant toute l’opération ; la documentation du pare-feu le demande explicitement avant de l’activer.
Avancez un nœud et un thème à la fois, et vérifiez que l’interface web, la migration et la réplication fonctionnent encore avant de passer au suivant.
Notez chaque changement avec sa date et sa valeur précédente : c’est ce qu’un auditeur vous demandera, et ce que Proxmox VE ne conserve pas lui-même.

1. Comptes et rôles

Un compte par personne, des droits limités à son périmètre, une date de fin pour les accès temporaires.

pveum acl modify /vms/104 --roles PVEVMUser --users jean@pve
pveum user modify prestataire@pve --expire 1798761599
pveum user modify ancien@pve --enable 0

Réservez le rôle Administrator sur / à quelques comptes nominatifs ; donnez PVEAuditor (lecture seule) à ceux qui consultent.
N’utilisez root@pam que pour les opérations qui l’exigent : il ne peut pas être supprimé et n’a aucune restriction.
L’expiration se donne en secondes depuis l’epoch Unix (ici le 31 décembre 2026 à 23:59:59 UTC) ; 0 signifie « jamais ». --enable 0 coupe l’accès d’un compte sans le supprimer.

2. Second facteur

Chaque compte d’administration doit avoir au moins un second facteur (TOTP ou WebAuthn) et des clés de récupération rangées hors du cluster. Pour un royaume entier, le second facteur peut être imposé avec pveum realm modify <royaume> --tfa type=… ; la documentation prévoit TOTP ou YubiKey OTP pour ce mode.

Précaution : imposer le second facteur à un royaume s’applique à tous ses comptes à la connexion suivante. Vérifiez d’abord avec pveum user tfa list qui en a déjà un, et prévenez les autres.

3. Tokens API

Une intégration, un compte technique, un token limité et daté.

pveum user token add supervision@pve grafana --privsep 1 --expire 1830297599
pveum acl modify / --roles PVEAuditor --tokens 'supervision@pve!grafana'
pveum user token remove automation@pve ancien

L’exemple crée un token de supervision en lecture seule (PVEAuditor), valable jusqu’à fin 2027. La séparation des privilèges (--privsep 1) est la valeur par défaut : le token n’a que les droits qui lui sont accordés, dans la limite de ceux de son utilisateur. Évitez --privsep 0, qui lui donne tous les droits de l’utilisateur.
Sans --expire, le token reprend l’expiration de son utilisateur ; 0 signifie « jamais ».
La valeur secrète n’est affichée qu’à la création : rangez-la dans le coffre de l’outil qui l’utilise.

4. Accès à l’interface web

L’interface (port 8006) ne doit être joignable que depuis le réseau d’administration. Au niveau du service, /etc/default/pveproxy accepte des listes d’adresses :

ALLOW_FROM="10.0.10.0/24"
DENY_FROM="all"
POLICY="allow"

systemctl restart pveproxy.service spiceproxy.service

Précaution : le redémarrage peut interrompre des opérations longues en cours. La documentation déconseille aussi de restreindre l’adresse d’écoute (LISTEN_IP) sur un cluster, dont les nœuds doivent joindre le service les uns des autres. Remplacez enfin le certificat par défaut par un certificat reconnu (ACME ou certificat de votre autorité).

5. Pare-feu de l’hôte

Le pare-feu de Proxmox VE est désactivé par défaut. L’ordre compte :

Ouvrez une session SSH sur un hôte.
Déclarez le réseau d’administration dans l’IPSet management de /etc/pve/firewall/cluster.fw : ses membres gardent l’accès à l’interface web, à SSH, aux consoles et aux migrations.
Activez le pare-feu au niveau du datacenter, puis vérifiez.

[IPSET management]
10.0.10.0/24

pve-firewall status
pve-firewall localnet

pve-firewall localnet affiche le réseau local détecté, celui que le pare-feu autorise pour corosync, l’API et SSH entre nœuds : vérifiez qu’il correspond bien au réseau du cluster. Le mode nftables (proxmox-firewall) existe mais reste en aperçu technique ; gardez l’implémentation par défaut en production sauf raison précise.

6. Pare-feu des invités

Pour qu’une VM ou un conteneur soit filtré, il faut deux réglages : l’option générale du pare-feu de l’invité, et le drapeau pare-feu de chacune de ses interfaces réseau. Une interface oubliée n’est pas filtrée. Les règles d’un invité se trouvent dans /etc/pve/firewall/<VMID>.fw. Activez aussi le filtre IP (ipfilter) sur les invités qui ne doivent pas changer d’adresse, pour les empêcher d’en usurper une autre.

7. SSH

Lisez la configuration réellement appliquée plutôt que le fichier, qui peut être complété par d’autres :

sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers|allowgroups'

PermitRootLogin prohibit-password coupe la connexion de root par mot de passe tout en gardant les clés.
PasswordAuthentication no une fois les clés des administrateurs en place.
AllowUsers ou AllowGroups pour limiter les comptes autorisés.

Précaution : les nœuds d’un cluster communiquent par un tunnel SSH sur le port 22, avec les clés de /etc/pve/priv/authorized_keys. Interdire totalement root (PermitRootLogin no) ou limiter AllowUsers sans y inclure root peut casser ces échanges. Après chaque modification, testez une migration et une réplication, et retirez de ce fichier les clés des nœuds qui ont quitté le cluster.

8. Mises à jour et dépôts

Un hôte de production suit le dépôt entreprise (abonnement) ou pve-no-subscription, jamais pve-test. Les dépôts sont décrits dans /etc/apt/sources.list.d/*.sources ; une entrée se désactive par une ligne Enabled: no.

apt update
apt full-upgrade

Utilisez apt full-upgrade, pas apt upgrade, qui laisse l’hôte partiellement à jour. Sur un cluster, mettez les nœuds à jour l’un après l’autre et gardez-les à la même version.

9. Conteneurs LXC

Créez des conteneurs non privilégiés, ce qui est le choix par défaut à la création ; la documentation réserve les conteneurs privilégiés aux environnements de confiance.
Ne montez jamais /, /var ou /etc de l’hôte dans un conteneur ; utilisez des répertoires dédiés, par exemple sous /mnt/bindmounts. Ces montages liés ne sont pas sauvegardés par vzdump : prévoyez leur sauvegarde à part.
N’activez les fonctions avancées (nesting, keyctl, fuse, mount) que si le conteneur en a besoin, et ne désactivez pas AppArmor (lxc.apparmor.profile = unconfined) en production.

10. Protection des invités critiques

qm set 104 --protection 1
pct set 201 --protection 1

Sur une VM, la protection bloque la suppression de la VM et de ses disques ; sur un conteneur, elle bloque aussi la mise à jour de ses disques. Elle ne remplace pas les droits, mais évite l’erreur de manipulation sur les machines dont la perte coûterait le plus.

11. Sauvegardes chiffrées

Vers Proxmox Backup Server, activez le chiffrement côté client (AES-256-GCM) : les données sont chiffrées avant de quitter l’hôte.

proxmox-backup-client key create
proxmox-backup-client key create-master-key
proxmox-backup-client key paperkey

Précaution : sans la clé, les sauvegardes sont inaccessibles, et une clé conservée uniquement sur l’hôte disparaît avec lui. Gardez une copie hors du cluster (coffre de mots de passe, clé USB rangée, version papier) et la clé maître, qui permet de retrouver les clés de chaque sauvegarde. Marquez comme protégées les sauvegardes qui ne doivent pas être supprimées par la rétention.

12. Notifications

Un échec doit arriver chez quelqu’un. Les notifications se règlent dans /etc/pve/notifications.cfg, avec des cibles Sendmail, SMTP, Gotify ou webhook. Proxmox VE notifie notamment les mises à jour disponibles, l’isolement d’un nœud (fencing), l’échec d’une réplication et le résultat des sauvegardes. Vérifiez que les comptes destinataires ont une adresse e-mail : sans adresse, aucun message n’est envoyé.

Les limites d’une checklist

Une checklist décrit l’état à atteindre, pas l’état réel la semaine suivante. Un token recréé sans expiration, une règle désactivée pour un dépannage ou un conteneur passé en privilégié ne se voient qu’au prochain audit, sans savoir qui l’a changé ni quand. Le durcissement tient dans la durée seulement s’il est revérifié et si chaque écart laisse une trace.

Ce que ProxTrace ajoute

ProxTrace ne durcit rien : il ne modifie pas l’infrastructure, son agent installé sur les nœuds lit en lecture seule. Il vérifie en continu que les réglages de cette liste tiennent et garde la trace de ce qui bouge :

ses 115 contrôles de bonnes pratiques Proxmox VE couvrent notamment comptes et rôles, second facteur, tokens API, SSH, pare-feu, dépôts, conteneurs LXC et sauvegardes, avec quatre statuts (Valide, Non valide, Non évaluable, Hors périmètre) et un recalcul toutes les cinq minutes ;
chaque changement de configuration est conservé avec sa valeur avant et après, ce qui répond à « qui a désactivé cette règle, et quand » ;
les rapports scellés gardent l’état d’une date tel qu’il a été évalué, pour le montrer à un auditeur.

Les droits exacts de l’agent sont détaillés sur la page sécurité du collecteur.