🛡️ Guide de Durcissement Proxmox VE 9 — Référence Francophone

Ce guide fournit des recommandations de durcissement prescriptives, vérifiables et opérationnelles pour Proxmox Virtual Environment 9.x (Debian 13 "Trixie"). Il est conçu pour les administrateurs systèmes, ingénieurs sécurité et auditeurs.

Ce qui le différencie

Base de référence

• CIS Debian Linux 13 Benchmark v1.0.0 (2025-12-16)
• MITRE ATT&CK v16
• CIS Controls v8
• ISO/IEC 27001:2022 Annex A
• PCI DSS v4.0
• BSI — Sicherheitsanalyse von KVM (KVMSec) v1.0.1
• QEMU Project — Security Documentation

Prérequis

• Proxmox VE 9.x installé (Debian 13 "Trixie")
• Accès root au(x) nœud(s)
• Accès console hors-bande (IPMI/iDRAC/KVM) ou physique
• Sauvegardes fonctionnelles des VM et du nœud

Par où commencer ?

🏠 Homelab — Top 5 actions à impact maximal :

1. SSH : clés uniquement + Fail2Ban → Phase 3
2. Mises à jour auto sécurité Debian → Phase 1
3. 2FA sur le web UI → Phase 3
4. Backups PBS chiffrées → Phase 9
5. Firewall PVE activé → Phase 4

🏢 Production — Parcours recommandé :

1. Lire le threat model (30 min)
2. Appliquer la Phase 0 (pré-installation) si nouveau déploiement
3. Phases 1 → 4 dans l'ordre (Level 1 d'abord)
4. Phase 9 (backup) en priorité si pas encore fait
5. Phases 5 → 8 pour la défense en profondeur
6. Revenir sur les contrôles Level 2

🌐 Exposé internet — Ajouts critiques :

• VPN comme unique entrée management → Phase 3, 3.5
• WebAuthn/FIDO2 → Phase 3, 3.2.2
• LUKS full-disk encryption → Phase 0, 0.2.3

Règles d'or

1. Toujours tester en lab avant d'appliquer en production
2. Ne jamais fermer votre session SSH avant d'avoir testé la nouvelle configuration dans un second terminal
3. Garder un accès console OOB en cas de lock-out
4. Appliquer Level 1 d'abord, puis Level 2 quand Level 1 est stabilisé
5. Documenter chaque déviation par rapport au guide (justification + acceptation du risque)

Chaque contrôle suit le format CIS Benchmark enrichi :

X.Y.Z — Titre du contrôle

Description / Rationale / Impact / Audit / Remédiation

Valeur par défaut / Rollback / Spécificité PVE

---

⚠️ Ce guide est fourni « en l'état », sans garantie. Vous êtes seul responsable de l'évaluation, du test et de la validation de chaque recommandation dans votre environnement.

⚠️ Certaines procédures ne sont pas officiellement supportées par Proxmox GmbH. Tester et maintenir à vos propres risques.

⚠️ Ce guide ne constitue pas une certification de conformité. Il est conçu pour aider à la préparation d'audits et à l'amélioration de la posture de sécurité.

Les contributions sont bienvenues. Voir CONTRIBUTING.md.

Ce guide est publié sous licence Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).

Vous pouvez copier, modifier et distribuer le contenu à condition de conserver l'attribution et de partager sous la même licence.

-e

01 — Modèle de menaces Proxmox VE

Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format normalisé Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, MITRE ATT&CK v16, CIS Controls v8 Sources : BSI KVMSec v1.0.1, QEMU Security Documentation, Proxmox Forum, CVE databases

Pourquoi un modèle de menaces ?

La plupart des guides de durcissement démarrent par « exécutez ces commandes ». Sans modèle de menaces, on applique des contrôles au hasard — on chiffre des disques pendant que SSH accepte les mots de passe, on active auditd sur un nœud dont le BMC a encore le mot de passe usine.

Ce chapitre identifie :

• Les surfaces d'attaque spécifiques à un hyperviseur Proxmox VE
• Les scénarios d'attaque réalistes, classés par probabilité
• Les mappings vers les cadres de référence (MITRE ATT&CK, CIS Controls v8, ISO 27001, PCI DSS)
• Les contrôles préventifs et détectifs de ce guide rattachés à chaque scénario

Chaque contrôle des phases suivantes référence un ou plusieurs scénarios de ce chapitre. Si un scénario ne vous concerne pas, les contrôles associés deviennent optionnels. Si un scénario est votre cauchemar, vous savez exactement quoi prioriser.

Portée

