Guide de Durcissement Proxmox VE 9 : 96 Contrôles CIS

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

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)

**Remédiation** :

Avec abonnement enterprise (🏢🌐 recommandé) :

Sans abonnement (🏠) :

**Valeur par défaut** : Dépôt enterprise activé (échoue sans licence). Clés GPG Proxmox installées.

**Rollback** :

**Spécificité PVE** : Ne jamais ajouter de dépôts tiers non vérifiés sur un hyperviseur. Le dépôt enterprise est préférable en production (paquets testés plus rigoureusement, signés par Proxmox GmbH).

---

**Remédiation** :

Contenu de `/etc/apt/apt.conf.d/50unattended-upgrades` :

Contenu de `/etc/apt/apt.conf.d/20auto-upgrades` :

**Valeur par défaut** : `unattended-upgrades` non installé.

**Rollback** : `apt purge unattended-upgrades`

**Spécificité PVE** : **Ne JAMAIS inclure les dépôts Proxmox dans unattended-upgrades.** Les mises à jour PVE (kernel, qemu-server, pve-manager) doivent être testées manuellement. Un kernel PVE qui ne démarre plus = downtime total. Procédure de mise à jour PVE manuelle → Phase 2 (2.4.1).

---

**Remédiation** :

**Valeur par défaut** : Varie selon la méthode d'installation. L'installateur ISO PVE installe un minimum. L'installateur Debian peut inclure des paquets supplémentaires selon les sélections tasksel.

---

**Remédiation** :

**Valeur par défaut** : Pas de mot de passe GRUB.

**Rollback** : Supprimer les lignes ajoutées dans `/etc/grub.d/40_custom` et `update-grub`.

---

**Remédiation** :

Créer `/etc/sysctl.d/90-cis-network.conf` :

**Valeur par défaut** : La plupart de ces paramètres sont à des valeurs permissives (accept_redirects=1, log_martians=0, etc.). `ip_forward` est activé par Proxmox.

**Rollback** : `rm /etc/sysctl.d/90-cis-network.conf && sysctl --system`

**Spécificité PVE** : **`net.ipv4.ip_forward = 1` est requis par Proxmox** pour le réseau des VM (bridges, NAT). Ne le désactivez PAS. Le CIS recommande de le mettre à 0 « si le système n'est pas un routeur » mais un hyperviseur Proxmox EST effectivement un routeur pour ses VM.

---

**Remédiation** :

Créer `/etc/sysctl.d/90-cis-kernel.conf` :

**Valeur par défaut** : La plupart à 0 ou 1 (permissif). `kptr_restrict=0`, `dmesg_restrict=0`, `ptrace_scope=0`.

**Rollback** : `rm /etc/sysctl.d/90-cis-kernel.conf && sysctl --system`

---

**Remédiation** :

Créer `/etc/modprobe.d/cis-hardening.conf` :

**Valeur par défaut** : Modules chargeables à la demande.

**Rollback** : `rm /etc/modprobe.d/cis-hardening.conf && update-initramfs -u`

---

GRUB_CMDLINE_LINUX_DEFAULT="quiet init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 slab_nomerge pti=on randomize_kstack_offset=on"

update-grub

**Audit** :

**Valeur par défaut** : `quiet` uniquement.

---

**Remédiation** :

Configurer `/etc/security/pwquality.conf` :

**Valeur par défaut** : Aucune politique de complexité.

---

**Remédiation** :

Configurer `/etc/security/faillock.conf` :

**Valeur par défaut** : Pas de verrouillage.

**Spécificité PVE** : **`even_deny_root` peut bloquer le cluster.** Les migrations et la réplication Proxmox utilisent SSH root entre les nœuds. Si l'authentification échoue plusieurs fois (ex : clé expirée), le compte root se verrouille sur le nœud distant → cluster cassé. Préférer Fail2Ban (Phase 3) pour la protection brute-force de root.

---

readonly TMOUT=900
export TMOUT

**Valeur par défaut** : Informations système dans `/etc/issue` (version Debian, hostname).

---

**Remédiation** :

Créer `/etc/audit/rules.d/cis-hardening.rules` :

**Valeur par défaut** : `auditd` non installé.

