CIS Benchmark et Proxmox VE : appliquer le référentiel Debian

Ce que publie le CIS

Au 12 octobre 2026, le catalogue du CIS ne comporte aucun référentiel CIS propre à Proxmox VE. Il liste en revanche Debian Linux 13 (version 1.1.0), Debian Linux 12 (2.0.0) et Debian Linux 11 (2.0.0). Les recommandations sont classées en niveaux : le niveau 1 vise une base raisonnable, le niveau 2 un durcissement plus poussé, avec des profils Server et Workstation ; pour un hyperviseur, c’est le profil Server qui s’applique. Adapter officiellement les recommandations à son contexte passe par l’adhésion CIS SecureSuite.

Proxmox VE 9 s’appuie sur Debian 13 « trixie » : c’est donc le référentiel Debian 13 qu’il faut prendre. Pour un cluster encore en Proxmox VE 8, c’est celui de Debian 12.

Pourquoi CIS Debian ne suffit pas tel quel

Un référentiel Debian décrit un serveur Debian générique. Un nœud Proxmox VE en diffère sur des points structurants :

/etc/pve est un système de fichiers en espace utilisateur fondé sur FUSE, répliqué en temps réel sur tous les nœuds par corosync : désactiver FUSE au nom de la réduction de surface casse Proxmox VE ;
les nœuds d’un cluster communiquent par SSH, avec les clés de /etc/pve/priv/authorized_keys ;
Proxmox VE a son propre pare-feu, qui génère les règles de l’hôte ;
le stockage local de la configuration par défaut, dans /var/lib/vz, héberge images ISO, modèles de conteneurs et sauvegardes, que l’hyperviseur doit pouvoir utiliser.

Appliquer le niveau 1 « tel quel » avec un script peut donc casser Proxmox VE sur ces points. Sur le forum Proxmox, un administrateur rapporte environ 75 % de conformité mesurée avec Wazuh sur un hôte durci selon CIS Debian, avec des faux positifs, avant même d’avoir réglé le pare-feu ; le fil ne contient aucune réponse officielle de Proxmox.

Les recommandations CIS à adapter sur Proxmox VE

Le guide communautaire Proxmox-Hardening-Guide (HomeSecExplorer) recense les exceptions à prévoir. Les numéros ci-dessous sont ceux qu’il cite pour le référentiel CIS Debian 13 en version 1.0.0 ; vérifiez la correspondance dans la version que vous appliquez.

Connexion SSH de root (§ 5.1.21). Ne pas l’interdire sur un cluster : le guide demande de ne pas poser PermitRootLogin no et d’appliquer à la place les mesures compensatoires qu’il décrit. Limiter root aux clés (prohibit-password) et filtrer SSH au réseau de gestion, comme dans notre checklist, vont dans ce sens.
Redirection SSH (§ 5.1.8, DisableForwarding). À écarter sur un cluster, avec une mesure compensatoire documentée.
Modules de systèmes de fichiers (§ 1.1.1.11). Ne pas désactiver fuse, nécessaire à Proxmox VE, ni les systèmes de fichiers effectivement utilisés, comme ceph.
Pare-feu de l’hôte (section 4). Si le pare-feu Proxmox VE est activé, il remplace les contrôles de pare-feu de l’hôte du référentiel : ne gérez pas les mêmes règles avec deux outils.
Partitions. Le guide recommande un système de fichiers dédié pour /var/lib/vz, sans noexec, que des hooks et outils de maintenance peuvent devoir utiliser.

Ce que CIS ne couvre pas

Le référentiel s’arrête au système d’exploitation. Toute la couche Proxmox VE reste à contrôler à part :

comptes, royaumes, rôles, ACL, second facteur et tokens API de Proxmox VE (pveum) ;
règles du pare-feu Proxmox VE de l’hôte et des invités, IPSet de gestion ;
redondance corosync et séparation des réseaux du cluster ;
dépôts Proxmox VE et cohérence des versions entre nœuds ;
conteneurs non privilégiés, montages liés, protection des invités ;
sauvegardes, chiffrement côté client vers Proxmox Backup Server, restaurations testées.

La checklist de durcissement Proxmox VE traite ces points avec leurs commandes, et le guide de l’audit de sécurité Proxmox VE explique comment les constater.

Une méthode qui tient en production