Un hyperviseur est le pire point de compromission possible dans une infrastructure. Compromettre un hyperviseur donne accès simultanément à toutes les VM hébergées, à leur mémoire vive, à leurs disques, à leur trafic réseau. Proxmox VE expose quatre plans d'attaque distincts :

Règle : en cas de doute entre deux profils, choisir le plus restrictif.

Chaque scénario suit un format normalisé avec mappings compliance intégrés. Les scénarios sont ordonnés par probabilité décroissante.

**Remédiation** :

**Valeur par défaut** : Microcode distribué avec le kernel Debian. Peut ne pas être la dernière version.

**Rollback** : Pour le microcode Debian : `apt purge intel-microcode` ou `amd64-microcode` et reboot. Pour le BIOS : procédure de flash-back constructeur (si disponible).

**Spécificité PVE** : Le kernel Proxmox (basé sur Ubuntu) charge le microcode depuis l'initramfs. Les paquets `intel-microcode` et `amd64-microcode` de Debian fonctionnent normalement avec le kernel PVE.

---

**Remédiation** :

| Action | Priorité | Détail |
|--------|----------|--------|
| Changer les credentials par défaut | 🔴 Critique | Mot de passe ≥ 16 caractères, unique par serveur, stocké dans un gestionnaire de MDP |
| Isoler sur VLAN OOB dédié | 🔴 Critique | VLAN non routable vers internet ni vers le réseau VM/management PVE |
| Désactiver HTTP (forcer HTTPS) | 🔴 Critique | Via l'interface web BMC ou CLI ipmitool |
| Désactiver SNMP v1/v2c | 🟡 Important | Migrer vers SNMPv3 si monitoring nécessaire |
| Désactiver Telnet | 🔴 Critique | Via l'interface web BMC |
| Désactiver IPMI-over-LAN | 🟡 Important | Si non utilisé pour le monitoring |
| Mettre à jour le firmware BMC | 🔴 Critique | Depuis le site constructeur |
| Installer certificat TLS | 🟡 Important | Si le BMC supporte l'import de certificats |
| Activer le System Event Log | 🟡 Important | Pour la traçabilité des accès BMC |

**Valeur par défaut** : Credentials usine (`admin`/`admin`, `ADMIN`/`ADMIN`, ou similaire). HTTP actif. SNMP v1/v2c actif. Pas d'isolation réseau.

**Rollback** : Reset usine du BMC via le bouton physique ou la procédure constructeur.

**Spécificité PVE** : Proxmox n'a aucune interaction directe avec le BMC. La sécurisation du BMC est entièrement indépendante de PVE mais critique pour la sécurité globale de l'infrastructure.

**Références** :
- Forum Proxmox — cas documentés de ransomware via BMC
- NIST SP 800-123 — Guide to General Server Security

---

**Remédiation** :
1. Activer Secure Boot dans le BIOS/UEFI
2. Installer PVE normalement (ou redémarrer si déjà installé)
3. Vérifier que le système démarre et que tous les modules nécessaires se chargent :

**Valeur par défaut** : Dépend du matériel et du BIOS. Souvent désactivé sur les serveurs.

**Rollback** : Désactiver Secure Boot dans le BIOS/UEFI.

**Spécificité PVE** : Proxmox VE 9 supporte Secure Boot. Le kernel PVE et ses modules intégrés (ZFS, KVM) sont signés. Cependant, les modules tiers non signés sont bloqués. **Tester impérativement en lab avant activation en production.**

---

**Remédiation** :
1. Activer le TPM 2.0 dans le BIOS/UEFI
2. Vérifier la détection par le kernel

Pour l'auto-unlock LUKS via TPM (si LUKS est utilisé) :

**Valeur par défaut** : TPM souvent désactivé dans le BIOS par défaut sur les serveurs.

**Rollback** : Supprimer l'enrollment TPM : `systemd-cryptenroll /dev/sdX3 --wipe-slot=tpm2`. La passphrase LUKS reste fonctionnelle.