**Rollback** : `systemctl stop auditd && apt purge auditd`

---

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemKeepFree=1G
ForwardToSyslog=yes

systemctl restart systemd-journald

**Remédiation** :

**Valeur par défaut** : Tous les services PVE actifs.

**Rollback** : `systemctl unmask <service>`

**Spécificité PVE** : Sur un nœud membre d'un cluster, ne JAMAIS masquer `corosync.service`, `pve-ha-lrm.service`, `pve-ha-crm.service`.

---

**Remédiation** :

**Valeur par défaut** : AppArmor installé et actif sur Debian 13 et PVE 9.

**Spécificité PVE** : AppArmor est utilisé par PVE pour confiner les conteneurs LXC. Les profils par défaut sont fonctionnels. ⚠️ Régressions connues sur kernel 6.17 avec LXC nested — tester si nesting est utilisé.

---

DÉPÔTS & PAQUETS
[ ] 1.1.1 — Dépôts Proxmox configurés, apt update sans erreur
[ ] 1.1.2 — unattended-upgrades configuré (sécurité Debian uniquement)
[ ] 1.1.3 — Paquets inutiles supprimés

KERNEL & BOOT
[ ] 1.2.1 — Mot de passe GRUB configuré (Level 2)
[ ] 1.2.2 — Sysctl réseau CIS 3.3.x appliqués
[ ] 1.2.3 — Sysctl kernel appliqués (Level 2)
[ ] 1.2.4 — Modules kernel inutiles blacklistés
[ ] 1.2.5 — Paramètres boot kernel appliqués (Level 2)

COMPTES & AUTH
[ ] 1.3.1 — Politique mots de passe (pwquality)
[ ] 1.3.2 — Verrouillage après échecs (faillock)
[ ] 1.3.3 — Timeout shell (TMOUT=900)
[ ] 1.3.4 — Bannière de connexion

JOURNALISATION
[ ] 1.4.1 — auditd installé + règles CIS + règle /etc/pve
[ ] 1.4.2 — journald en mode persistent

SERVICES
[ ] 1.5.1 — Services inutiles désactivés
[ ] 1.5.2 — Services PVE non utilisés masqués

APPARMOR
[ ] 1.6.1 — AppArmor actif et fonctionnel

VALIDATION
[ ] Reboot effectué
[ ] SSH fonctionnel
[ ] Web UI :8006 accessible
[ ] VM/CT de test démarrable
[ ] En cluster : migration live testée
[ ] ss -tlnp : uniquement les ports attendus

**Remédiation** :

Créer ou modifier `/etc/default/pveproxy` :

**Valeur par défaut** : Le fichier `/etc/default/pveproxy` n'existe pas par défaut. Pveproxy utilise les ciphers par défaut d'OpenSSL (incluant des ciphers CBC SHA-256/SHA-384).

**Rollback** : `rm /etc/default/pveproxy && systemctl restart pveproxy`

**Spécificité PVE** : Pveproxy est un daemon Perl utilisant AnyEvent::TLS. La configuration se fait exclusivement via `/etc/default/pveproxy` — il n'y a pas de fichier de configuration Apache/Nginx.

---

**Remédiation** :

**Valeur par défaut** : Certificats auto-signés générés à l'installation.

**Spécificité PVE** : Proxmox intègre nativement le support ACME dans l'interface web (Datacenter > ACME, puis Node > System > Certificates). Le renouvellement automatique est géré par un timer systemd (`pve-daily-update.timer`).

---

**Remédiation** :

**Méthode 1 — ACL pveproxy** (simple, appliquée au niveau applicatif) :

Dans `/etc/default/pveproxy` :

**Méthode 2 — Firewall PVE** (recommandée, plus granulaire) :
Voir Phase 4 (4.2.2) pour la configuration complète des règles firewall par nœud.

**Méthode combinée** (🌐 recommandée) : Les deux méthodes sont complémentaires — la défense en profondeur.

**Valeur par défaut** : Aucune restriction. Pveproxy accepte les connexions de toutes les IP.

**Rollback** : Supprimer les lignes ALLOW_FROM/DENY_FROM/POLICY de `/etc/default/pveproxy` et `systemctl restart pveproxy`. Si lock-out : accéder via console et modifier le fichier.