Choisir le référentiel et le niveau. Debian 13 pour Proxmox VE 9, profil Server, niveau 1 d’abord ; le guide communautaire le recommande aussi (« niveau 1 d’abord »).
Appliquer sur un nœud de test. Gardez une console hors bande ou une session SSH ouverte, et une sauvegarde de la configuration.
Mesurer. Passez un outil d’évaluation compatible CIS et relevez le score avant et après ; conservez chaque rapport, daté, pour montrer la progression à l’auditeur.
Vérifier Proxmox VE. Interface web, migration, réplication, sauvegarde et restauration doivent fonctionner avant d’étendre au nœud suivant.
Étendre nœud par nœud. Un cluster dont les nœuds ne portent pas le même durcissement devient difficile à diagnostiquer.
Passer au niveau 2 point par point, une fois l’impact de chaque recommandation compris.

Documenter les écarts : le registre d’exceptions

Un auditeur n’attend pas 100 % : il attend que chaque recommandation non appliquée soit expliquée. Pour chaque exception, notez :

le numéro de la recommandation et la version du référentiel ;
la raison propre à Proxmox VE (par exemple, échanges SSH entre nœuds) ;
la mesure compensatoire en place, et comment la vérifier ;
le responsable et la date de la prochaine revue.

Exemple de ligne, pour la connexion SSH de root :

Recommandation : 5.1.21, CIS Debian 13 v1.0.0
Raison         : échanges SSH entre les nœuds du cluster Proxmox VE
Compensation   : root limité aux clés (prohibit-password), SSH filtré
                 par l’IPSet management, clés des anciens nœuds retirées
                 de /etc/pve/priv/authorized_keys
Vérification   : sshd -T, pve-firewall status
Responsable    : équipe infrastructure ; revue trimestrielle

Ce registre sert aussi de preuve pour NIS2, au titre de la gestion des configurations : voir Proxmox VE et NIS2 : quelles preuves fournir.

Et les machines virtuelles, et Proxmox Backup Server ?

Le durcissement de l’hôte ne couvre pas les invités : chaque système invité (Debian, Ubuntu, Windows Server…) relève de son propre référentiel CIS, à appliquer et à mesurer séparément. ProxTrace ne voit pas l’intérieur des machines virtuelles ; il voit leur configuration côté Proxmox VE, comme l’agent invité QEMU, la protection contre la suppression ou le pare-feu de leurs interfaces.

Le même raisonnement vaut pour Proxmox Backup Server, lui aussi construit sur Debian : le guide communautaire lui consacre des guides distincts.

Les outils qui existent

Proxmox-Hardening-Guide : guides pour Proxmox VE 9 et 8 et Proxmox Backup Server 4 et 3, sous licence CC BY 4.0, organisés en trois niveaux et rattachés au référentiel CIS Debian. Le projet se dit « en développement actif » et signale des contrôles pas encore validés : traitez-le comme une base de travail, pas comme une référence officielle. Il n’est pas soutenu par Proxmox.
PegaProx annonce, depuis sa version 0.9.1.1, un audit CIS et un scan de vulnérabilités, ainsi qu’une fonction d’application du durcissement. Avant de l’employer sur un cluster, vérifiez quelles recommandations elle applique et lesquelles elle écarte.
Les outils d’évaluation génériques, comme Wazuh cité sur le forum, mesurent l’hôte Debian ; ils ne connaissent pas les exceptions propres à Proxmox VE et produiront des écarts attendus.

Ce que ProxTrace ajoute

ProxTrace n’évalue pas le référentiel CIS Debian ligne à ligne et n’applique aucun durcissement : son agent installé sur les nœuds lit en lecture seule. Il complète un audit CIS là où celui-ci s’arrête :

ses 115 contrôles de bonnes pratiques Proxmox VE couvrent la couche Proxmox VE (comptes et rôles, second facteur, tokens, pare-feu, cluster, stockage, sauvegardes, conteneurs) et une partie de l’hôte jugée sur les valeurs du CIS Debian (politique SSH, paramètres noyau, montages de /dev/shm et /tmp, modules noyau, core dumps, AppArmor, auditd, fail2ban, verrouillage PAM, qualité et durée de vie des mots de passe, TMOUT, bannières, droits des fichiers sensibles et des journaux, AIDE, chiffrement des disques, dépôts, services critiques, persistance des journaux), recalculés toutes les cinq minutes ;
l’historique des changements avec la valeur avant et après montre quand une exception a été introduite ou un réglage défait, et par qui ;
les rapports scellés gardent l’état d’une date tel qu’il a été évalué.