**Spécificité PVE** :
- PVE 9 supporte le vTPM (TPM virtuel) pour les VM guests — utile pour Windows 11 et les OS exigeant un TPM
- L'auto-unlock LUKS via TPM est une fonctionnalité Debian/systemd standard, indépendante de PVE
- **Alternatives sans TPM** : `dropbear-initramfs` (unlock SSH dans l'initramfs), `tang`/`clevis` (Network-Bound Disk Encryption — NBDE)

---

**Remédiation** :
Créer et maintenir un fichier d'inventaire par nœud. Modèle :

Mettre à jour après **chaque** changement de matériel ou de configuration.

**Valeur par défaut** : Aucun inventaire.

---

**Remédiation** :

Schéma complet (installateur Debian, conformité CIS Level 1+2) :

| Point de montage | CIS | Level | Taille recommandée | Options de montage |
|-----------------|-----|-------|--------------------|--------------------|
| `/` | — | — | 20-50 Go | `defaults` |
| `/boot` | — | — | 1 Go | `defaults,nosuid,nodev,noexec` |
| `/boot/efi` | — | — | 512 Mo | `defaults,nosuid,nodev,noexec` |
| `/tmp` | 1.1.2.1 | L1 | 5-10 Go | `defaults,nosuid,nodev,noexec` |
| `/dev/shm` | 1.1.2.2 | L1 | tmpfs | `defaults,nosuid,nodev,noexec` |
| `/home` | 1.1.2.3 | L1 | 5-10 Go | `defaults,nosuid,nodev` |
| `/var` | 1.1.2.4 | L1 | 20-50 Go | `defaults,nosuid,nodev` |
| `/var/tmp` | 1.1.2.5 | L1 | 5-10 Go | `defaults,nosuid,nodev,noexec` |
| `/var/log` | 1.1.2.6 | L1 | 10-20 Go | `defaults,nosuid,nodev,noexec` |
| `/var/log/audit` | 1.1.2.7 | L1 | 5-10 Go | `defaults,nosuid,nodev,noexec` |
| `/var/lib/vz` | PVE | — | Max ou volume dédié | `defaults,nosuid,nodev` |
| swap | — | — | 1-2x RAM (max 32 Go) | `sw` |

**Valeur par défaut** : L'installateur ISO PVE crée une partition unique root + swap (LVM) ou un pool ZFS sans séparation. Non conforme CIS 1.1.2.x.

**Rollback** : Les options de montage sont modifiables dans `/etc/fstab` + `mount -o remount`. Le partitionnement lui-même n'est pas modifiable sans réinstallation.

**Spécificité PVE** : `/var/lib/vz` est le répertoire de stockage local par défaut de Proxmox (images ISO, templates, snippets). Sur l'installateur ISO, il est créé comme un volume LVM-thin ou un dataset ZFS. Le séparer du root filesystem prévient l'épuisement de l'espace disque root par les images VM.

---

**Remédiation** :

Trois options (voir 0.2.1 pour le choix d'installation) :

**Option A — ZFS native encryption (via installateur PVE)** :
Sélectionner ZFS dans l'installateur et activer le chiffrement. Pour un chiffrement per-dataset post-installation :

**Option B — LUKS2 (via installateur Debian)** :
Choisir « Guided — use entire disk and set up encrypted LVM » dans l'installateur Debian 13. Puis installer Proxmox par-dessus.

**Option C — LUKS sous ZFS (post-installation, avancé)** :
Conversion in-place via live boot. Réservé aux experts.

**Impératifs communs** :

**Valeur par défaut** : Aucun chiffrement.

**Rollback** : Le chiffrement une fois appliqué n'est pas réversible sans réinstallation ou procédure de déchiffrement destructive.

**Spécificité PVE** :
- L'installateur ISO PVE **ne propose PAS LUKS pour ext4/XFS**. Le chiffrement dans l'installateur n'est disponible que pour ZFS.
- ZFS native encryption ne chiffre pas le root pool facilement (le boot doit lire le pool).
- Pour un chiffrement total (full disk encryption), la méthode Debian-first + LUKS est nécessaire.
- Le déverrouillage distant via `dropbear-initramfs` est recommandé pour les serveurs en datacenter :

---

MATÉRIEL
[ ] 0.1.1 — Firmware/BIOS à jour
[ ] 0.1.1 — Microcode CPU installé
[ ] 0.1.2 — Credentials BMC changés
[ ] 0.1.2 — BMC isolé sur VLAN OOB
[ ] 0.1.2 — Protocoles non chiffrés BMC désactivés
[ ] 0.1.3 — Secure Boot : décision documentée (activé/désactivé)
[ ] 0.1.4 — TPM 2.0 : décision documentée
[ ] 0.1.5 — Inventaire matériel rempli

ARCHITECTURE
[ ] 0.2.1 — Méthode d'installation choisie (ISO PVE / Debian-first)
[ ] 0.2.2 — Schéma de partitionnement défini
[ ] 0.2.3 — Stratégie de chiffrement définie + clés générées et stockées
[ ] 0.2.4 — Architecture réseau VLAN planifiée et documentée

PRÉREQUIS
[ ] Accès console hors-bande vérifié
[ ] ISO d'installation préparée (checksum SHA256 vérifié)
[ ] Procédure de déverrouillage distant planifiée (si LUKS)