**Spécificité PVE** : La syntaxe ALLOW_FROM accepte les notations CIDR, les plages IP, et les adresses individuelles séparées par des virgules. `LISTEN_IP` peut aussi restreindre l'interface d'écoute mais ne supporte qu'une seule IP.

---

**Valeur par défaut** : spiceproxy actif et en écoute sur le port 3128.

**Rollback** : `systemctl unmask spiceproxy.service && systemctl start spiceproxy`

---

**Remédiation** :

**Valeur par défaut** : Aucun token API créé.

**Spécificité PVE** : Avec `--privsep 1`, le token a des privilèges indépendants de l'utilisateur parent, ce qui permet le moindre privilège. La rotation des tokens se fait par suppression + recréation (`pveum user token remove` puis `add`).

---

**Remédiation** :
Les logs API sont actifs par défaut. S'assurer de leur centralisation :

**Valeur par défaut** : Logs actifs dans `/var/log/pveproxy/access.log`. Rotation via logrotate.

**Spécificité PVE** : Le format des logs pveproxy est spécifique (pas du Common Log Format standard). Les parseurs Fail2Ban doivent être adaptés (voir Phase 3 — 3.4.2).

---

**Remédiation** :

**Lors de la création du cluster** (méthode recommandée) :
Le chiffrement est activé par défaut lors de la création d'un cluster PVE 9 via l'interface web ou `pvecm create`.

**Sur un cluster existant** (nécessite un redémarrage de Corosync sur tous les nœuds) :

Modifier `/etc/corosync/corosync.conf` dans la section `totem` :

**Valeur par défaut** : Sur PVE 9, le chiffrement Corosync est activé par défaut à la création du cluster (`aes256` + `sha256`). Sur les clusters migrés depuis PVE 7/8, il peut être désactivé.

**Rollback** : Remettre `crypto_cipher: none` et `crypto_hash: none`, redémarrer Corosync sur tous les nœuds.

**Spécificité PVE** : Le réseau Corosync doit être sur un VLAN dédié (voir Phase 4). Même avec le chiffrement activé, un réseau partagé expose le trafic à des attaques de déni de service ciblant Corosync.

---

**Remédiation** :

**Valeur par défaut** : `/etc/pve` géré par pmxcfs, pas de sauvegarde automatique dédiée.

**Spécificité PVE** : `/etc/pve` est un mount FUSE. Il n'est pas accessible si `pve-cluster` n'est pas actif. Les modifications sont propagées automatiquement à tous les nœuds du cluster. La surveillance via auditd (configurée en Phase 1, 1.4.1) détecte les modifications.

---

**Remédiation** :

Via l'interface web : Datacenter > Options > Migration Settings

Via la CLI, modifier `/etc/pve/datacenter.cfg` :

**Valeur par défaut** : `migration: secure` est le défaut sur PVE 9 (vérifier sur les clusters migrés depuis des versions antérieures).

**Rollback** : Modifier `migration: insecure` dans `/etc/pve/datacenter.cfg`.

**Spécificité PVE** : Le mode `secure` utilise un tunnel SSH chiffré pour le transfert mémoire. Le mode `insecure` envoie les données en clair sur un port TCP éphémère (60000-60050). Même en mode `secure`, isoler le trafic de migration sur un VLAN dédié est recommandé pour la performance et la sécurité.

---

2. **Test en lab** : appliquer les mises à jour sur un nœud de test ou un PVE nested

3. **Rolling update en production** (un nœud à la fois) :

4. **Documentation** : noter les versions avant/après dans le journal des changements

**Valeur par défaut** : Pas de procédure définie. Les mises à jour sont à l'initiative de l'administrateur.

**Spécificité PVE** : Sur PVE 9, les breaking changes kernel 6.17 incluent le renommage d'interfaces réseau, des incompatibilités NVIDIA vGPU/DRBD, et des régressions AppArmor LXC. Toujours consulter les release notes avant une mise à jour kernel.

---

**Remédiation** :

**Valeur par défaut** : Proxmox conserve les anciens kernels installés. Pas d'épinglage.

---

**Remédiation** :

**Valeur par défaut** : etckeeper non installé.

---

INTERFACE WEB
[ ] 2.1.1 — Ciphers TLS durcis dans /etc/default/pveproxy
[ ] 2.1.2 — Certificats Let's Encrypt / ACME configurés (🏢🌐)
[ ] 2.1.3 — Accès Web UI restreint par IP
[ ] 2.1.4 — spiceproxy masqué si non utilisé (Level 2)

API
[ ] 2.2.1 — Tokens API utilisés (pas de mots de passe dans les scripts)
[ ] 2.2.2 — Accès API restreint par IP (Level 2)
[ ] 2.2.3 — Logs API collectés et centralisés

CLUSTER
[ ] 2.3.1 — Chiffrement Corosync activé (aes256 + sha256)
[ ] 2.3.2 — /etc/pve sauvegardé régulièrement
[ ] 2.3.3 — Migration configurée en mode secure + réseau dédié

MISES À JOUR
[ ] 2.4.1 — Procédure de mise à jour PVE documentée
[ ] 2.4.2 — Au moins 2 kernels installés

CONFIGURATION
[ ] 2.5.1 — etckeeper installé et fonctionnel (Level 2)

VALIDATION
[ ] Web UI accessible sur HTTPS avec certificat valide
[ ] sslscan/<PVE_IP>:8006 : uniquement TLS 1.2+ et ciphers AEAD
[ ] API fonctionnelle avec tokens
[ ] Cluster : pvecm status OK
[ ] Migration test : réussie en mode secure

**Audit** :

**Remédiation** :

**Étape 1 — Préparer les clés SSH AVANT de modifier sshd** :

**Étape 2 — Modifier la configuration sshd** :

Créer `/etc/ssh/sshd_config.d/hardening.conf` :

**Étape 3 — Tester et appliquer** :

**Valeur par défaut** : `PasswordAuthentication yes`, `PermitRootLogin yes`, `MaxAuthTries 6`, `X11Forwarding yes`.

**Rollback** : `rm /etc/ssh/sshd_config.d/hardening.conf && systemctl restart sshd`

**Spécificité PVE** :
- **Ne JAMAIS mettre `PermitRootLogin no`** sur un nœud cluster — casse les migrations et la réplication
- `prohibit-password` autorise les clés SSH root (nécessaire au cluster) mais interdit les mots de passe
- Pour la configuration SSH client des peers cluster (compatibilité clés RSA PVE), voir la section ssh-audit ci-dessous

---

**Remédiation** :

Ajouter dans `/etc/ssh/sshd_config.d/hardening.conf` :

**Configuration SSH client pour les peers cluster** :

Proxmox stocke des clés hôte RSA dans `/etc/pve/nodes/*/ssh_known_hosts`. Pour éviter les warnings lors des opérations cluster tout en utilisant Ed25519 pour l'accès externe :

Créer `/root/.ssh/config` sur chaque nœud :

**Valeur par défaut** : Algorithmes par défaut d'OpenSSL/OpenSSH incluant des options legacy.

---

**Remédiation** :

**Procédure recommandée (via interface web)** :
1. Se connecter à l'interface web PVE (`https://<PVE_IP>:8006`)
2. Aller dans **Datacenter > Permissions > Two Factor**
3. Cliquer **Add > TOTP**
4. Scanner le QR code avec votre app authenticator
5. Entrer le code de vérification
6. **Générer des Recovery Keys** (IMPÉRATIF — les stocker hors ligne)

**Pour imposer le 2FA au niveau du realm** :
- Via l'interface web : **Datacenter > Permissions > Realms** > sélectionner `pam` > **Edit** > **TFA** : sélectionner "OATH (TOTP)"
- ⚠️ Si vous sélectionnez "OATH (TOTP)" comme exigence du realm, **seul** TOTP sera accepté (pas WebAuthn). Pour autoriser TOTP ou WebAuthn au choix de l'utilisateur, laisser le champ TFA du realm à "none" et imposer le 2FA par politique organisationnelle.

**Procédure de récupération en cas de perte du token** :

**Valeur par défaut** : Aucun 2FA configuré.

**Spécificité PVE** : Le 2FA PVE est indépendant du 2FA PAM système. Il protège l'interface web et l'API REST, mais PAS l'accès SSH (qui est protégé par les clés SSH). C'est la combinaison des deux (clés SSH + 2FA web) qui assure la protection complète.

---

**Remédiation** :

**Rôles prédéfinis utiles PVE** :

| Rôle | Privilèges | Usage type |
|------|-----------|------------|
| `Administrator` | Tous | Admin infra (à limiter au strict nécessaire) |
| `PVEVMAdmin` | Gestion VM complète | Opérateur VM |
| `PVEVMUser` | Console, start/stop | Utilisateur VM |
| `PVEAuditor` | Lecture seule | Auditeur, monitoring |
| `PVEDatastoreUser` | Backup, restore | Opérateur backup |

**Valeur par défaut** : Seul `root@pam` existe avec tous les privilèges.

**Spécificité PVE** :
- Les nouveaux privilèges PVE 9 incluent `VM.Replicate` (ajouté) et `VM.Monitor` (supprimé). Vérifier les rôles custom après une mise à jour majeure.
- Préférer les groupes aux ACL individuelles pour faciliter la maintenance.
- Les ACL PVE supportent les chemins : `/`, `/vms/<vmid>`, `/storage/<storage>`, `/pool/<pool>`.

---

---

**Valeur par défaut** : Seuls les realms `pam` et `pve` sont configurés.

**Spécificité PVE** : La synchronisation LDAP importe les utilisateurs et groupes dans `/etc/pve/user.cfg`. Les mots de passe ne sont PAS stockés dans PVE (authentification relayée vers le serveur LDAP).

---

**Notes** : Le `bantime.increment` est crucial — après le premier ban de 1h, le deuxième sera de 24h, le troisième de 48h, etc. Rend le brute-force véritablement impraticable.

---

**Remédiation** :

**Filtre** — Créer `/etc/fail2ban/filter.d/proxmox.conf` :

**Jail** — Créer `/etc/fail2ban/jail.d/proxmox.conf` :

**Validation** :

**Valeur par défaut** : Fail2Ban non installé. Aucune protection brute-force sur le port 8006.

**Rollback** : `apt purge fail2ban`

**Spécificité PVE** :
- Le `journalmatch = _SYSTEMD_UNIT=pvedaemon.service` est essentiel pour la performance — sans lui, Fail2Ban scanne TOUT le journal systemd.
- Penser aussi à protéger le realm PAM : si PAM est un realm de login disponible, ajouter le jail `pam-generic` standard de Fail2Ban.
- En cluster, Fail2Ban doit être installé sur **chaque nœud** individuellement (la configuration n'est pas synchronisée via pmxcfs).

---

apt install -y wireguard

Créer `/etc/wireguard/wg0.conf` :

Puis restreindre l'accès SSH et web UI au VPN uniquement (via firewall PVE ou pveproxy ALLOW_FROM, voir Phase 2 et Phase 4).

**Valeur par défaut** : WireGuard non installé.

**Spécificité PVE** :
- Idéalement, WireGuard ne devrait PAS tourner sur l'hyperviseur lui-même mais dans une VM ou un conteneur dédié, ou sur un routeur externe. Cela évite qu'un bug WireGuard compromette directement l'hyperviseur. En pratique pour un serveur unique chez un hébergeur, le faire tourner sur l'hôte est acceptable.
- **Alternatives** : OpenVPN, Tailscale/Headscale (mesh VPN sans configuration NAT), ZeroTier.

---

SSH
[ ] 3.1.1 — Clés SSH configurées et testées AVANT modification sshd
[ ] 3.1.1 — PasswordAuthentication no
[ ] 3.1.1 — PermitRootLogin prohibit-password (pas 'no' en cluster !)
[ ] 3.1.1 — MaxAuthTries 3, X11Forwarding no
[ ] 3.1.2 — Algorithmes ssh-audit appliqués
[ ] 3.1.2 — Config SSH client pour peers cluster (/root/.ssh/config)

2FA
[ ] 3.2.1 — TOTP configuré pour tous les comptes admin
[ ] 3.2.1 — Recovery keys générées et stockées hors ligne
[ ] 3.2.2 — WebAuthn configuré (Level 2, 🏢🌐)

RBAC
[ ] 3.3.1 — Comptes nominatifs créés (root@pam non utilisé quotidiennement)
[ ] 3.3.1 — Groupes et rôles attribués
[ ] 3.3.2 — Rôles custom créés si nécessaire (Level 2)
[ ] 3.3.3 — LDAP/AD intégré si applicable (Level 2, 🏢)

FAIL2BAN
[ ] 3.4.1 — Jail SSH active et testée
[ ] 3.4.2 — Jail Proxmox web UI active avec backend systemd
[ ] 3.4.2 — Regex validé : fail2ban-regex systemd-journal proxmox.conf

VPN (🌐)
[ ] 3.5.1 — WireGuard déployé (si serveur exposé internet)
[ ] 3.5.1 — SSH et web UI accessibles uniquement via VPN

VALIDATION
[ ] Connexion SSH par clé fonctionnelle
[ ] Connexion web UI avec 2FA fonctionnelle
[ ] Fail2Ban : tester un échec d'auth et vérifier le ban
[ ] En cluster : migration live fonctionnelle (SSH root entre nœuds)
[ ] Procédure de récupération 2FA documentée et testée

**Remédiation** :

Architecture VLAN de référence (🏢🌐) :

| VLAN | Nom | Bridge PVE | Rôle | Ports |
|------|-----|-----------|------|-------|
| 10 | Management | vmbr0 | Web UI, SSH, API | 8006, 22 |
| 20 | VM/CT | vmbr1 | Trafic applicatif guests | Variable |
| 30 | Stockage | vmbr2 | NFS, iSCSI, Ceph public | 2049, 3260, 6789 |
| 40 | Cluster | vmbr3 | Corosync, migration | 5405/udp, 60000-60050 |
| 41 | Ceph cluster | vmbr4 | Réplication OSD (si Ceph) | 6800-7300 |
| 99 | OOB | — | BMC/IPMI (port physique dédié) | 443 |

Exemple `/etc/network/interfaces` (2 interfaces physiques, VLAN tagging) :

**Alternative — VLAN-aware bridge** (plus flexible, recommandé PVE 9) :

Avec un VLAN-aware bridge, les VM se voient attribuer un VLAN tag dans leur configuration réseau (ex: `tag=20`).

Architecture simplifiée (🏠) :

**Valeur par défaut** : L'installateur PVE crée un seul bridge `vmbr0` avec l'IP de management.

**Rollback** : Modifier `/etc/network/interfaces` et `ifreload -a`. ⚠️ Tester via console OOB — une erreur réseau rend le serveur inaccessible par SSH.

**Spécificité PVE** : Les VLAN-aware bridges sont la méthode recommandée par Proxmox. Chaque VM peut recevoir un tag VLAN dans sa config réseau sans créer de bridges supplémentaires.

---

**Remédiation** : Migrer les VM du bridge management vers un bridge VM dédié. Modifier la configuration réseau de chaque VM dans l'interface PVE (Hardware > Network Device > Bridge).

**Valeur par défaut** : Toutes les VM sur `vmbr0` (même bridge que le management).

---

**Remédiation** :

**Procédure pas à pas (anti lock-out)** :

**Étape 1** — Préparer les règles AVANT d'activer le firewall :

Créer `/etc/pve/firewall/cluster.fw` :

**Étape 2** — Vérifier l'accès OOB (IPMI/iDRAC/console) — en cas de lock-out.

**Étape 3** — Activer le firewall :

**Étape 4** — Tester IMMÉDIATEMENT :

**Étape 5** — Activer le firewall par nœud :

Créer `/etc/pve/nodes/<hostname>/host.fw` :

**Valeur par défaut** : Firewall **désactivé**. Aucune règle.

**Rollback** :

**Spécificité PVE** :
- Le firewall PVE est basé sur **iptables** (backend classique) ou **nftables** (nouveau backend `proxmox-firewall`, activable dans Host > Firewall > Options).
- Les règles sont stockées dans `/etc/pve/firewall/` (cluster) et distribuées automatiquement à tous les nœuds.
- Les **management hosts** sont définis par l'IPSet `management` qui inclut automatiquement le réseau du cluster. Cet IPSet peut être personnalisé.

---

[OPTIONS]
enable: 1

[RULES]

---

**Remédiation** :

Créer des Security Groups via l'interface web (Datacenter > Firewall > Security Group) ou via `/etc/pve/firewall/cluster.fw` :

Appliquer à une VM : VM > Firewall > Insert: Security Group

**Valeur par défaut** : Aucun Security Group. Firewall VM désactivé par défaut.

**Spécificité PVE** : Les Security Groups sont définis au niveau Datacenter mais appliqués au niveau VM. Ils sont réutilisables sur toutes les VM du cluster.

---

**Valeur par défaut** : `policy_forward: ACCEPT`

---

[OPTIONS]
nftables: 1

**Remédiation** : Voir Phase 1 (1.2.2) pour la configuration complète des sysctl réseau.

---

ARCHITECTURE RÉSEAU
[ ] 4.1.1 — Segmentation VLAN implémentée (🏢🌐)
[ ] 4.1.1 — Bridges configurés dans /etc/network/interfaces
[ ] 4.1.2 — VM sur bridge séparé du management

FIREWALL PVE
[ ] 4.2.1 — Firewall activé au niveau Datacenter (policy_in: DROP)
[ ] 4.2.1 — Règles d'accès management configurées (SSH, :8006)
[ ] 4.2.1 — Règles cluster configurées (Corosync, migration)
[ ] 4.2.2 — Firewall activé par nœud (host.fw)
[ ] 4.2.3 — Security Groups créés et appliqués aux VM
[ ] 4.2.4 — FORWARD policy évalué (Level 2)
[ ] 4.2.5 — Backend nftables évalué (Level 2)

RÉSEAU
[ ] 4.3.1 — ip_forward = 1 (requis PVE), rp_filter = 1

VALIDATION
[ ] Accès SSH fonctionnel depuis le réseau admin
[ ] Web UI accessible depuis le réseau admin
[ ] VM accessible depuis le réseau VM (pas management)
[ ] En cluster : Corosync fonctionnel (pvecm status)
[ ] En cluster : migration live réussie
[ ] Ceph fonctionnel (si applicable)
[ ] Test : accès Web UI depuis un réseau non-admin → bloqué
[ ] iptables -L -n | grep PVEFW : chaînes présentes

**Spécificité PVE** : Même si le root filesystem n'est pas chiffré, les données VM peuvent l'être via ZFS native encryption per-dataset. C'est un compromis acceptable pour les environnements où le FDE compliquerait trop les reboots.

---

**Remédiation** :

**Valeur par défaut** : `crc` (intégrité uniquement, pas de chiffrement).

**Rollback** : `ceph config set global ms_cluster_mode crc`

---

**Remédiation** : Si `/var/lib/vz` est sur le root filesystem (cas de l'installateur ISO avec LVM-thin), envisager de le déplacer sur un volume dédié lors de la prochaine maintenance.

**Spécificité PVE** : L'installateur ISO PVE crée un LVM-thin pool séparé pour les données VM (`data`), mais `/var/lib/vz` (ISOs, templates) reste sur le root LV par défaut. Pour ZFS, un dataset séparé est créé automatiquement.

---

---

CHIFFREMENT AU REPOS
[ ] 5.1.1 — Chiffrement vérifié (LUKS ou ZFS encryption)

CHIFFREMENT EN TRANSIT
[ ] 5.2.1 — Ceph Messenger v2 en mode secure (si Ceph)
[ ] 5.2.2 — NFS/iSCSI sécurisé (exports restreints, VLAN stockage)

STOCKAGE PVE
[ ] 5.3.1 — /var/lib/vz isolé ou surveillance espace disque
[ ] 5.3.2 — Permissions datastores vérifiées

**Valeur par défaut** : Seccomp activé par défaut dans QEMU sur PVE 9.

**Spécificité PVE** : Proxmox n'expose pas de paramètre pour désactiver seccomp dans la configuration VM standard. Seul l'ajout d'arguments QEMU custom (`-sandbox off`) via `args:` dans la config VM pourrait le désactiver — auditer les configurations pour s'en assurer.

---

**Remédiation** :

**Valeur par défaut** : KSM activé (`run = 1`) sur PVE pour économiser la mémoire.

**Rollback** : `echo 1 > /sys/kernel/mm/ksm/run`

---

**Remédiation** :
1. Activer VT-d (Intel) ou AMD-Vi dans le BIOS
2. Ajouter dans `/etc/default/grub` :

**Règle** : Ne JAMAIS passer un device PCI à une VM non fiable sans IOMMU vérifié fonctionnel.

---

---

**Remédiation** : Lors de la création, toujours cocher « Unprivileged container ». Pour convertir un conteneur existant : recréer (pas de conversion in-place possible).

**Spécificité PVE** :
- Les conteneurs privilégiés sont parfois nécessaires pour NFS mounts, certains modules kernel, ou Docker-in-LXC. Documenter et justifier chaque exception.
- **Docker dans LXC** : préférer Docker dans une VM en environnement sensible. Si LXC est nécessaire, utiliser un conteneur non privilégié avec nesting activé + keyctl.
- ⚠️ Régressions AppArmor + LXC nested sur kernel 6.17 — tester.

**Remédiation** : Configurer pour chaque VM/CT :
- `memory` : limite mémoire maximale
- `cores` : nombre de vCPU
- `cpulimit` : limite CPU en pourcentage (ex: `cpulimit: 2` = 2 cœurs max)
- `bwlimit` : limite bande passante réseau et I/O (via Options > Bandwidth Limit)

---

QEMU/KVM
[ ] 6.1.1 — Seccomp actif sur les processus QEMU
[ ] 6.1.2 — KSM désactivé (multi-tenant)
[ ] 6.1.3 — IOMMU actif et vérifié (si PCI passthrough)
[ ] 6.1.4 — VM en machine type q35, devices inutiles retirés

LXC
[ ] 6.2.1 — Tous les conteneurs en mode unprivileged
[ ] 6.2.2 — Limites cgroup configurées sur chaque VM/CT

VALIDATION
[ ] Vérifier seccomp : grep Seccomp /proc/<QEMU_PID>/status → 2
[ ] Vérifier KSM : cat /sys/kernel/mm/ksm/run → 0
[ ] Vérifier IOMMU : dmesg | grep IOMMU → enabled
[ ] Aucune VM avec args: contenant "-sandbox off"

**Alertes critiques à configurer** :

| Alerte | Seuil | Scénario |
|--------|-------|----------|
| Espace disque root < 10% | Warning à 20%, Critical à 10% | S2 |
| Espace stockage VM < 15% | Warning à 25% | S2 |
| Échecs auth > 10/h | Rate | S1 |
| CPU hôte > 90% soutenu 15min | Sustained | S3 |
| Certificat TLS expire < 14j | Days | S1 |
| Nœud cluster unreachable | Quorum | S4 |
| Backup PBS échoué | Boolean | S2 |
| Suppression massive de fichiers | Rate | S2 (ransomware) |

---

**Spécificité PVE** : Initialiser AIDE **après** avoir terminé toutes les phases de hardening. Sinon, la base de référence contiendra l'état non durci et les modifications de hardening seront signalées comme des altérations.

---

**Option B — Promtail + Loki** (plus moderne) :
Déployer Promtail dans une VM dédiée, configurer la collecte des journaux systemd et des fichiers de log PVE.

**Point critique** : Le serveur de centralisation ne doit PAS être administrable par les mêmes comptes que les nœuds PVE.

---

---

MONITORING
[ ] 7.1.1 — Solution de monitoring déployée
[ ] 7.1.1 — Alertes critiques configurées (disque, auth, backup, cluster)

DÉTECTION
[ ] 7.2.1 — AIDE initialisé (après hardening complet)
[ ] 7.2.2 — Logs centralisés vers serveur externe
[ ] 7.2.3 — Script audit.sh planifié mensuellement

Actions à prendre :
- Désactiver les comptes inutilisés : `pveum user modify <user> --enable 0`
- Révoquer les tokens API inutilisés : `pveum user token remove <user> <token>`
- Documenter les déviations