Guide de Durcissement Proxmox VE 9 : 96 Contrôles CIS
96 contrôles CIS pour durcir Proxmox VE 9 : réseau, stockage, authentification, VMs, RBAC — guide expert avec mappings MITRE ATT&CK et PCI DSS.
Guide de Durcissement Proxmox VE 9 : 96 Contrôles CIS
✅ 100% Gratuit · Aucune inscription
Ce que vous allez apprendre
Présentation
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
| Caractéristique | Ce guide | Guides existants |
|---|---|---|
| Format CIS hybride | Chaque contrôle suit la structure CIS (Audit/Remediation/Default Value) + mappings compliance | Formats variés, rarement alignés CIS |
| Mappings compliance intégrés | CIS Controls v8, MITRE ATT&CK, ISO 27001:2022, PCI DSS v4.0 | Peu ou pas de mappings |
| Threat model explicite | 10 scénarios d'attaque rattachés à chaque contrôle | Pas de threat model |
| 3 profils d'environnement | 🏠 Homelab, 🏢 Production, 🌐 Exposé internet | Pas de distinction |
| Contrôles validés | Testé sur PVE 9.x — pas de "non validé" dans le guide principal | Contrôles souvent non validés |
| Corrections d'erreurs | Corrige les erreurs des guides existants (syntaxe 2FA, Fail2Ban regex, firewall defaults, LUKS) | Erreurs propagées |
| Rollback documenté | Chaque contrôle risqué a sa procédure de retour arrière | Jamais documenté |
| Couverture hyperviseur | Isolation VM (seccomp, KSM, IOMMU), pas juste l'OS | Focalisé OS uniquement |
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
Structure du guide
| # | Fichier | Phase | Description | Contrôles |
|---|---|---|---|---|
| 01 | 01-threat-model.md | — | Modèle de menaces (10 scénarios MITRE ATT&CK) | — |
| 02 | 02-pre-installation.md | Phase 0 | Avant l'installation (matériel, BIOS, chiffrement, réseau) | 8 |
| 03 | 03-os-debian-durci.md | Phase 1 | Durcissement OS Debian 13 (kernel, comptes, audit, services) | 15 |
| 04 | 04-proxmox-specifique.md | Phase 2 | Durcissement Proxmox (pveproxy, cluster, API, mises à jour) | 12 |
| 05 | 05-acces-authentification.md | Phase 3 | Accès et authentification (SSH, 2FA, RBAC, Fail2Ban, VPN) | 12 |
| 06 | 06-reseau-segmentation.md | Phase 4 | Réseau et segmentation (VLAN, firewall PVE, security groups) | 8 |
| 07 | 07-stockage-chiffrement.md | Phase 5 | Stockage et chiffrement (LUKS, ZFS, Ceph, NFS/iSCSI) | 5 |
| 08 | 08-isolation-vm-ct.md | Phase 6 | Isolation VM/CT (seccomp, KSM, IOMMU, LXC) | 6 |
| 09 | 09-monitoring-detection.md | Phase 7 | Monitoring et détection (AIDE, logs centralisés, audit) | 3 |
| 10 | 10-maintenance-backup.md | Phase 8+9 | Maintenance, backup, reprise d'activité (PBS, DR drills) | 8 |
Quickstart
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 :
- SSH : clés uniquement + Fail2Ban → Phase 3
- Mises à jour auto sécurité Debian → Phase 1
- 2FA sur le web UI → Phase 3
- Backups PBS chiffrées → Phase 9
- Firewall PVE activé → Phase 4
🏢 Production — Parcours recommandé :
- Lire le threat model (30 min)
- Appliquer la Phase 0 (pré-installation) si nouveau déploiement
- Phases 1 → 4 dans l'ordre (Level 1 d'abord)
- Phase 9 (backup) en priorité si pas encore fait
- Phases 5 → 8 pour la défense en profondeur
- 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
- Toujours tester en lab avant d'appliquer en production
- Ne jamais fermer votre session SSH avant d'avoir testé la nouvelle configuration dans un second terminal
- Garder un accès console OOB en cas de lock-out
- Appliquer Level 1 d'abord, puis Level 2 quand Level 1 est stabilisé
- Documenter chaque déviation par rapport au guide (justification + acceptation du risque)
Corrections notables vs guides existants
| Erreur courante | Notre correction | Phase |
|---|---|---|
pveum realm modify <<pam>> --tfa type=<<oath>> (syntaxe invalide) |
Procédure via interface web documentée | 3 (3.2.1) |
Fail2Ban pointe vers /var/log/syslog (absent PVE 9) |
Backend systemd + journalmatch = _SYSTEMD_UNIT=pvedaemon.service |
3 (3.4.2) |
PermitRootLogin no (casse le cluster) |
PermitRootLogin prohibit-password + Match Address cluster |
3 (3.1.1) |
lockdown=integrity en production (casse ZFS/Ceph/GPU) |
Classé expérimental, exclu du guide principal | 1 (1.2.5) |
| Firewall PVE "INPUT=DROP par défaut" (faux) | Explication complète des règles anti-lockout cachées | 4 (4.2.1) |
| LUKS via installateur PVE (non disponible pour ext4) | Tableau comparatif ISO PVE vs Debian-first | 0 (0.2.1) |
KSM echo 2 > run (incomplet) |
Désactivation KSM + ksmtuned | 6 (6.1.2) |
| FORWARD=DROP sans règles cluster (casse les migrations) | Avertissement + prérequis réseau dédié | 4 (4.2.4) |
Format des contrôles
Chaque contrôle suit le format CIS Benchmark enrichi :
X.Y.Z — Titre du contrôle
| Profile Applicability | Level 1/2 — Server |
|---|---|
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | X.Y.Z |
| CIS Controls v8 | Safeguard mappé |
| MITRE ATT&CK | Techniques + Mitigations |
| ISO 27001:2022 | Annex A |
| PCI DSS v4.0 | Exigence |
| Scénario threat model | S1-S10 |
| Statut PVE 9 | ✅ Validé / ⚠️ Partiel / 🧪 Expérimental |
Description / Rationale / Impact / Audit / Remédiation
Valeur par défaut / Rollback / Spécificité PVE
---
Avertissements
⚠️ 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é.
Contribuer
Les contributions sont bienvenues. Voir CONTRIBUTING.md.
Licence
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
1.1 — Objectif et portée
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
| Élément | Inclus | Exclu |
|---|---|---|
| Hyperviseur Proxmox VE 9.x | ✅ | |
| OS hôte Debian 13 | ✅ | |
| Infrastructure réseau PVE (bridges, VLAN, firewall) | ✅ | |
| Stockage PVE (local, Ceph, NFS/iSCSI) | ✅ | |
| BMC/IPMI/iDRAC | ✅ | |
| Proxmox Backup Server | ✅ (interactions) | Guide dédié PBS hors périmètre |
| Sécurité des OS guests (VM/CT internes) | ❌ | |
| Sécurité applicative des workloads | ❌ | |
| Sécurité physique des locaux | ❌ (mentionnée, non couverte) |
1.2 — Surfaces d'attaque
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 :
| Composant | Port/Protocole |
| pveproxy (Web UI + API REST) | TCP 8006 |
| SSH | TCP 22 |
| VNC/SPICE/noVNC | Tunnelés via pveproxy |
| pvedaemon | TCP 85 (local) |
Criticité : Quiconque contrôle le plan de management contrôle tout — création/destruction de VM, accès backups, lecture mémoire des VM, modification de la configuration cluster.
| Composant | Port/Protocole |
| Bridges Linux (vmbr*) | Variable |
| Stockage NFS | TCP 2049 |
| Stockage iSCSI | TCP 3260 |
| Ceph public | TCP 6789, 6800-7300 |
| Migration live | TCP 60000-60050 |
Criticité : Une VM compromise peut tenter de pivoter via le réseau partagé ou tenter une évasion vers l'hôte via les devices émulés QEMU.
Référence : La documentation officielle de sécurité QEMU définit explicitement les guests, les interfaces utilisateur (VNC, SPICE), les protocoles réseau (NBD, migration) et les fichiers fournis par l'utilisateur comme des entités non fiables (untrusted).
| Composant | Port/Protocole |
| Corosync | UDP 5405 |
| pmxcfs | — |
| SSH inter-nœuds | TCP 22 |
Criticité : Compromettre un nœud = accès au filesystem cluster partagé (configurations, certificats, tokens de tous les nœuds).
| Composant | Accès |
| BMC/IPMI/iDRAC/iLO | Réseau OOB (TCP 443, UDP 623) |
| Console physique | Local |
| Disques physiques | Local |
| Ports USB | Local |
Criticité : Un BMC compromis donne un accès console virtuel complet, invisible depuis l'OS. Des cas de ransomware via BMC vulnérable sont documentés dans la communauté Proxmox.
1.3 — Profils d'environnement
| Profil | Symbole | Description | Menaces principales |
|---|---|---|---|
| Homelab | 🏠 | Nœud unique ou petit cluster, réseau local, pas d'exposition internet directe | Rebond depuis poste LAN compromis, erreur de config, accès physique accidentel |
| Production | 🏢 | Cluster multi-nœuds, réseau d'entreprise segmenté, SLA internes, multi-administrateurs | Mouvement latéral, insider malveillant, ransomware, non-conformité réglementaire |
| Exposé internet | 🌐 | Nœuds accessibles depuis internet (hébergeur, cloud privé, VPS) | Brute-force, exploitation CVE, compromission BMC, attaques ciblées, supply chain |
Règle : en cas de doute entre deux profils, choisir le plus restrictif.
1.4 — Scénarios d'attaque
Chaque scénario suit un format normalisé avec mappings compliance intégrés. Les scénarios sont ordonnés par probabilité décroissante.
| Probabilité | 🔴 Très élevée |
| Impact | Critique — contrôle total de l'hyperviseur |
| Profils | 🏠🏢🌐 |
| Vecteur | Réseau — plan de management |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Accès initial | Initial Access | Exploit Public-Facing Application | T1190 |
| Accès initial | Initial Access | Valid Accounts | T1078 |
| Accès initial | Initial Access | Brute Force | T1110 |
| Exécution | Execution | Command and Scripting Interpreter | T1059 |
| Persistance | Persistence | Account Manipulation | T1098 |
CIS Controls v8 : 4.1, 5.2, 5.4, 6.3, 6.4, 6.5, 13.1
ISO 27001:2022 : A.5.15, A.5.17, A.8.5, A.8.20
PCI DSS v4.0 : 2.2.1, 6.3.3, 8.2.1, 8.3.1, 8.3.6
Description :
Description :
Chaîne d'attaque type :
- Scan de ports → détection SSH (22) et/ou pveproxy (8006)
- Brute-force ou credential stuffing sur SSH/web UI
- Ou : exploitation d'une CVE pveproxy (ex : CVE-2023-43320 bypass 2FA, CVE-2025-57538/39/40 XSS stocké)
- Obtention d'un shell root ou d'une session web admin
- Contrôle total : création/suppression VM, accès backups, modification cluster
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Désactivation auth par mot de passe SSH | 3 | 3.1.1 | 🔴 Critique |
| 2FA obligatoire (TOTP ou WebAuthn) | 3 | 3.2 | 🔴 Critique |
| Fail2Ban SSH + Web UI (regex corrigé) | 3 | 3.4 | 🔴 Critique |
| Restriction IP sur pveproxy :8006 | 2 | 2.1.3 | 🔴 Critique |
| VPN comme unique entrée management | 3 | 3.5 | 🟡 Important (🌐) |
| Mise à jour régulière PVE | 2 | 2.4 | 🔴 Critique |
| RBAC moindre privilège | 3 | 3.3 | 🟡 Important |
Contrôles détectifs :
| Contrôle | Phase | Réf. |
|---|---|---|
| Centralisation logs auth | 7 | 7.2.3 |
| Alerting échecs auth multiples | 7 | 7.1.3 |
| Audit appels API | 2 | 2.2.3 |
CVE historiques pertinentes :
| CVE | Année | Type | CVSS |
|---|---|---|---|
| CVE-2023-43320 | 2023 | Bypass 2FA (PVE 5.4–8.0) | N/A |
| CVE-2025-57538/39/40 | 2025 | XSS stocké config Datacenter | N/A |
| CVE-2022-31358 | 2022 | XSS stocké | N/A |
| Probabilité | 🔴 Élevée |
| Impact | Critique — perte totale des données et des VM |
| Profils | 🏠🏢🌐 |
| Vecteur | Post-compromission (rebond après S1 ou poste admin compromis) |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Impact | Impact | Data Encrypted for Impact | T1486 |
| Impact | Impact | Inhibit System Recovery | T1490 |
| Impact | Impact | Data Destruction | T1485 |
| Mouvement | Lateral Movement | Remote Services: SSH | T1021.004 |
| Collection | Collection | Data from Local System | T1005 |
CIS Controls v8 : 3.4, 11.1, 11.2, 11.3, 11.4, 11.5
ISO 27001:2022 : A.8.13 (Information backup), A.8.14 (Redundancy), A.5.29 (Business continuity)
PCI DSS v4.0 : 3.5.1, 9.4.1, 12.10.1
Description :
Description :
Chaîne d'attaque type :
- Compromission initiale (S1, phishing admin, rebond LAN)
- Reconnaissance : stockage, backups PBS, snapshots
- Suppression des snapshots ZFS/LVM
- Suppression ou chiffrement des backups PBS
- Chiffrement des images disque VM
- Demande de rançon
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Backups PBS chiffrés client-side + clé escrow hors ligne | 9 | 9.1.2, 9.1.3 | 🔴 Critique |
| Immutabilité backups (retention lock PBS) | 9 | 9.1.3 | 🔴 Critique |
| Tokens PBS avec privilèges minimaux (pas de suppression) | 9 | 9.1.2 | 🔴 Critique |
| Backup hors site / hors ligne (3-2-1-1-0) | 9 | 9.1.1 | 🔴 Critique |
| Snapshots ZFS out-of-band | 5 | 5.3 | 🟡 Important |
| RBAC : séparer admin-VM et admin-backup | 3 | 3.3 | 🟡 Important |
Contrôles détectifs :
| Contrôle | Phase | Réf. |
|---|---|---|
| Monitoring espace stockage (suppression massive = alerte) | 7 | 7.1 |
| AIDE (intégrité fichiers) | 7 | 7.2.1 |
| Alerting suppression backups PBS | 7 | 7.1.3 |
| Probabilité | 🟡 Moyenne (en augmentation) |
| Impact | Critique — compromission de l'hôte depuis un guest |
| Profils | 🏢🌐 |
| Vecteur | VM compromise → exploitation QEMU/KVM → accès hôte |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Évasion | Privilege Escalation | Escape to Host | T1611 |
| Exploitation | Execution | Exploitation for Client Execution | T1203 |
| Découverte | Discovery | System Information Discovery | T1082 |
| Accès | Privilege Escalation | Exploitation for Privilege Escalation | T1068 |
CIS Controls v8 : 4.1, 7.1, 7.3, 10.5, 16.13
ISO 27001:2022 : A.8.7, A.8.8, A.8.9
PCI DSS v4.0 : 6.2.4, 6.3.3, 11.3.1
Description :
Description :
Particularité Proxmox : Contrairement à libvirt/sVirt qui confine chaque processus QEMU avec des labels SELinux automatiques, Proxmox ne génère pas de profils AppArmor par VM automatiquement. Les processus QEMU tournent en tant que root sans confinement mandatory access control par défaut. C'est une différence architecturale majeure documentée par le BSI.
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Profils AppArmor pour QEMU | 6 | 6.1.1 | 🟡 Important |
| Filtres seccomp QEMU | 6 | 6.1.2 | 🟡 Important |
| Suppression devices émulés inutiles | 6 | 6.1.5 | 🟡 Important |
| Machine type q35 (meilleure isolation) | 6 | 6.1.5 | 🟡 Important |
| KSM désactivé (side-channel multi-tenant) | 6 | 6.1.4 | 🟡 Important |
| IOMMU vérifié pour PCI passthrough | 6 | 6.1.3 | 🔴 Critique si passthrough |
| Mise à jour kernel + QEMU prioritaire | 2 | 2.4 | 🔴 Critique |
| Paramètres boot kernel durcis | 1 | 1.2.5 | 🟡 Important |
Contrôles détectifs :
| Contrôle | Phase | Réf. |
|---|---|---|
| auditd modules kernel + syscalls | 1 | 1.4.1 |
| Monitoring processus anormaux sur l'hôte | 7 | 7.2 |
Références :
- BSI — Sicherheitsanalyse von KVM (KVMSec) v1.0.1, 2017
- QEMU Project — Security Documentation (modèle d'entités non fiables)
- Red Hat — Hardening QEMU through continuous security testing
| Probabilité | 🟡 Moyenne |
| Impact | Critique — compromission de tous les nœuds |
| Profils | 🏢🌐 |
| Vecteur | Réseau interne — plan cluster |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Mouvement | Lateral Movement | Remote Services: SSH | T1021.004 |
| Mouvement | Lateral Movement | Exploitation of Remote Services | T1210 |
| Collecte | Credential Access | Unsecured Credentials: Private Keys | T1552.004 |
| Collecte | Collection | Data from Information Repositories | T1213 |
CIS Controls v8 : 4.1, 6.1, 6.4, 12.2, 13.1
ISO 27001:2022 : A.8.20, A.8.22, A.8.24
PCI DSS v4.0 : 1.2.1, 1.3.1, 4.2.1
Description :
Description :
Chaîne d'attaque type :
- Compromission d'un nœud (via S1 ou S3)
- Lecture
/etc/pve→ certificats cluster, clés SSH, tokens API - SSH root vers les autres nœuds (confiance implicite)
- Interception/injection Corosync si non chiffré
- Contrôle de l'ensemble du cluster
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Réseau dédié Corosync (VLAN isolé) | 4 | 4.1.1 | 🔴 Critique |
| Chiffrement Corosync | 2 | 2.3.1 | 🔴 Critique |
| Segmentation VLAN management/cluster/VM | 4 | 4.1 | 🔴 Critique |
| Restriction SSH inter-nœuds au réseau cluster | 3 | 3.1.1 | 🟡 Important |
| Firewall PVE FORWARD=DROP + règles explicites | 4 | 4.2 | 🟡 Important |
Contrôles détectifs :
| Contrôle | Phase | Réf. |
|---|---|---|
| Monitoring connexions SSH inter-nœuds | 7 | 7.2.4 |
| Alerting changements config cluster | 7 | 7.2 |
| auditd sur /etc/pve | 1 | 1.4.1 |
| Probabilité | 🟡 Moyenne (🔴 si BMC exposé internet) |
| Impact | Critique — contrôle physique total du serveur |
| Profils | 🏢🌐 |
| Vecteur | Réseau — plan physique/OOB |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Accès initial | Initial Access | External Remote Services | T1133 |
| Accès initial | Initial Access | Valid Accounts: Default Accounts | T1078.001 |
| Persistance | Persistence | Pre-OS Boot: Component Firmware | T1542.002 |
| Accès | Privilege Escalation | Hardware Additions | T1200 |
CIS Controls v8 : 1.1, 2.2, 4.1, 4.6, 12.2
ISO 27001:2022 : A.5.15, A.7.2, A.8.9, A.8.20
PCI DSS v4.0 : 2.2.1, 9.2.1, 11.3.1
Description :
Description :
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Isolation BMC sur VLAN OOB dédié | 0 | 0.1.2 | 🔴 Critique |
| Changement credentials par défaut | 0 | 0.1.2 | 🔴 Critique |
| Désactivation protocoles non chiffrés | 0 | 0.1.2 | 🔴 Critique |
| Mise à jour firmware BMC | 0 | 0.1.1 | 🔴 Critique |
| Certificats TLS sur interface web BMC | 0 | 0.1.2 | 🟡 Important |
| Probabilité | 🟡 Moyenne |
| Impact | Variable — fuite de données à destruction |
| Profils | 🏢 |
| Vecteur | Accès légitime — plan de management |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Collection | Collection | Data from Local System | T1005 |
| Exfiltration | Exfiltration | Exfiltration Over Web Service | T1567 |
| Impact | Impact | Data Destruction | T1485 |
| Évasion | Defense Evasion | Indicator Removal: Clear Linux Logs | T1070.002 |
CIS Controls v8 : 3.3, 5.3, 5.4, 6.1, 6.2, 8.2, 8.5
ISO 27001:2022 : A.5.10, A.5.15, A.6.1, A.8.15
PCI DSS v4.0 : 7.2.1, 8.2.1, 10.2.1
Description :
Description :
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| RBAC strict moindre privilège | 3 | 3.3 | 🔴 Critique |
| Comptes nommés individuels | 3 | 3.3.1 | 🔴 Critique |
| 2FA sur tous les comptes | 3 | 3.2.3 | 🔴 Critique |
| Séparation des rôles | 3 | 3.3.2 | 🟡 Important |
| Revue trimestrielle des accès | 8 | 8.2.1 | 🟡 Important |
Contrôles détectifs :
| Contrôle | Phase | Réf. |
|---|---|---|
| Journalisation appels API | 2 | 2.2.3 |
| auditd fichiers sensibles | 1 | 1.4.1 |
| Logs centralisés hors contrôle admin PVE | 7 | 7.2.3 |
| Probabilité | 🟠 Faible-Moyenne |
| Impact | Critique — backdoor persistante sur tous les nœuds |
| Profils | 🏠🏢🌐 |
| Vecteur | Réseau — mises à jour |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Accès initial | Initial Access | Supply Chain Compromise: Software | T1195.002 |
| Exécution | Execution | System Services: Service Execution | T1569.002 |
| Persistance | Persistence | Compromise Client Software Binary | T1554 |
CIS Controls v8 : 2.2, 2.5, 7.3, 16.4
ISO 27001:2022 : A.8.8, A.8.10
PCI DSS v4.0 : 6.3.2, 6.3.3
Description :
Description :
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Vérification signatures GPG (ne pas désactiver) | 1 | 1.1.1 | 🔴 Critique |
| Dépôt enterprise (signé Proxmox GmbH) | 1 | 1.1.1 | 🟡 Important |
| Vérification intégrité paquets installés | 1 | 1.1.3 | 🟡 Important |
| Pas de dépôts tiers non vérifiés | 1 | 1.1.1 | 🔴 Critique |
Contrôles détectifs :
| Contrôle | Phase | Réf. |
|---|---|---|
| Vérification périodique intégrité (debsums) | 7 | 7.2 |
| AIDE (changements binaires) | 7 | 7.2.1 |
| Probabilité | 🟠 Faible |
| Impact | Critique — accès mémoire hôte |
| Profils | 🏢🌐 |
| Vecteur | VM compromise + device passthrough → DMA → mémoire hôte |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Évasion | Privilege Escalation | Escape to Host | T1611 |
| Accès | Privilege Escalation | Exploitation for Privilege Escalation | T1068 |
CIS Controls v8 : 4.1, 4.8
ISO 27001:2022 : A.8.9
Description :
Description :
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| IOMMU activé et vérifié (VT-d / AMD-Vi) | 6 | 6.1.3 | 🔴 Critique |
| IOMMU groups isolés | 6 | 6.1.3 | 🔴 Critique |
| Pas de passthrough vers VM non fiables | 6 | 6.1.3 | 🔴 Critique |
Paramètres kernel intel_iommu=on iommu=pt |
1 | 1.2.5 | 🔴 Critique |
| Probabilité | 🟠 Faible (accès réseau interne requis) |
| Impact | Élevé — vol de données, injection |
| Profils | 🏢 |
| Vecteur | Réseau interne — plan données/cluster |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Collecte | Credential Access | Adversary-in-the-Middle | T1557 |
| Collecte | Collection | Data from Network Shared Drive | T1039 |
CIS Controls v8 : 3.10, 12.2, 12.6
ISO 27001:2022 : A.8.20, A.8.24
PCI DSS v4.0 : 4.2.1
Description :
Description :
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Réseaux dédiés Ceph et migration | 4 | 4.1.1 | 🔴 Critique |
| Chiffrement Ceph en transit (Messenger v2) | 5 | 5.2.1 | 🟡 Important |
| Migration chiffrée | 2 | 2.3.3 | 🟡 Important |
| VLAN isolation stricte | 4 | 4.1 | 🔴 Critique |
| Probabilité | Variable |
| Impact | Critique — compromission totale |
| Profils | 🏠🏢 |
| Vecteur | Physique |
MITRE ATT&CK :
| Phase | Tactique | Technique | ID |
|---|---|---|---|
| Accès initial | Initial Access | Hardware Additions | T1200 |
| Accès initial | Initial Access | Replication Through Removable Media | T1091 |
| Persistance | Persistence | Pre-OS Boot | T1542 |
| Collecte | Collection | Data from Local System | T1005 |
CIS Controls v8 : 3.6, 4.1, 4.6
ISO 27001:2022 : A.7.1, A.7.2, A.7.4, A.8.24
PCI DSS v4.0 : 9.1.1, 9.2.1, 9.4.1
Description :
Description :
Contrôles préventifs :
| Contrôle | Phase | Réf. | Priorité |
|---|---|---|---|
| Chiffrement disques (LUKS2 / ZFS encryption) | 0 | 0.2.3 | 🔴 Critique (🌐) |
| Mot de passe GRUB | 1 | 1.2.1 | 🟡 Important |
| Secure Boot | 0 | 0.1.3 | 🟡 Important |
| Désactivation boot USB dans BIOS | 0 | 0.1.1 | 🟡 Important |
| TPM 2.0 pour scellement clés | 0 | 0.1.4 | 🟡 Important |
1.5 — Matrice menaces ↔ phases du guide
| Scénario | Ph.0 | Ph.1 | Ph.2 | Ph.3 | Ph.4 | Ph.5 | Ph.6 | Ph.7 | Ph.8 | Ph.9 |
|---|---|---|---|---|---|---|---|---|---|---|
| S1 SSH/Web | ● | ●●● | ● | ●● | ● | |||||
| S2 Ransomware | ● | ●● | ● | ●● | ●●● | |||||
| S3 VM escape | ● | ●● | ●●● | ● | ||||||
| S4 Cluster | ●● | ● | ●●● | ●● | ||||||
| S5 BMC | ●●● | ● | ||||||||
| S6 Insider | ●●● | ●●● | ●● | ● | ||||||
| S7 Supply chain | ●●● | ● | ●● | |||||||
| S8 PCI/DMA | ● | ●●● | ||||||||
| S9 Interception | ●● | ●●● | ●● | |||||||
| S10 Physique | ●●● | ● | ●● |
Légende : ● pertinent, ●● important, ●●● critique pour ce scénario
1.6 — Priorisation par profil
🏠 Homelab — Top 5 actions
| # | Action | Scénario | Phase |
|---|---|---|---|
| 1 | SSH clés uniquement + Fail2Ban | S1 | 3 |
| 2 | Mises à jour auto sécurité Debian | S7 | 1 |
| 3 | 2FA sur le web UI | S1, S6 | 3 |
| 4 | Backups PBS chiffrées + hors site | S2 | 9 |
| 5 | Firewall PVE politique restrictive | S1 | 4 |
🏢 Production — Top 10
| # | Action | Scénario | Phase |
|---|---|---|---|
| 1-5 | Tout le Top 5 homelab | — | — |
| 6 | RBAC strict comptes nommés | S6 | 3 |
| 7 | Segmentation VLAN complète | S4, S9 | 4 |
| 8 | Chiffrement Corosync | S4 | 2 |
| 9 | Logs centralisés hors contrôle admin PVE | S6 | 7 |
| 10 | BMC isolé VLAN OOB | S5 | 0 |
🌐 Exposé internet — Ajouts critiques
| # | Action | Scénario | Phase |
|---|---|---|---|
| 11 | VPN unique entrée management | S1 | 3 |
| 12 | WebAuthn/FIDO2 (résistant phishing) | S1 | 3 |
| 13 | Profils AppArmor QEMU | S3 | 6 |
| 14 | BMC jamais exposé internet | S5 | 0 |
| 15 | Chiffrement disques complet (LUKS2) | S10 | 0 |
| 16 | Secure Boot | S10 | 0 |
| 17 | IOMMU vérifié pour tout passthrough | S8 | 6 |
1.7 — Références
| Source | Description | Date |
|---|---|---|
| BSI — Sicherheitsanalyse von KVM (KVMSec) v1.0.1 | Analyse de sécurité KVM/QEMU avec recommandations (AppArmor/sVirt, seccomp, devices) | 2017 |
| QEMU Project — Security Documentation | Modèle de sécurité QEMU, entités non fiables, principe de moindre privilège | En cours |
| Red Hat — Hardening QEMU through continuous security testing | Mécanismes de durcissement continu (fuzzing, Coverity, analyse statique) | 2025 |
| OpenStack Security Guide — Hardening the Virtualization Layers | Recommandations minimisation QEMU, compiler hardening, sVirt/AppArmor | En cours |
| CIS — Debian Linux 13 Benchmark v1.0.0 | Benchmark de configuration sécurisée Debian 13 | 2025-12-16 |
| MITRE — ATT&CK Framework v16 | Tactiques, techniques et procédures adversaires | 2025 |
| CIS — Controls v8 | Contrôles de sécurité prioritisés | 2021 |
| Proxmox Forum — Security Hardening threads | Retours communautaires, cas BMC/ransomware | 2021-2026 |
| CVE databases (OpenCVE, CVEDetails, Akaoma) | Vulnérabilités Proxmox VE documentées | Continu |
Navigation : ← 00-introduction.md | 02-pre-installation.md →
-e
02 — Phase 0 : Avant l'installation
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0 (2025-12-16) Scénarios du threat model : S5, S7, S10
Conventions du format
Chaque contrôle suit la structure du CIS Benchmark, enrichie de champs spécifiques à Proxmox VE :
| Champ | Description |
|---|---|
| Profile Applicability | Level 1 (baseline) / Level 2 (defense-in-depth) — conforme au CIS |
| Applicabilité PVE | 🏠 Homelab / 🏢 Production / 🌐 Exposé internet |
| Réf. CIS Debian 13 | Numéro de section CIS correspondant (si applicable) |
| CIS Controls v8 | Safeguard CIS Controls v8 mappé |
| MITRE ATT&CK | Techniques / Tactics / Mitigations |
| ISO 27001:2022 | Contrôle Annex A mappé |
| PCI DSS v4.0 | Exigence PCI DSS mappée |
| Scénario threat model | Référence S1-S10 du chapitre 01 |
| Statut PVE 9 | ✅ Validé / ⚠️ Partiel / 🧪 Expérimental |
| Description | Ce que fait le contrôle |
| Rationale | Pourquoi ce contrôle est nécessaire |
| Impact | Conséquences opérationnelles |
| Audit | Commande(s) de vérification + résultat attendu |
| Remédiation | Commande(s) d'application |
| Valeur par défaut | Valeur sur une installation fraîche |
| Rollback | Procédure de retour arrière (ajout Proxmox) |
| Spécificité PVE | Notes spécifiques à Proxmox (ajout Proxmox) |
| Références | Sources additionnelles |
0.1 — Préparation matérielle
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Hors périmètre CIS (prérequis matériel) |
| CIS Controls v8 | 2.2 — Ensure Authorized Software is Currently Supported |
| MITRE ATT&CK | T1542 (Pre-OS Boot), T1195 (Supply Chain Compromise) |
| ISO 27001:2022 | A.8.8 — Management of technical vulnerabilities |
| PCI DSS v4.0 | 6.3.3 — Install security patches within one month |
| Scénario threat model | S5 (BMC), S10 (accès physique) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Reboot nécessaire. Un flash de BIOS raté peut bricker le serveur — prévoir un accès console physique ou IPMI. Certaines mises à jour de microcode peuvent réduire très légèrement les performances (~1-3%) sur les workloads affectés par les mitigations Spectre.
🔍 Audit
Audit :
Version BIOS/UEFI
dmidecode -t bios | grep -E "Vendor|Version|Release Date"
Résultat attendu : version correspondant à la dernière release constructeur
Version microcode CPU
journalctl -k | grep -i microcode
ou :
cat /proc/cpuinfo | grep -m1 microcode
Résultat attendu : version récente (comparer avec les advisories Intel/AMD)
Vérification des mitigations CPU actives
cat /sys/devices/system/cpu/vulnerabilities/*
Résultat attendu : "Mitigation:" sur chaque ligne (pas "Vulnerable")
**Remédiation** :1. Firmware BIOS : procédure constructeur (Dell, HP, Lenovo, Supermicro)
Télécharger depuis le site officiel, vérifier le checksum, appliquer
2. Microcode CPU via paquets Debian :
apt update
Intel
apt install -y intel-microcode
AMD
apt install -y amd64-microcode
3. Redémarrer pour appliquer
reboot
**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.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 (N/A si matériel sans BMC) |
| Réf. CIS Debian 13 | Hors périmètre CIS (couche matérielle) |
| CIS Controls v8 | 4.1 — Establish and Maintain a Secure Configuration Process |
| MITRE ATT&CK | T1200 (Hardware Additions), T1133 (External Remote Services), T1078 (Valid Accounts) |
| ISO 27001:2022 | A.8.9 — Configuration management, A.5.15 — Access control |
| PCI DSS v4.0 | 2.2.1 — Develop configuration standards for system components |
| Scénario threat model | S5 (Compromission BMC) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Faible. Nécessite un accès au réseau BMC pour la configuration initiale.
🔍 Audit
Audit :
Vérifier que le BMC N'EST PAS accessible depuis le réseau management PVE
(exécuter depuis un hôte sur le réseau management, PAS le réseau OOB)
nmap -sV <adresse_IP_BMC> -p 80,443,623,5900 --max-retries 1
Résultat attendu : tous les ports filtrés ou host unreachable
(le BMC ne doit être joignable QUE depuis le VLAN OOB)
Vérifier les protocoles actifs (depuis le réseau OOB)
ipmitool -I lanplus -H <BMC_IP> -U admin -P <password> lan print 1
Vérifier : Auth Type = PASSWORD uniquement n'est pas acceptable
Résultat attendu : des méthodes d'authentification fortes
**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
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Hors périmètre CIS |
| CIS Controls v8 | 4.1 — Establish and Maintain a Secure Configuration Process |
| MITRE ATT&CK | T1542.003 (Bootkit), T1014 (Rootkit) |
| ISO 27001:2022 | A.8.9 — Configuration management |
| PCI DSS v4.0 | 2.2.1 |
| Scénario threat model | S10 (accès physique) |
| Statut PVE 9 | ⚠️ Partiel — fonctionnel mais incompatible avec certains modules tiers |
Description :
Description :
Rationale :
Rationale :
Impact :
Moyen à élevé. Les modules kernel non signés ne se chargeront pas. Cela affecte :
- Drivers NVIDIA propriétaires (GPU passthrough) — ❌ ne fonctionneront pas sans signature personnalisée
- Certains modules DRBD — ⚠️ vérifier la compatibilité
- Modules kernel out-of-tree tiers — ❌ bloqués
- ZFS (inclus dans le kernel PVE) — ✅ fonctionne
- Modules kernel Proxmox standard — ✅ fonctionnent
🔍 Audit
Audit :
mokutil --sb-state
Résultat attendu : "SecureBoot enabled"
Alternative si mokutil non installé :
dmesg | grep -i "secure boot"
Résultat attendu : "Secure boot enabled"
**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 :lsmod | grep -E "zfs|kvm|vhost"
Résultat attendu : modules présents et chargés
**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.**
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Hors périmètre CIS |
| CIS Controls v8 | 3.6 — Encrypt Data on End-User Devices |
| MITRE ATT&CK | T1542 (Pre-OS Boot), M1026 (Privileged Account Management) |
| ISO 27001:2022 | A.8.24 — Use of cryptography |
| PCI DSS v4.0 | 3.5.1 |
| Scénario threat model | S10 (accès physique) |
| Statut PVE 9 | ✅ Validé (vTPM pour VM), ⚠️ Partiel (auto-unlock LUKS) |
Description :
Description :
Rationale :
Rationale :
Impact :
Faible. Le TPM est transparent une fois configuré. L'auto-unlock via TPM protège contre le vol de disques mais PAS contre un attaquant ayant accès à l'ensemble du serveur (le TPM est sur la carte mère).
🔍 Audit
Audit :
cat /sys/class/tpm/tpm0/tpm_version_major 2>/dev/null
Résultat attendu : 2
dmesg | grep -i tpm
Résultat attendu : lignes indiquant un TPM détecté et initialisé
**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é) :apt install -y systemd-cryptenroll tpm2-tools
Enregistrer la clé TPM pour un volume LUKS
systemd-cryptenroll /dev/sdX3 --tpm2-device=auto --tpm2-pcrs=0+1+7
PCR 0 = firmware, PCR 1 = firmware config, PCR 7 = Secure Boot state
Générer une clé de récupération (IMPÉRATIF)
systemd-cryptenroll /dev/sdX3 --recovery-key
STOCKER CETTE CLÉ HORS LIGNE (password manager, coffre-fort)
**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)
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Hors périmètre CIS |
| CIS Controls v8 | 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory |
| MITRE ATT&CK | T1082 (System Information Discovery) — contrôle défensif |
| ISO 27001:2022 | A.5.9 — Inventory of information and other associated assets |
| PCI DSS v4.0 | 9.9.1 — Maintain a listing of devices |
| Scénario threat model | Tous |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nul.
🔍 Audit
Audit :
Script de génération d'inventaire rapide
echo "=== SYSTEM ===" && dmidecode -t system | grep -E "Manufacturer|Product|Serial" && \
echo "=== BIOS ===" && dmidecode -t bios | grep -E "Vendor|Version|Release" && \
echo "=== CPU ===" && lscpu | grep -E "Model name|Socket|Thread" && \
echo "=== RAM ===" && free -h | grep Mem && \
echo "=== STORAGE ===" && lsblk -d -o NAME,SIZE,MODEL,SERIAL && \
echo "=== NETWORK ===" && ip -br link show && \
echo "=== PVE ===" && pveversion -v 2>/dev/null && \
echo "=== KERNEL ===" && uname -r
Résultat attendu : informations complètes pour alimenter le tableau d'inventaire
**Remédiation** :
Créer et maintenir un fichier d'inventaire par nœud. Modèle :
| Champ | Valeur |
|---|---|
| Hostname | pve-node01 |
| Modèle | Dell PowerEdge R750 |
| N° série | [À renseigner] |
| CPU | 2x Intel Xeon Gold 6338 |
| RAM | 256 Go DDR4 ECC |
| Disques OS | 2x 480 Go SSD SATA (RAID1) |
| Disques VM | 4x 1.92 To NVMe |
| Réseau | 2x 25 GbE + 2x 1 GbE |
| BIOS | v2.12.2 (2025-10-15) |
| BMC | iLO 5 v3.10 |
| PVE | 9.1-3 |
| Kernel | 6.12.6-1-pve |
| Emplacement | Rack A, U12-14 |
| VLAN Mgmt | 10 — 10.0.10.11/24 |
| VLAN BMC | 99 — 10.0.99.11/24 |
| Dernier audit | 2026-03-20 |
Mettre à jour après **chaque** changement de matériel ou de configuration.
**Valeur par défaut** : Aucun inventaire.
---
0.2 — Choix d'installation
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Prérequis global (conditionne 1.1.x partitionnement) |
| CIS Controls v8 | 4.1 — Establish and Maintain a Secure Configuration Process |
| ISO 27001:2022 | A.8.9 — Configuration management |
| Scénario threat model | S7 (supply chain), S10 (accès physique) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Décision architecturale irréversible. L'installateur ISO Proxmox ne propose pas d'option LUKS pour ext4/XFS. Les options de chiffrement dans l'installateur PVE n'existent que pour ZFS.
| Critère | ISO Proxmox | Debian 13 + dépôt PVE |
|---|---|---|
| Simplicité | ✅ Assistée | ❌ Manuelle |
| Support Proxmox GmbH | ✅ Méthode principale | ⚠️ Supportée |
| Partitionnement CIS (1.1.x) | ❌ Schéma fixe | ✅ Contrôle total |
| LUKS sur ext4/LVM | ❌ Non disponible | ✅ Via installateur Debian |
| ZFS encryption | ✅ Disponible | ⚠️ Installation manuelle |
| Conformité CIS complète | ❌ Partitions non séparées | ✅ Possible |
| Risque opérationnel | Faible | Moyen |
Remédiation (recommandation par profil) :
| Profil | Recommandation |
|---|---|
| 🏠 Homelab | ISO Proxmox — simple, fiable |
| 🏢 Prod sans exigence CIS strict | ISO Proxmox + ZFS encryption si chiffrement requis |
| 🏢🌐 Prod avec conformité CIS ou LUKS obligatoire | Debian 13 + dépôt Proxmox |
Si Debian 13 + dépôt PVE : suivre https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_13_Trixie
Pièges documentés :
- Ne PAS installer d'environnement de bureau
- Sélectionner uniquement
Standard system utilities+SSH server - Configurer un hostname FQDN résolvable (requis par Proxmox)
- Retirer le kernel Debian APRÈS vérification du boot sur kernel PVE
Valeur par défaut : N/A (choix initial).
Spécificité PVE : L'installateur ISO PVE utilise un partitionnement prédéfini : une partition EFI, un VG LVM avec root + swap (ou ZFS avec root pool + data pool). Ce schéma ne crée PAS de partitions séparées pour /tmp, /var, /var/log, /var/log/audit, /home.
| Profile Applicability | Level 1 — Server (partitions de base), Level 2 — Server (toutes) |
| Applicabilité PVE | 🏠 (simplifié) 🏢🌐 (complet) |
| Réf. CIS Debian 13 | 1.1.2.1 à 1.1.2.7 |
| CIS Controls v8 | 4.8 — Uninstall or Disable Unnecessary Services |
| MITRE ATT&CK | T1499.001 (OS Exhaustion Flood), M1022 (Restrict File and Directory Permissions) |
| ISO 27001:2022 | A.8.9 — Configuration management |
| PCI DSS v4.0 | 2.2.1, 2.2.4 |
| Scénario threat model | S2 (ransomware), S7 (supply chain) |
| Statut PVE 9 | ✅ Validé (si Debian-first) / ⚠️ Non conforme (si ISO PVE) |
Description :
Description :
Rationale :
Rationale :
Impact :
Nul si fait à l'installation. Irréversible après installation (réinstallation nécessaire pour le partitionnement, options de montage modifiables à chaud).
🔍 Audit
Audit :
Vérifier que les partitions existent
for mp in /tmp /var /var/log /var/log/audit /home /var/tmp; do
findmnt -n "$mp" > /dev/null 2>&1 && echo "PASS: $mp est une partition séparée" \
| echo "FAIL: $mp n'est PAS une partition séparée" |
done
Vérifier les options de montage
for mp in /tmp /dev/shm /var/tmp; do
opts=$(findmnt -n -o OPTIONS "$mp" 2>/dev/null)
echo "$mp: $opts"
echo "$opts" | grep -q "nosuid" && echo " nosuid: PASS" || echo " nosuid: FAIL"
echo "$opts" | grep -q "nodev" && echo " nodev: PASS" || echo " nodev: FAIL"
echo "$opts" | grep -q "noexec" && echo " noexec: PASS" || echo " noexec: FAIL"
done
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Hors périmètre CIS (recommandation complémentaire) |
| CIS Controls v8 | 3.6 — Encrypt Data on End-User Devices, 3.9 — Encrypt Data on Removable Media |
| MITRE ATT&CK | T1005 (Data from Local System), T1025 (Data from Removable Media), M1041 (Encrypt Sensitive Information) |
| ISO 27001:2022 | A.8.24 — Use of cryptography |
| PCI DSS v4.0 | 3.5.1 — Render PAN unreadable anywhere it is stored |
| Scénario threat model | S10 (accès physique) |
| Statut PVE 9 | ⚠️ Partiel — ZFS encryption natif dans l'installateur, LUKS uniquement via Debian-first |
Description :
Description :
Rationale :
Rationale :
Impact :
- Surcoût performance : 3-5% (LUKS2 + AES-NI), 5-8% (ZFS encryption) sur I/O séquentiel
- Nécessite une intervention au boot (saisie de passphrase) ou une configuration auto-unlock (TPM, dropbear, tang/clevis)
- Complexité accrue de la gestion des clés et de la recovery
🔍 Audit
Audit :
Vérifier le chiffrement LUKS
lsblk -f | grep -i crypt
Résultat attendu : volumes de type "crypt" visibles
Vérifier le chiffrement ZFS
zfs get encryption -r rpool 2>/dev/null | grep -v off
Résultat attendu : datasets avec encryption=aes-256-gcm
Vérifier l'état global
cryptsetup status cryptlvm 2>/dev/null || echo "Pas de LUKS actif"
**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 :zfs create -o encryption=aes-256-gcm \
-o keylocation=prompt \
-o keyformat=passphrase \
rpool/encrypted-vms
**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** :Sauvegarder l'en-tête LUKS (si LUKS)
cryptsetup luksHeaderBackup /dev/sdX3 --header-backup-file /root/luks-header-sdX3.img
STOCKER HORS SITE
Générer et stocker une clé de récupération
systemd-cryptenroll /dev/sdX3 --recovery-key 2>/dev/null
ou noter la passphrase dans un gestionnaire de MDP hors ligne
**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 :apt install dropbear-initramfs
echo 'DROPBEAR_OPTIONS="-s -c cryptroot-unlock"' > /etc/dropbear/initramfs/dropbear.conf
Ajouter votre clé publique SSH dans /etc/dropbear/initramfs/authorized_keys
update-initramfs -u
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠 (simplifié) 🏢🌐 (complet) |
| Réf. CIS Debian 13 | Hors périmètre CIS (architecture) |
| CIS Controls v8 | 12.2 — Establish and Maintain a Secure Network Architecture |
| MITRE ATT&CK | T1557 (Adversary-in-the-Middle), T1021 (Remote Services), M1030 (Network Segmentation) |
| ISO 27001:2022 | A.8.22 — Segregation of networks |
| PCI DSS v4.0 | 1.2.1 — Restrict inbound and outbound traffic |
| Scénario threat model | S1, S4, S5, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nul (planification uniquement).
🔧 Remédiation
Remédiation :
Architecture VLAN de référence (🏢🌐) :
| VLAN | Nom | Rôle | Plage exemple | Ports PVE |
|---|---|---|---|---|
| 10 | Management | Web UI :8006, SSH, API | 10.0.10.0/24 | 8006/tcp, 22/tcp |
| 20 | VM/CT | Trafic applicatif guests | 10.0.20.0/24+ | Variable |
| 30 | Stockage | NFS, iSCSI, Ceph public | 10.0.30.0/24 | 2049, 3260, 6789 |
| 40 | Cluster | Corosync, migration, réplication | 10.0.40.0/24 | 5405/udp, 60000-60050/tcp |
| 41 | Ceph cluster | Réplication OSD (si Ceph) | 10.0.41.0/24 | 6800-7300/tcp |
| 99 | OOB | BMC/IPMI | 10.0.99.0/24 | 443/tcp (BMC web) |
Architecture simplifiée (🏠) :
Réseau plat avec firewall PVE pour restreindre l'accès aux ports management. Pas de VLAN nécessaire.
Valeur par défaut : Pas de segmentation. Un seul bridge vmbr0 sur l'interface principale.
Spécificité PVE : Proxmox utilise des bridges Linux (vmbr0, vmbr1...) pour la connectivité réseau. Chaque VLAN peut être associé à un bridge dédié ou utiliser des VLAN-aware bridges. La configuration détaillée est couverte en Phase 4.
0.3 — Checklist pré-installation
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)Navigation : ← 01-threat-model.md | 03-os-debian-durci.md →
-e
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0 (2025-12-16) Scénarios du threat model : S1, S2, S3, S6, S7
1.1 — Gestion des paquets et dépôts
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 1.2.1.1 — Ensure GPG keys are configured |
| CIS Controls v8 | 2.2 — Ensure Authorized Software is Currently Supported |
| MITRE ATT&CK | T1195.002 (Compromise Software Supply Chain), M1051 (Update Software) |
| ISO 27001:2022 | A.8.8 — Management of technical vulnerabilities, A.8.10 — Information deletion |
| PCI DSS v4.0 | 6.3.3 |
| Scénario threat model | S7 (supply chain) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Sans abonnement, les mises à jour via le dépôt no-subscription sont fonctionnelles mais n'ont pas le même niveau de test que le dépôt enterprise.
🔍 Audit
Audit :
Vérifier que apt update fonctionne sans erreur
apt update 2>&1 | grep -E "Err:|401|Failed"
Résultat attendu : aucune sortie (pas d'erreurs)
Vérifier les clés GPG Proxmox
apt-key list 2>/dev/null | grep -A1 "proxmox" || \
ls /etc/apt/trusted.gpg.d/proxmox-*
Résultat attendu : clé Proxmox Release Key présente
Vérifier qu'aucun dépôt n'a AllowUnauthenticated
grep -r "AllowUnauthenticated\|AllowInsecureRepositories" /etc/apt/ 2>/dev/null
Résultat attendu : aucune sortie
**Remédiation** :
Avec abonnement enterprise (🏢🌐 recommandé) :Vérifier /etc/apt/sources.list.d/pve-enterprise.list
cat /etc/apt/sources.list.d/pve-enterprise.list
Doit contenir : deb https://enterprise.proxmox.com/debian/pve trixie pve-enterprise
apt update # Doit fonctionner sans erreur 401
Sans abonnement (🏠) :Désactiver le dépôt enterprise
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
Ajouter le dépôt no-subscription
echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" \
/etc/apt/sources.list.d/pve-no-subscription.list
apt update
**Valeur par défaut** : Dépôt enterprise activé (échoue sans licence). Clés GPG Proxmox installées.
**Rollback** :sed -i 's/^#deb/deb/' /etc/apt/sources.list.d/pve-enterprise.list
rm -f /etc/apt/sources.list.d/pve-no-subscription.list
**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).
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 1.2.2.1 — Ensure updates, patches, and additional security software are installed |
| CIS Controls v8 | 7.3 — Perform Automated Operating System Patch Management |
| MITRE ATT&CK | T1190 (Exploit Public-Facing Application), M1051 (Update Software) |
| ISO 27001:2022 | A.8.8 — Management of technical vulnerabilities |
| PCI DSS v4.0 | 6.3.3 — Install security patches within one month |
| Scénario threat model | S3 (VM escape via CVE QEMU), S7 (supply chain) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Les correctifs de sécurité Debian sont stables. Un reboot peut être nécessaire (kernel) mais Automatic-Reboot est désactivé.
🔍 Audit
Audit :
dpkg -l unattended-upgrades | grep -q "^ii" && echo "PASS: installé" || echo "FAIL: non installé"
systemctl is-enabled unattended-upgrades && echo "PASS: activé" || echo "FAIL: désactivé"
grep -v "^//" /etc/apt/apt.conf.d/50unattended-upgrades | grep -q "Debian-Security" \
&& echo "PASS: sécurité Debian configurée" || echo "FAIL: non configuré"
**Remédiation** :apt install -y unattended-upgrades apt-listchanges
dpkg-reconfigure -plow unattended-upgrades
Contenu de `/etc/apt/apt.conf.d/50unattended-upgrades` :Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
// NE PAS ajouter de ligne pour les dépôts Proxmox
};
Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Contenu de `/etc/apt/apt.conf.d/20auto-upgrades` :APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
**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).
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 2.1.x — Ensure [service] is not installed |
| CIS Controls v8 | 4.8 — Uninstall or Disable Unnecessary Services |
| MITRE ATT&CK | T1543 (Create or Modify System Process), M1042 (Disable or Remove Feature or Program) |
| ISO 27001:2022 | A.8.9 — Configuration management |
| PCI DSS v4.0 | 2.2.4 — Only necessary services are enabled |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible.
🔍 Audit
Audit :
for pkg in telnet rsh-client rsh-server xinetd tftp-server nis \
avahi-daemon cups talk inetutils-talk postfix exim4; do
dpkg -l "$pkg" 2>/dev/null | grep -q "^ii" && echo "FAIL: $pkg installé" \
| echo "PASS: $pkg absent" |
done
**Remédiation** :apt purge -y telnet rsh-client rsh-server xinetd tftp-server nis \
avahi-daemon cups cups-client talk inetutils-talk 2>/dev/null
apt autoremove -y
**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.
---
1.2 — Noyau et paramètres de démarrage
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | 1.4.1 — Ensure bootloader password is set |
| CIS Controls v8 | 4.1 |
| MITRE ATT&CK | T1542.003 (Bootkit), M1046 (Boot Integrity) |
| ISO 27001:2022 | A.8.5 — Secure authentication |
| PCI DSS v4.0 | 2.2.1 |
| Scénario threat model | S10 (accès physique) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Le boot normal ne demande pas le mot de passe (paramètre --unrestricted). Le mot de passe n'est demandé que pour l'édition des entrées GRUB.
🔍 Audit
Audit :
grep -q "^set superusers" /boot/grub/grub.cfg && echo "PASS" || echo "FAIL"
grep -q "^password_pbkdf2" /boot/grub/grub.cfg && echo "PASS" || echo "FAIL"
**Remédiation** :Générer le hash
grub-mkpasswd-pbkdf2
(saisir le mot de passe, noter le hash grub.pbkdf2.sha512.10000.XXXXX)
Configurer dans /etc/grub.d/40_custom :
cat >> /etc/grub.d/40_custom << 'EOF'
set superusers="grubadmin"
password_pbkdf2 grubadmin grub.pbkdf2.sha512.10000.<VOTRE_HASH>
EOF
Permettre le boot normal sans mot de passe
sed -i 's/class gnu-linux/class gnu-linux --unrestricted/' /etc/grub.d/10_linux
update-grub
**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`.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 3.3.1 à 3.3.11 |
| CIS Controls v8 | 4.1, 4.8 |
| MITRE ATT&CK | T1557 (AitM), T1499 (Endpoint DoS), M1037 (Filter Network Traffic) |
| ISO 27001:2022 | A.8.20 — Network security, A.8.22 — Segregation of networks |
| PCI DSS v4.0 | 1.2.1, 1.3.1 |
| Scénario threat model | S1, S4, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Exception critique : net.ipv4.ip_forward est nécessaire pour le réseau des VM. Ne PAS le désactiver si des VM ont un accès réseau.
🔍 Audit
Audit :
Vérifier les paramètres critiques
declare -A expected=(
["net.ipv4.conf.all.rp_filter"]="1"
["net.ipv4.conf.all.accept_redirects"]="0"
["net.ipv4.conf.all.send_redirects"]="0"
["net.ipv4.conf.all.accept_source_route"]="0"
["net.ipv4.conf.all.log_martians"]="1"
["net.ipv4.tcp_syncookies"]="1"
["net.ipv4.icmp_echo_ignore_broadcasts"]="1"
["net.ipv6.conf.all.accept_redirects"]="0"
["net.ipv6.conf.all.accept_source_route"]="0"
)
for key in "${!expected[@]}"; do
val=$(sysctl -n "$key" 2>/dev/null)
[ "$val" = "${expected[$key]}" ] && echo "PASS: $key = $val" \
| echo "FAIL: $key = $val (attendu: ${expected[$key]})" |
done
**Remédiation** :
Créer `/etc/sysctl.d/90-cis-network.conf` :CIS 3.3.1 — Source routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0
CIS 3.3.2 — ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
CIS 3.3.3 — Secure ICMP redirects
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
CIS 3.3.4 — Suspicious packets logged
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
CIS 3.3.5 — Broadcast ICMP requests
net.ipv4.icmp_echo_ignore_broadcasts = 1
CIS 3.3.6 — Bogus ICMP responses
net.ipv4.icmp_ignore_bogus_error_responses = 1
CIS 3.3.7 — Reverse path filtering
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
CIS 3.3.8 — TCP SYN cookies
net.ipv4.tcp_syncookies = 1
CIS 3.3.9 — IPv6 router advertisements
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
CIS 3.3.10 — Do not send ICMP redirects (not a router)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
CIS 3.3.11 — IP forwarding
ATTENTION PVE : NE PAS DÉSACTIVER si les VM ont un accès réseau !
Proxmox gère ce paramètre — il DOIT être à 1 pour le réseau VM
net.ipv4.ip_forward = 0 # UNIQUEMENT si aucun réseau VM routé/NAT
sysctl --system
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | 1.5.1 à 1.5.4 |
| CIS Controls v8 | 4.1 |
| MITRE ATT&CK | T1068 (Exploitation for Privilege Escalation), M1050 (Exploit Protection) |
| ISO 27001:2022 | A.8.9 — Configuration management |
| PCI DSS v4.0 | 2.2.1 |
| Scénario threat model | S3 (VM escape), S6 (insider) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible pour la plupart des workloads. ptrace_scope=2 empêche strace et gdb pour les utilisateurs non-root.
🔍 Audit
Audit :
declare -A expected=(
["kernel.kptr_restrict"]="2"
["kernel.dmesg_restrict"]="1"
["kernel.perf_event_paranoid"]="3"
["kernel.yama.ptrace_scope"]="2"
["kernel.unprivileged_bpf_disabled"]="1"
["kernel.kexec_load_disabled"]="1"
["fs.suid_dumpable"]="0"
)
for key in "${!expected[@]}"; do
val=$(sysctl -n "$key" 2>/dev/null)
[ "$val" = "${expected[$key]}" ] && echo "PASS: $key = $val" \
| echo "FAIL: $key = $val (attendu: ${expected[$key]})" |
done
**Remédiation** :
Créer `/etc/sysctl.d/90-cis-kernel.conf` :Masquer les pointeurs kernel (prévient KASLR bypass)
kernel.kptr_restrict = 2
Restreindre dmesg aux privilégiés
kernel.dmesg_restrict = 1
Restreindre perf_event (profilage)
kernel.perf_event_paranoid = 3
Restreindre ptrace (debugging inter-processus)
kernel.yama.ptrace_scope = 2
Désactiver BPF non privilégié
kernel.unprivileged_bpf_disabled = 1
Durcir BPF JIT
net.core.bpf_jit_harden = 2
Désactiver kexec (chargement kernel à chaud)
kernel.kexec_load_disabled = 1
Restreindre userfaultfd
vm.unprivileged_userfaultfd = 0
Pas de core dumps des processus setuid
fs.suid_dumpable = 0
sysctl --system
**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`
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | 1.1.1.1 à 1.1.1.8 |
| CIS Controls v8 | 4.8 |
| MITRE ATT&CK | T1068 (Exploitation for Privilege Escalation), M1042 (Disable or Remove Feature) |
| ISO 27001:2022 | A.8.9 |
| PCI DSS v4.0 | 2.2.4 |
| Scénario threat model | S3, S10 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Ces modules ne sont pas utilisés sur un hyperviseur standard.
🔍 Audit
Audit :
for mod in cramfs freevxfs hfs hfsplus jffs2 udf dccp sctp rds tipc; do
result=$(modprobe -n -v "$mod" 2>&1)
echo "$result" | grep -q "install /bin/true\|install /bin/false" \
&& echo "PASS: $mod désactivé" || echo "FAIL: $mod chargeable"
done
**Remédiation** :
Créer `/etc/modprobe.d/cis-hardening.conf` :CIS 1.1.1.1 — cramfs
install cramfs /bin/false
blacklist cramfs
CIS 1.1.1.2 — freevxfs
install freevxfs /bin/false
blacklist freevxfs
CIS 1.1.1.3 — hfs
install hfs /bin/false
blacklist hfs
CIS 1.1.1.4 — hfsplus
install hfsplus /bin/false
blacklist hfsplus
CIS 1.1.1.5 — jffs2
install jffs2 /bin/false
blacklist jffs2
CIS 1.1.1.7 — udf
install udf /bin/false
blacklist udf
Protocoles réseau obsolètes
install dccp /bin/false
blacklist dccp
install sctp /bin/false
blacklist sctp
install rds /bin/false
blacklist rds
install tipc /bin/false
blacklist tipc
Bluetooth (inutile sur un serveur)
install bluetooth /bin/false
blacklist bluetooth
Firewire
install firewire-core /bin/false
blacklist firewire-core
update-initramfs -u
**Valeur par défaut** : Modules chargeables à la demande.
**Rollback** : `rm /etc/modprobe.d/cis-hardening.conf && update-initramfs -u`
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Complémentaire (hardening kernel avancé) |
| CIS Controls v8 | 4.1 |
| MITRE ATT&CK | T1068, T1014 (Rootkit), M1050 (Exploit Protection) |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S3 |
| Statut PVE 9 | ✅ Validé (paramètres listés), 🧪 Expérimental (lockdown=integrity) |
Description :
Description :
Rationale :
Rationale :
Impact : Surcoût performance ~1-5% selon le workload (principalement init_on_alloc/free).
🔧 Remédiation
Remédiation :
Dans /etc/default/grub :
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"⚠️ NE PAS AJOUTER lockdown=integrity — ce paramètre empêche le chargement de modules kernel même par root. Il casse ZFS, Ceph, GPU passthrough et d'autres fonctionnalités Proxmox. Voir 12-experimental.md.
update-grubNE PAS redémarrer immédiatement — tester d'abord les autres modifications
**Audit** :cat /proc/cmdline | grep -o "init_on_alloc=1" && echo "PASS" || echo "FAIL"
**Valeur par défaut** : `quiet` uniquement.
---
1.3 — Comptes et authentification locale
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 5.3.1 — Configure PAM software packages, 5.4.1 — Ensure password creation requirements |
| CIS Controls v8 | 5.2 — Use Unique Passwords |
| MITRE ATT&CK | T1110 (Brute Force), M1027 (Password Policies) |
| ISO 27001:2022 | A.5.17 — Authentication information |
| PCI DSS v4.0 | 8.3.6 — Minimum password complexity |
| Scénario threat model | S1, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
grep -E "^minlen|^minclass|^dcredit|^ucredit" /etc/security/pwquality.conf 2>/dev/null
Résultat attendu : minlen = 14, minclass = 3
**Remédiation** :apt install -y libpam-pwquality
Configurer `/etc/security/pwquality.conf` :minlen = 14
minclass = 3
maxrepeat = 3
dictcheck = 1
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
**Valeur par défaut** : Aucune politique de complexité.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 5.3.2 — Ensure lockout for failed password attempts |
| CIS Controls v8 | 5.6 — Centralize Account Management |
| MITRE ATT&CK | T1110 (Brute Force), M1036 (Account Use Policies) |
| ISO 27001:2022 | A.8.5 — Secure authentication |
| PCI DSS v4.0 | 8.3.4 — Lockout after 10 invalid attempts |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
grep -E "^deny|^unlock_time|^fail_interval" /etc/security/faillock.conf 2>/dev/null
**Remédiation** :
Configurer `/etc/security/faillock.conf` :deny = 5
unlock_time = 900
fail_interval = 900
even_deny_root # PRUDENCE : peut bloquer les opérations cluster SSH
**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.
---
| Profile Applicability | Level 1 — Server |
| Réf. CIS Debian 13 | 5.5.5 — Ensure default user shell timeout is configured |
| CIS Controls v8 | 4.3 — Configure Automatic Session Locking |
| MITRE ATT&CK | T1078 (Valid Accounts) |
| ISO 27001:2022 | A.8.5 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
Créer /etc/profile.d/cis-timeout.sh :
readonly TMOUT=900
export TMOUTValeur par défaut : Pas de timeout.
| Profile Applicability | Level 1 — Server |
| Réf. CIS Debian 13 | 1.7.1 à 1.7.6 |
| CIS Controls v8 | N/A |
| MITRE ATT&CK | N/A (contrôle juridique, pas technique) |
| ISO 27001:2022 | A.8.5 |
| PCI DSS v4.0 | 2.2.1 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
cat > /etc/issue.net << 'EOF'
- Acces autorise uniquement. Toute activite est journalisee. *
- Les acces non autorises seront poursuivis conformement a la loi.*
EOF
cp /etc/issue.net /etc/issue
/etc/motd
**Valeur par défaut** : Informations système dans `/etc/issue` (version Debian, hostname).
---
1.4 — Journalisation et audit
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 (🟡 N2 pour 🏠) |
| Réf. CIS Debian 13 | 6.2.1 à 6.2.4 |
| CIS Controls v8 | 8.2 — Collect Audit Logs, 8.5 — Collect Detailed Audit Logs |
| MITRE ATT&CK | T1070 (Indicator Removal), T1078 (Valid Accounts), M1028 (Operating System Configuration) |
| ISO 27001:2022 | A.8.15 — Logging |
| PCI DSS v4.0 | 10.2.1 — Audit logs capture defined events |
| Scénario threat model | S1, S3, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Surcoût CPU ~2-4%, I/O supplémentaire selon le volume de logs. Surveiller la taille de /var/log/audit.
🔍 Audit
Audit :
systemctl is-active auditd && echo "PASS" || echo "FAIL"
auditctl -l | wc -l
Résultat attendu : > 0
**Remédiation** :apt install -y auditd audispd-plugins
systemctl enable --now auditd
Créer `/etc/audit/rules.d/cis-hardening.rules` :Purge des règles existantes
-D
Buffer
-b 8192
Action en cas d'erreur
-f 1
=== CIS 6.2.3.1-4 : Fichiers d'identité ===
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
=== CIS 6.2.3.5 : Réseau ===
-w /etc/hosts -p wa -k network
-w /etc/network/ -p wa -k network
=== CIS 6.2.3.6 : Sysctl ===
-w /etc/sysctl.conf -p wa -k sysctl
-w /etc/sysctl.d/ -p wa -k sysctl
=== CIS 6.2.3.7 : SSH ===
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/ssh/sshd_config.d/ -p wa -k sshd
=== CIS 6.2.3.8 : PAM ===
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/ -p wa -k pam
=== CIS 6.2.3.9 : Heure système ===
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
=== CIS 6.2.3.10 : Cron ===
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
=== CIS 6.2.3.14 : Élévation de privilèges ===
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k privilege_escalation
=== CIS 6.2.3.15 : Montage de filesystems ===
-a always,exit -F arch=b64 -S mount,umount2 -F auid>=1000 -F auid!=4294967295 -k mounts
=== CIS 6.2.3.17 : Suppression de fichiers ===
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -k delete
=== CIS 6.2.3.19 : Modules kernel ===
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-w /sbin/rmmod -p x -k modules
=== SPÉCIFIQUE PROXMOX : Configuration PVE ===
-w /etc/pve/ -p wa -k proxmox-config
=== Verrouillage des règles (reboot requis pour modifier) ===
-e 2
augenrules --load
**Valeur par défaut** : `auditd` non installé.
**Rollback** : `systemctl stop auditd && apt purge auditd`
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 6.1.1 à 6.1.3 |
| CIS Controls v8 | 8.2 |
| MITRE ATT&CK | T1070.002 (Clear Linux Logs) |
| ISO 27001:2022 | A.8.15 |
| PCI DSS v4.0 | 10.2.1 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
Dans /etc/systemd/journald.conf :
[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemKeepFree=1G
ForwardToSyslog=yessystemctl restart systemd-journaldValeur par défaut : Storage=auto (persistant si /var/log/journal existe, sinon volatile).
1.5 — Services et processus
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 2.1.x à 2.3.x |
| CIS Controls v8 | 4.8 |
| MITRE ATT&CK | T1543 (Create or Modify System Process), M1042 |
| ISO 27001:2022 | A.8.9 |
| PCI DSS v4.0 | 2.2.4 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ✅ Validé |
🔍 Audit
Audit :
Lister les ports en écoute
ss -tlnp | grep LISTEN
Résultat attendu : uniquement les ports PVE nécessaires
(22, 8006, 85, et selon le cas : 3128, 5405, 6789, 6800-7300)
**Remédiation** :systemctl disable --now avahi-daemon.service 2>/dev/null
systemctl disable --now cups.service 2>/dev/null
systemctl disable --now rpcbind.service rpcbind.socket 2>/dev/null
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox (hors CIS) |
| CIS Controls v8 | 4.8 |
| MITRE ATT&CK | M1042 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Si SPICE non utilisé (consoles VM) :
systemctl mask --now spiceproxy.service
Note : 'disable' ne suffit pas, pve-manager le réactive
Si Ceph non utilisé :
systemctl mask --now ceph.target
Note : 'disable' ne suffit pas, le service se réactive au reboot
Si ZFS non utilisé :
systemctl disable --now zfs-mount.service zfs-share.service zfs-zed.service
**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`.
---
1.6 — AppArmor
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 1.3.1.1 — Ensure AppArmor is installed, 1.3.1.2 — Ensure AppArmor is enabled |
| CIS Controls v8 | 4.1, 10.5 |
| MITRE ATT&CK | T1068 (Exploitation for Privilege Escalation), M1050 (Exploit Protection) |
| ISO 27001:2022 | A.8.7 — Protection against malware |
| PCI DSS v4.0 | 2.2.1 |
| Scénario threat model | S3 (VM escape) |
| Statut PVE 9 | ✅ Validé |
🔍 Audit
Audit :
aa-status --enabled && echo "PASS" || echo "FAIL"
aa-status 2>/dev/null | head -5
Résultat attendu : "apparmor module is loaded", X profiles, Y enforce
**Remédiation** :apt install -y apparmor apparmor-utils
Vérifier la ligne de commande kernel
grep -qE "apparmor=1|security=apparmor" /proc/cmdline || {
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="apparmor=1 security=apparmor /' /etc/default/grub
update-grub
echo "Reboot nécessaire pour activer AppArmor"
}
**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é.
---
1.7 — Checklist post-Phase 1
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 attendusNavigation : ← 02-pre-installation.md | 04-proxmox-specifique.md →
-e
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, Documentation Proxmox VE 9 Scénarios du threat model : S1, S3, S4, S6, S9
2.1 — Interface web (pveproxy)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox (hors CIS) |
| CIS Controls v8 | 3.10 — Encrypt Sensitive Data in Transit |
| MITRE ATT&CK | T1557 (Adversary-in-the-Middle), T1040 (Network Sniffing), M1041 (Encrypt Sensitive Information) |
| ISO 27001:2022 | A.8.24 — Use of cryptography |
| PCI DSS v4.0 | 4.2.1 — Strong cryptography for transmission |
| Scénario threat model | S1, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Faible. Les navigateurs modernes supportent tous TLS 1.2+ avec AES-GCM et ChaCha20. Seuls les clients très anciens (IE < 11, Android < 5) seraient affectés.
🔍 Audit
Audit :
Vérifier la configuration existante
cat /etc/default/pveproxy 2>/dev/null
Résultat attendu : fichier présent avec CIPHERS et HONOR_CIPHER_ORDER
Tester les ciphers acceptés (depuis un autre hôte)
nmap --script ssl-enum-ciphers -p 8006 <PVE_IP>
Résultat attendu : uniquement TLS 1.2 et 1.3, pas de ciphers CBC
Alternative avec openssl
openssl s_client -connect <PVE_IP>:8006 -tls1_1 2>&1 | grep -i "handshake"
Résultat attendu : handshake failure (TLS 1.1 refusé)
**Remédiation** :
Créer ou modifier `/etc/default/pveproxy` :Ciphers TLS 1.2 — uniquement AEAD (GCM, ChaCha20), pas de CBC
CIPHERS="ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"
Ciphers TLS 1.3 (défauts OpenSSL, déjà sécurisés)
CIPHERSUITES="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
Le serveur choisit le cipher (pas le client)
HONOR_CIPHER_ORDER=1
Désactiver TLS < 1.2 explicitement
(normalement déjà désactivé via OpenSSL sur Debian 13, mais par sécurité)
Note : pveproxy désactive SSL 2/3 inconditionnellement
systemctl restart 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.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, M1041 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite un FQDN résolvable et un accès réseau pour la validation ACME (HTTP-01 ou DNS-01).
🔍 Audit
Audit :
Vérifier le certificat actuel
openssl x509 -in /etc/pve/local/pve-ssl.pem -text -noout | grep -E "Issuer:|Not After"
Résultat attendu : Issuer != "Proxmox Virtual Environment" (pas auto-signé)
Not After : date dans le futur
Vérifier la configuration ACME
pvenode acme account list 2>/dev/null
**Remédiation** :1. Enregistrer un compte ACME
pvenode acme account register default <email@example.com> --directory https://acme-v02.api.letsencrypt.org/directory
2. Configurer le challenge (HTTP-01 ou DNS-01)
HTTP-01 (le port 80 doit être accessible depuis internet) :
pvenode config set --acme domains=<fqdn>
pvenode acme cert order
DNS-01 (recommandé si le serveur n'est pas directement accessible) :
Configurer le plugin DNS dans Datacenter > ACME
**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`).
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.2 — Establish and Maintain a Firewall Rule Set, 13.1 — Centralize Security Event Alerting |
| MITRE ATT&CK | T1190 (Exploit Public-Facing Application), M1030 (Network Segmentation), M1035 (Limit Access to Resource) |
| ISO 27001:2022 | A.8.20 — Network security |
| PCI DSS v4.0 | 1.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible, mais risque de lock-out si l'IP d'administration change. Toujours conserver un accès console hors-bande.
🔍 Audit
Audit :
Vérifier la configuration ACL pveproxy
grep -E "ALLOW_FROM|DENY_FROM|POLICY" /etc/default/pveproxy 2>/dev/null
Résultat attendu : ALLOW_FROM configuré, DENY_FROM="all", POLICY="deny"
Vérifier les règles firewall PVE pour le port 8006
pvesh get /cluster/firewall/rules 2>/dev/null | grep 8006
**Remédiation** :
**Méthode 1 — ACL pveproxy** (simple, appliquée au niveau applicatif) :
Dans `/etc/default/pveproxy` :Autoriser uniquement les réseaux d'administration
ALLOW_FROM="10.0.10.0/24,192.168.1.0/24"
DENY_FROM="all"
POLICY="deny"
systemctl restart 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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.8 |
| MITRE ATT&CK | T1021.005 (VNC), M1042 (Disable or Remove Feature) |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ⚠️ Partiel — spiceproxy masquable, noVNC intégré à pveproxy |
Description :
Description :
Rationale :
Rationale :
Impact : Moyen. Plus de console graphique pour les VM depuis l'interface web PVE. L'accès SSH aux VM reste fonctionnel.
🔧 Remédiation
Remédiation :
Désactiver SPICE proxy (port 3128)
systemctl mask --now spiceproxy.service
Note : utiliser 'mask' car pve-manager le réactive avec 'disable'
noVNC est intégré dans pveproxy et ne peut pas être désactivé séparément
→ Restreindre l'accès à pveproxy (2.1.3) est la meilleure mitigation
**Valeur par défaut** : spiceproxy actif et en écoute sur le port 3128.
**Rollback** : `systemctl unmask spiceproxy.service && systemctl start spiceproxy`
---
2.2 — API Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 5.2 — Use Unique Passwords, 5.4 — Restrict Administrator Privileges |
| MITRE ATT&CK | T1078 (Valid Accounts), T1552 (Unsecured Credentials), M1026 (Privileged Account Management) |
| ISO 27001:2022 | A.5.17, A.8.5 |
| PCI DSS v4.0 | 8.3.1, 8.6.1 |
| Scénario threat model | S1, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite de reconfigurer les outils d'automatisation existants.
🔍 Audit
Audit :
Lister les tokens API existants
pveum user token list <user>@<realm>
Résultat attendu : tokens dédiés par outil/service
Vérifier qu'aucun script n'utilise de mot de passe en dur
grep -rn "password\|PVE_PASSWORD" /root/ /home/ /opt/ /etc/cron* 2>/dev/null
Résultat attendu : aucune correspondance
**Remédiation** :Créer un token API pour Ansible (exemple)
pveum user token add ansible@pve ansible-token --privsep 1
privsep=1 : le token a ses propres privilèges (séparés de l'utilisateur)
privsep=0 : le token hérite des privilèges de l'utilisateur
Attribuer uniquement les privilèges nécessaires
pveum acl modify / --token 'ansible@pve!ansible-token' --role PVEVMAdmin
Le token sera affiché une seule fois — le stocker de manière sécurisée
**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`).
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.2, 13.1 |
| MITRE ATT&CK | T1190, M1030 |
| ISO 27001:2022 | A.8.20 |
| PCI DSS v4.0 | 1.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Remédiation : Voir 2.1.3 (même mécanisme ALLOW_FROM/DENY_FROM).
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 8.2, 8.5 |
| MITRE ATT&CK | T1070 (Indicator Removal), M1028 (OS Configuration) |
| ISO 27001:2022 | A.8.15 |
| PCI DSS v4.0 | 10.2.1 |
| Scénario threat model | S6 (insider) |
| Statut PVE 9 | ✅ Validé (logs pveproxy natifs) |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Vérifier que les logs API existent et sont alimentés
ls -la /var/log/pveproxy/access.log
tail -5 /var/log/pveproxy/access.log
Résultat attendu : fichier existant avec des entrées récentes
Vérifier la rotation des logs
cat /etc/logrotate.d/pveproxy 2>/dev/null
**Remédiation** :
Les logs API sont actifs par défaut. S'assurer de leur centralisation :Configurer rsyslog pour forwarder les logs pveproxy
(voir Phase 7 — 7.2.3 pour la centralisation complète)
**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).
---
2.3 — Cluster Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢 (clusters uniquement) |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.10, 12.6 |
| MITRE ATT&CK | T1557 (AitM), T1040 (Network Sniffing), M1041 (Encrypt Sensitive Information) |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S4 (mouvement latéral cluster) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Surcoût CPU négligeable avec AES-NI.
🔍 Audit
Audit :
Vérifier la configuration Corosync
grep -E "crypto_cipher|crypto_hash" /etc/corosync/corosync.conf
Résultat attendu :
crypto_cipher: aes256
crypto_hash: sha256
**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` :totem {
...existant...
crypto_cipher: aes256
crypto_hash: sha256
}
Appliquer sur TOUS les nœuds simultanément (fenêtre de maintenance)
systemctl restart corosync
**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.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.3, 4.1 |
| MITRE ATT&CK | T1552.004 (Private Keys), T1213 (Data from Information Repositories) |
| ISO 27001:2022 | A.8.3, A.8.12 |
| PCI DSS v4.0 | 3.5.1, 7.2.1 |
| Scénario threat model | S4, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Vérifier les permissions
ls -la /etc/pve/
Résultat attendu : propriétaire root:www-data, permissions restrictives
Vérifier qu'une sauvegarde récente existe
ls -la /var/lib/pve-cluster/backup/ 2>/dev/null
ou vérifier les sauvegardes PBS
Vérifier les changements récents (si etckeeper/git configuré)
cd /etc/pve && git log --oneline -5 2>/dev/null
**Remédiation** :1. Sauvegarder régulièrement /etc/pve
Via vzdump (inclus dans les backups PVE) ou manuellement :
tar czf /root/pve-config-backup-$(date +%Y%m%d).tar.gz /etc/pve/
2. Optionnel : suivre les changements avec etckeeper
apt install -y etckeeper
cd /etc/pve
git init
git add -A
git commit -m "Initial PVE config snapshot"
3. Programmer une sauvegarde automatique
cat > /etc/cron.daily/backup-pve-config << 'EOF'
#!/bin/bash
tar czf /var/backups/pve-config-$(date +%Y%m%d).tar.gz /etc/pve/ 2>/dev/null
find /var/backups/ -name "pve-config-*.tar.gz" -mtime +30 -delete
EOF
chmod +x /etc/cron.daily/backup-pve-config
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, T1040 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S9 (interception trafic) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Moyen. Le chiffrement de la migration augmente la durée de migration et la charge CPU. L'impact dépend de la taille de la mémoire VM et de la bande passante réseau.
🔍 Audit
Audit :
Vérifier la configuration de migration
grep -E "migration:|migration_type" /etc/pve/datacenter.cfg 2>/dev/null
Résultat attendu : migration: secure
ou migration_network configuré sur un réseau dédié
**Remédiation** :
Via l'interface web : Datacenter > Options > Migration Settings
Via la CLI, modifier `/etc/pve/datacenter.cfg` :Forcer le chiffrement des migrations
migration: secure
Utiliser un réseau dédié pour les migrations (VLAN cluster)
migration_network: 10.0.40.0/24
**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.4 — Gestion des mises à jour Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 1.2.2.1 (complémentaire) |
| CIS Controls v8 | 7.1, 7.3, 7.4 |
| MITRE ATT&CK | T1190, T1068, M1051 (Update Software) |
| ISO 27001:2022 | A.8.8 |
| PCI DSS v4.0 | 6.3.3 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : La procédure elle-même n'a pas d'impact. L'application des mises à jour nécessite une fenêtre de maintenance avec reboot potentiel.
🔧 Remédiation
Remédiation :
Procédure de mise à jour recommandée :
- Veille : s'abonner aux listes de diffusion Proxmox et surveiller les advisories
Vérifier les mises à jour disponibles
apt update
apt list --upgradable 2>/dev/null | grep pve
2. **Test en lab** : appliquer les mises à jour sur un nœud de test ou un PVE nestedapt dist-upgrade # Sur le nœud de test
Vérifier : boot, Web UI, création VM, migration, stockage
3. **Rolling update en production** (un nœud à la fois) :Sur chaque nœud, un par un :
a) Migrer les VM critiques vers un autre nœud
b) Appliquer les mises à jour
apt dist-upgrade
c) Redémarrer si nécessaire (nouveau kernel)
reboot
d) Vérifier :
pveversion -v # Version PVE
uname -r # Kernel
systemctl status pveproxy pvedaemon corosync
pvecm status # Statut cluster
e) Passer au nœud suivant
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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 2.2 |
| MITRE ATT&CK | T1068, M1051 |
| ISO 27001:2022 | A.8.8 |
| Scénario threat model | S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Lister les kernels installés
dpkg -l | grep pve-kernel | grep "^ii"
Résultat attendu : au moins 2 versions
Vérifier le kernel actif
uname -r
**Remédiation** :Conserver les anciens kernels (ne pas purger automatiquement)
Proxmox garde par défaut les anciens kernels
Pour épingler une version kernel (stabilité) :
apt-mark hold pve-kernel-<version>
Exemple :
apt-mark hold pve-kernel-6.12.6-1-pve
Pour désépingler :
apt-mark unhold pve-kernel-<version>
**Valeur par défaut** : Proxmox conserve les anciens kernels installés. Pas d'épinglage.
---
2.5 — Configuration PVE sécurisée
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.1, 8.2 |
| MITRE ATT&CK | T1070 (Indicator Removal), M1028 |
| ISO 27001:2022 | A.8.9, A.8.15 |
| PCI DSS v4.0 | 10.2.1 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
dpkg -l etckeeper | grep -q "^ii" && echo "PASS" || echo "FAIL"
cd /etc && git log --oneline -3 2>/dev/null && echo "PASS: historique git" || echo "FAIL: pas d'historique"
**Remédiation** :apt install -y etckeeper
etckeeper s'initialise automatiquement et commite après chaque apt install/upgrade
Pour le filesystem cluster /etc/pve (voir 2.3.2)
**Valeur par défaut** : etckeeper non installé.
---
2.6 — Checklist post-Phase 2
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 secureNavigation : ← 03-os-debian-durci.md | 05-acces-authentification.md →
-e
05 — Phase 3 : Accès et authentification
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, Documentation Proxmox VE 9 Scénarios du threat model : S1, S4, S6
3.1 — Durcissement SSH
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 5.1.1 à 5.1.22 |
| CIS Controls v8 | 4.1, 5.2, 5.4 |
| MITRE ATT&CK | T1021.004 (SSH), T1110 (Brute Force), T1078 (Valid Accounts), M1032 (Multi-factor Authentication), M1035 (Limit Access) |
| ISO 27001:2022 | A.5.17, A.8.5, A.8.20 |
| PCI DSS v4.0 | 2.2.1, 8.2.1, 8.3.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Moyen. Nécessite de configurer les clés SSH avant de désactiver l'authentification par mot de passe. Risque de lock-out si mal exécuté.
⚠️ SPÉCIFICITÉ PVE CRITIQUE — PermitRootLogin :
Proxmox utilise SSH root entre les nœuds du cluster pour les migrations live, la réplication, et les opérations cluster. Désactiver complètement le login root SSH casse le cluster.
La configuration recommandée est :
Désactiver le login root par mot de passe MAIS autoriser les clés
PermitRootLogin prohibit-password
Pour les clusters : autoriser root uniquement depuis le réseau cluster
Match Address 10.0.40.0/24
PermitRootLogin prohibit-password
**Audit** :Vérifier les paramètres critiques
sshd -T 2>/dev/null | grep -Ei "permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding|protocol"
Résultat attendu :
permitrootlogin prohibit-password
passwordauthentication no
pubkeyauthentication yes
maxauthtries 3
x11forwarding no
**Remédiation** :
**Étape 1 — Préparer les clés SSH AVANT de modifier sshd** :Sur votre poste d'administration :
ssh-keygen -t ed25519 -C "admin@pve"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<PVE_IP>
Tester que la connexion par clé fonctionne
ssh -i ~/.ssh/id_ed25519 root@<PVE_IP>
!! NE PAS fermer cette session !!
**Étape 2 — Modifier la configuration sshd** :
Créer `/etc/ssh/sshd_config.d/hardening.conf` :=== Authentification ===
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30
=== Protocole ===
(SSH protocol 1 est obsolète depuis longtemps — CIS 5.1.1)
Protocol 2 est le seul supporté sur OpenSSH récent
=== Fonctionnalités inutiles ===
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitUserEnvironment no
DisableForwarding yes
=== Bannière ===
Banner /etc/issue.net
=== Timeouts ===
ClientAliveInterval 300
ClientAliveCountMax 2
=== Logging ===
LogLevel VERBOSE
**Étape 3 — Tester et appliquer** :Valider la syntaxe
sshd -t
Résultat attendu : aucune erreur
Redémarrer sshd
systemctl restart sshd
TESTER IMMÉDIATEMENT depuis un NOUVEAU terminal
ssh -i ~/.ssh/id_ed25519 root@<PVE_IP>
Si ça fonctionne → OK
Si ça échoue → utiliser la session existante pour corriger
**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
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 5.1.6 à 5.1.10 |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, M1041 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S1, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Les clients SSH modernes supportent tous les algorithmes recommandés. Les clients très anciens (PuTTY < 0.75, OpenSSH < 7.6) pourraient être impactés.
🔍 Audit
Audit :
Installer et exécuter ssh-audit
apt install -y ssh-audit 2>/dev/null || pip install ssh-audit --break-system-packages
ssh-audit localhost
Résultat attendu : pas de lignes en rouge (fail) ou orange (warn)
**Remédiation** :
Ajouter dans `/etc/ssh/sshd_config.d/hardening.conf` :=== Algorithmes (ssh-audit Debian 13 server guide) ===
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
**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 :=== Peers cluster — utiliser les clés RSA ===
Host pve-node 10.0.40.
HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms rsa-sha2-512,rsa-sha2-256
=== Accès externe — Ed25519 préféré ===
Host *
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
systemctl restart sshd
**Valeur par défaut** : Algorithmes par défaut d'OpenSSL/OpenSSH incluant des options legacy.
---
3.2 — Authentification multi-facteurs (2FA)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 6.3 — Require MFA for Externally-Exposed Applications, 6.4 — Require MFA for Remote Network Access, 6.5 — Require MFA for Administrative Access |
| MITRE ATT&CK | T1078 (Valid Accounts), T1110 (Brute Force), M1032 (Multi-factor Authentication) |
| ISO 27001:2022 | A.8.5 — Secure authentication |
| PCI DSS v4.0 | 8.4.1, 8.4.2, 8.4.3 |
| Scénario threat model | S1, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite une app TOTP (FreeOTP, Google Authenticator, Aegis, etc.) et une procédure de récupération documentée.
⚠️ CORRECTION vs guide HomeSecExplorer : La syntaxe pveum realm modify <<pam>> --tfa type=<<oath>> est incorrecte et échoue. La bonne procédure est via l'interface web ou /etc/pve/domains.cfg.
🔍 Audit
Audit :
Vérifier si le 2FA est configuré pour les utilisateurs
cat /etc/pve/priv/tfa.cfg 2>/dev/null | head -5
Résultat attendu : entrées TFA pour les utilisateurs
Vérifier si un realm impose le 2FA
grep -i "tfa" /etc/pve/domains.cfg 2>/dev/null
**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** :Via SSH (toujours accessible avec les clés) :
Option 1 : utiliser une Recovery Key
Option 2 : supprimer le TFA de l'utilisateur
Éditer /etc/pve/priv/tfa.cfg et supprimer la ligne de l'utilisateur concerné
Ou supprimer tout le TFA :
rm /etc/pve/priv/tfa.cfg
⚠️ Ceci supprime le 2FA de TOUS les utilisateurs
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 6.3, 6.4, 6.5 |
| MITRE ATT&CK | T1078, T1110, T1566 (Phishing), M1032 |
| ISO 27001:2022 | A.8.5 |
| PCI DSS v4.0 | 8.4.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nécessite un certificat TLS valide (pas auto-signé) et la configuration WebAuthn dans PVE.
Prérequis :
- Certificat TLS valide sur le nœud PVE (voir Phase 2, 2.1.2)
- Hardware key (YubiKey, SoloKeys) ou platform authenticator (Touch ID, Windows Hello, Android)
🔧 Remédiation
Remédiation :
- Origin :
https://<votre-fqdn>:8006 - Relying Party :
<votre-fqdn> - ID :
<votre-domaine>
- Datacenter > Permissions > Two Factor > Add > WebAuthn
- Enregistrer votre clé ou authenticator
Valeur par défaut : WebAuthn non configuré.
Spécificité PVE : En cluster, le WebAuthn Relying Party doit correspondre au domaine par lequel vous accédez au cluster. Si vous accédez via des noms différents par nœud, WebAuthn ne fonctionnera que pour le domaine configuré. Un load balancer ou DNS round-robin avec un FQDN unique est recommandé.
3.3 — RBAC Proxmox (contrôle d'accès basé sur les rôles)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 5.4 — Restrict Administrator Privileges, 6.1 — Establish an Access Granting Process, 6.8 — Define and Maintain Role-Based Access Control |
| MITRE ATT&CK | T1078 (Valid Accounts), M1026 (Privileged Account Management), M1018 (User Account Management) |
| ISO 27001:2022 | A.5.15, A.5.18, A.8.2 |
| PCI DSS v4.0 | 7.2.1, 7.2.2 |
| Scénario threat model | S6 (insider) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite la création de comptes et l'attribution de rôles.
🔍 Audit
Audit :
Lister les utilisateurs
pveum user list
Résultat attendu : des comptes nominatifs en plus de root@pam
Vérifier les ACL
pveum acl list
Résultat attendu : ACL par utilisateur/groupe, pas de '/' attribué à tout le monde
Vérifier les connexions récentes avec root@pam
journalctl -u pvedaemon --since "7 days ago" | grep "root@pam" | grep "successful" | tail -5
Résultat attendu : minimal (root@pam ne devrait pas être utilisé quotidiennement)
**Remédiation** :1. Créer un groupe d'administrateurs
pveum group add admins --comment "Administrateurs PVE"
2. Créer des comptes nominatifs
pveum user add alice@pve --firstname Alice --lastname Dupont --email alice@example.com --groups admins
pveum passwd alice@pve
3. Attribuer le rôle Administrator au groupe sur /
pveum acl modify / --group admins --role Administrator
4. Imposer le 2FA pour ces comptes (voir 3.2.1)
5. Documenter la procédure d'utilisation de root@pam :
→ uniquement pour les opérations de maintenance système
→ uniquement via SSH avec clé
→ jamais via l'interface web en usage quotidien
**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>`.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 6.8 |
| MITRE ATT&CK | M1026 |
| ISO 27001:2022 | A.5.15, A.5.18 |
| PCI DSS v4.0 | 7.2.2 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Rôle "opérateur VM" (start/stop/console, pas de create/delete)
pveum role add VMOperator --privs "VM.Console VM.PowerMgmt VM.Monitor VM.Audit"
Rôle "admin backup" (backup/restore uniquement)
pveum role add BackupAdmin --privs "Datastore.AllocateSpace Datastore.Audit VM.Backup"
Rôle "lecteur réseau" (audit réseau uniquement)
pveum role add NetAuditor --privs "SDN.Audit Sys.Audit"
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢 |
| CIS Controls v8 | 5.6, 6.1, 6.7 |
| MITRE ATT&CK | T1078.002 (Domain Accounts), M1026 |
| ISO 27001:2022 | A.5.16, A.5.17 |
| PCI DSS v4.0 | 7.2.1, 8.2.1 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Impact : Moyen. Dépendance à l'infrastructure LDAP/AD.
🔧 Remédiation
Remédiation :
Ajouter un realm LDAP
pveum realm add myldap --type ldap \
--base-dn "ou=People,dc=example,dc=com" \
--bind-dn "cn=pve-readonly,dc=example,dc=com" \
--server1 ldap.example.com \
--port 636 \
--secure 1 \
--user-attr uid
⚠️ TOUJOURS utiliser LDAPS (port 636) ou StartTLS
Ne JAMAIS utiliser LDAP en clair (port 389) → credentials transitent en clair
Synchroniser les groupes
pveum realm sync myldap
**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).
---
3.4 — Protection brute-force
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Complémentaire |
| CIS Controls v8 | 4.1, 13.1 |
| MITRE ATT&CK | T1110 (Brute Force), M1036 (Account Use Policies) |
| ISO 27001:2022 | A.8.5, A.8.16 |
| PCI DSS v4.0 | 8.3.4 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
apt install -y fail2ban
La jail SSH est préconfigurée, il suffit de l'activer
cat > /etc/fail2ban/jail.d/sshd.conf << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 2d
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 30d
EOF
systemctl enable --now fail2ban
**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.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.1, 13.1 |
| MITRE ATT&CK | T1110, T1190, M1036 |
| ISO 27001:2022 | A.8.5, A.8.16 |
| PCI DSS v4.0 | 8.3.4 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
⚠️ CORRECTION CRITIQUE : Sur PVE 9, syslog n'est plus installé par défaut. La configuration Fail2Ban doit utiliser le backend systemd (journal), PAS /var/log/daemon.log ou /var/log/syslog. Les guides qui pointent vers ces fichiers ne fonctionnent PAS sur PVE 9.
Impact : Faible. Risque de faux positif si findtime est trop court.
🔍 Audit
Audit :
Vérifier que le jail proxmox est actif
fail2ban-client status proxmox 2>/dev/null
Résultat attendu : jail active avec nombre de bans
Tester le regex contre le journal
fail2ban-regex systemd-journal /etc/fail2ban/filter.d/proxmox.conf
Résultat attendu : "Failregex: X total" (X > 0 si des échecs existent)
**Remédiation** :
**Filtre** — Créer `/etc/fail2ban/filter.d/proxmox.conf` :[INCLUDES]
before = common.conf
[Definition]
failregex = pvedaemon\[.authentication failure; rhost=<HOST> user=. msg=.*
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
ignoreregex =
**Jail** — Créer `/etc/fail2ban/jail.d/proxmox.conf` :[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 30d
systemctl restart fail2ban
Vérifier
fail2ban-client status proxmox
**Validation** :Provoquer un échec d'authentification volontaire via l'interface web
(mauvais mot de passe), puis vérifier :
fail2ban-regex systemd-journal /etc/fail2ban/filter.d/proxmox.conf
Résultat attendu : au moins 1 match
**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).
---
3.5 — Accès VPN
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🌐 |
| Réf. CIS Debian 13 | Spécifique infrastructure |
| CIS Controls v8 | 12.7 — Ensure Remote Devices Use a VPN |
| MITRE ATT&CK | T1133 (External Remote Services), M1030 (Network Segmentation), M1037 (Filter Network Traffic) |
| ISO 27001:2022 | A.8.20, A.8.22 |
| PCI DSS v4.0 | 1.2.1, 2.2.7, 4.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Moyen. Nécessite une configuration VPN sur chaque poste d'administration. Si le VPN est inaccessible, l'administration du serveur l'est aussi (prévoir un accès console OOB de secours).
🔧 Remédiation
Remédiation :
apt install -y wireguard
Générer les clés serveur
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
chmod 600 /etc/wireguard/server.key
Créer `/etc/wireguard/wg0.conf` :[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = <contenu de /etc/wireguard/server.key>
Post-up : autoriser le trafic VPN vers les ports management
PostUp = iptables -A INPUT -i wg0 -j ACCEPT
PostDown = iptables -D INPUT -i wg0 -j ACCEPT
[Peer]
Poste admin 1
PublicKey = <clé publique du client>
AllowedIPs = 10.10.10.2/32
systemctl enable --now wg-quick@wg0
Vérifier
wg show
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.
---
3.6 — Checklist post-Phase 3
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éeNavigation : ← 04-proxmox-specifique.md | 06-reseau-segmentation.md →
-e
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, Documentation Proxmox VE Firewall Scénarios du threat model : S1, S4, S8, S9
4.1 — Architecture réseau
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 (🏠 simplifié) |
| Réf. CIS Debian 13 | Spécifique infrastructure |
| CIS Controls v8 | 12.2 — Establish and Maintain a Secure Network Architecture |
| MITRE ATT&CK | T1557 (Adversary-in-the-Middle), T1021 (Remote Services), T1040 (Network Sniffing), M1030 (Network Segmentation) |
| ISO 27001:2022 | A.8.22 — Segregation of networks |
| PCI DSS v4.0 | 1.2.1 — Restrict inbound/outbound traffic, 1.3.1 — Restrict inbound to CDE |
| Scénario threat model | S4 (cluster), S5 (BMC), S9 (interception) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nécessite un switch manageable supportant les VLAN 802.1Q. Configuration à faire idéalement avant la mise en production.
🔍 Audit
Audit :
Vérifier les bridges et VLAN configurés
cat /etc/network/interfaces
Résultat attendu : bridges séparés par rôle ou VLAN tagging
Vérifier les interfaces actives
ip -br link show
ip -br addr show
Vérifier la table de routage
ip route show
**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) :auto lo
iface lo inet loopback
Interface physique 1 (trunk VLAN)
auto eno1
iface eno1 inet manual
VLAN 10 — Management
auto eno1.10
iface eno1.10 inet static
auto vmbr0
iface vmbr0 inet static
address 10.0.10.11/24
gateway 10.0.10.1
bridge-ports eno1.10
bridge-stp off
bridge-fd 0
VLAN 20 — VM
auto eno1.20
iface eno1.20 inet manual
auto vmbr1
iface vmbr1 inet manual
bridge-ports eno1.20
bridge-stp off
bridge-fd 0
VLAN 40 — Cluster (interface physique 2 si disponible)
auto eno2
iface eno2 inet manual
auto vmbr3
iface vmbr3 inet static
address 10.0.40.11/24
bridge-ports eno2
bridge-stp off
bridge-fd 0
**Alternative — VLAN-aware bridge** (plus flexible, recommandé PVE 9) :auto vmbr0
iface vmbr0 inet static
address 10.0.10.11/24
gateway 10.0.10.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40
Avec un VLAN-aware bridge, les VM se voient attribuer un VLAN tag dans leur configuration réseau (ex: `tag=20`).
Architecture simplifiée (🏠) :Un seul bridge, pas de VLAN
auto vmbr0
iface vmbr0 inet static
address 192.168.1.100/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 12.2 |
| MITRE ATT&CK | M1030 |
| ISO 27001:2022 | A.8.22 |
| Scénario threat model | S4, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Vérifier qu'aucune VM n'est connectée au bridge management
grep -r "bridge=vmbr0" /etc/pve/qemu-server/ /etc/pve/lxc/ 2>/dev/null
Résultat attendu (si vmbr0 = management) : aucune VM connectée à vmbr0
Les VM doivent être sur vmbr1 ou un bridge VM dédié
**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).
---
4.2 — Firewall Proxmox VE
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 4.1.x à 4.3.x (firewall) |
| CIS Controls v8 | 4.2 — Establish and Maintain a Firewall Rule Set, 4.4 — Implement and Manage a Host-Based Firewall, 4.5 — Implement Application Layer Filtering |
| MITRE ATT&CK | T1190 (Exploit Public-Facing Application), T1021 (Remote Services), M1037 (Filter Network Traffic) |
| ISO 27001:2022 | A.8.20 — Network security, A.8.21 — Security of network services |
| PCI DSS v4.0 | 1.2.1, 1.3.1, 1.3.2, 1.4.1 |
| Scénario threat model | S1, S4 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Élevé si mal exécuté. Risque de lock-out. Toujours conserver un accès console OOB. Le firewall PVE dispose de règles anti-lockout cachées qui autorisent automatiquement certains trafics depuis les « management hosts ».
⚠️ CORRECTION vs guide HomeSecExplorer : Le guide HSE affirme que la politique INPUT est DROP par défaut quand le firewall est activé. C'est partiellement vrai : la politique est bien DROP, mais les règles anti-lockout automatiques autorisent SSH (22), Web UI (8006), VNC (5900-5999), SPICE (3128) et Corosync (5405-5412) depuis le réseau local management. Ces règles sont invisibles dans l'interface mais présentes dans les iptables.
Comportement du firewall PVE à l'activation :
| Trafic | Politique par défaut | Règles anti-lockout |
|---|---|---|
| INPUT depuis management LAN → SSH (22) | DROP | ✅ Autorisé (anti-lockout) |
| INPUT depuis management LAN → Web UI (8006) | DROP | ✅ Autorisé (anti-lockout) |
| INPUT depuis management LAN → VNC (5900-5999) | DROP | ✅ Autorisé (anti-lockout) |
| INPUT cluster → Corosync (5405-5412) | DROP | ✅ Autorisé (anti-lockout) |
| INPUT depuis AUTRE réseau → n'importe quoi | DROP | ❌ Bloqué |
| OUTPUT → tout | ACCEPT | — |
| FORWARD (VM) | — | Géré par les firewall VM individuels |
Point critique : les règles DC et les règles VM sont indépendantes. Les règles Datacenter s'appliquent aux nœuds. Les règles VM s'appliquent uniquement aux VM. Il n'y a PAS de cascading automatique.
🔍 Audit
Audit :
Vérifier si le firewall est actif
cat /etc/pve/firewall/cluster.fw 2>/dev/null | grep "enable"
Résultat attendu : enable: 1
Vérifier la politique
cat /etc/pve/firewall/cluster.fw 2>/dev/null | grep "policy"
Résultat attendu : policy_in: DROP
Vérifier les règles iptables actives
iptables -L -n -v | head -30
Résultat attendu : chaînes PVEFW-* présentes
Vérifier le statut du service
systemctl is-active pve-firewall
**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` :[OPTIONS]
enable: 0
policy_in: DROP
policy_out: ACCEPT
[RULES]
Management — Web UI (restreint au réseau admin)
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 8006 -log nolog
Management — SSH (restreint au réseau admin)
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22 -log nolog
Cluster — Corosync
IN ACCEPT -source 10.0.40.0/24 -p udp -dport 5405:5412 -log nolog
Cluster — Migration live
IN ACCEPT -source 10.0.40.0/24 -p tcp -dport 60000:60050 -log nolog
Monitoring — ICMP ping (optionnel)
IN ACCEPT -p icmp -log nolog
**Étape 2** — Vérifier l'accès OOB (IPMI/iDRAC/console) — en cas de lock-out.
**Étape 3** — Activer le firewall :Via la CLI :
pvesh set /cluster/firewall/options --enable 1
Ou éditer cluster.fw et passer enable: 1
**Étape 4** — Tester IMMÉDIATEMENT :Depuis votre poste admin, dans un NOUVEAU terminal :
ssh root@<PVE_IP>
Tester l'accès web UI : https://<PVE_IP>:8006
En cluster : tester pvecm status
**Étape 5** — Activer le firewall par nœud :
Créer `/etc/pve/nodes/<hostname>/host.fw` :[OPTIONS]
enable: 1
**Valeur par défaut** : Firewall **désactivé**. Aucune règle.
**Rollback** :Désactiver le firewall immédiatement
pvesh set /cluster/firewall/options --enable 0
Ou éditer /etc/pve/firewall/cluster.fw : enable: 0
Ou via console OOB : pve-firewall stop
**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é.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.2 |
| MITRE ATT&CK | M1037 |
| ISO 27001:2022 | A.8.20 |
| PCI DSS v4.0 | 1.2.1 |
| Scénario threat model | S1, S4 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Ports à autoriser par nœud (dans /etc/pve/nodes/<hostname>/host.fw) :
| Port | Protocole | Source | Rôle | Obligatoire |
|---|---|---|---|---|
| 22 | TCP | Réseau admin | SSH | ✅ |
| 8006 | TCP | Réseau admin | Web UI / API | ✅ |
| 5405-5412 | UDP | Réseau cluster | Corosync | ✅ (cluster) |
| 60000-60050 | TCP | Réseau cluster | Migration live | ✅ (cluster) |
| 5900-5999 | TCP | Réseau admin | Console VNC | ⚠️ Si noVNC utilisé |
| 3128 | TCP | Réseau admin | Console SPICE | ⚠️ Si SPICE utilisé |
| 6789 | TCP | Réseau stockage | Ceph monitor | ⚠️ Si Ceph |
| 6800-7300 | TCP | Réseau stockage/Ceph | Ceph OSD | ⚠️ Si Ceph |
| 2049 | TCP | Réseau stockage | NFS | ⚠️ Si NFS |
| 3260 | TCP | Réseau stockage | iSCSI | ⚠️ Si iSCSI |
| 111 | TCP/UDP | Réseau stockage | rpcbind (NFS) | ⚠️ Si NFS v3 |
Exemple /etc/pve/nodes/pve-node01/host.fw :
[OPTIONS]
enable: 1
[RULES]SSH depuis le réseau admin uniquement
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22
Web UI depuis le réseau admin
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 8006
Corosync depuis le réseau cluster
IN ACCEPT -source 10.0.40.0/24 -p udp -dport 5405:5412
Migration depuis le réseau cluster
IN ACCEPT -source 10.0.40.0/24 -p tcp -dport 60000:60050
Ceph depuis le réseau stockage (si applicable)
IN ACCEPT -source 10.0.30.0/24 -p tcp -dport 6789
IN ACCEPT -source 10.0.30.0/24 -p tcp -dport 6800:7300
ICMP
IN ACCEPT -p icmp
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.2, 4.4 |
| MITRE ATT&CK | M1030, M1037 |
| ISO 27001:2022 | A.8.20, A.8.22 |
| PCI DSS v4.0 | 1.2.1, 1.3.1 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite de définir les groupes et de les assigner.
🔍 Audit
Audit :
Lister les security groups
pvesh get /cluster/firewall/groups
Vérifier les VM sans firewall activé
for vmid in $(qm list 2>/dev/null | tail -n+2 | awk '{print $1}'); do
fw=$(qm config $vmid | grep "firewall=" | head -1)
echo "VM $vmid: $fw"
done
Résultat attendu : firewall=1 sur chaque interface de chaque VM
**Remédiation** :
Créer des Security Groups via l'interface web (Datacenter > Firewall > Security Group) ou via `/etc/pve/firewall/cluster.fw` :
[group web-server]
Serveur web standard
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22
[group db-server]
Serveur base de données — accès restreint
IN ACCEPT -source 10.0.20.0/24 -p tcp -dport 3306
IN ACCEPT -source 10.0.20.0/24 -p tcp -dport 5432
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22
[group management-only]
Accès SSH admin uniquement
IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22
IN ACCEPT -p icmp
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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢 |
| CIS Controls v8 | 4.2 |
| MITRE ATT&CK | M1037 |
| Scénario threat model | S4 |
| Statut PVE 9 | ⚠️ Partiel — tester soigneusement |
Description :
Description :
Rationale :
Rationale :
Impact : Élevé. FORWARD=DROP sans règles explicites casse la communication inter-VM, y compris les migrations live et la réplication si les VM utilisent le même bridge que le cluster.
⚠️ CORRECTION vs guide HomeSecExplorer : Le guide HSE recommande FORWARD=DROP sans documenter suffisamment les règles nécessaires pour le cluster. En pratique, cette modification casse les migrations si le réseau de migration passe par un bridge qui a aussi des VM.
🔧 Remédiation
Remédiation :
Seul mettre FORWARD=DROP si :
- Le réseau de migration est sur un bridge/VLAN séparé des VM
- Des règles FORWARD explicites sont configurées pour chaque flux inter-VM nécessaire
- Le changement a été testé en lab avec des migrations live
Dans cluster.fw (UNIQUEMENT après tests)
[OPTIONS]
policy_forward: DROP
**Valeur par défaut** : `policy_forward: ACCEPT`
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.2 |
| Scénario threat model | S1 |
| Statut PVE 9 | ⚠️ Partiel — fonctionnel mais plus récent |
Description :
Description :
Avantages du backend nftables :
- Pas de bridges firewall supplémentaires (fwbrX) créés pour les bridges Linux
- Architecture plus moderne et performante
- Meilleur support futur
Limitations :
- REJECT n'est pas disponible pour le trafic guest (trafic droppé à la place)
- Plus récent, moins de retour d'expérience communautaire
🔧 Remédiation
Remédiation :
[OPTIONS]
nftables: 1Valeur par défaut : Backend iptables (pve-firewall).
Spécificité PVE : Ne PAS confondre le backend nftables PVE avec le passage du système de iptables-legacy à nftables au niveau Debian. Le firewall PVE gère sa propre couche, indépendamment du backend nftables Debian.
4.3 — Protection réseau avancée
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 3.3.11 |
| CIS Controls v8 | 4.8, 12.2 |
| MITRE ATT&CK | T1557, M1037 |
| ISO 27001:2022 | A.8.20 |
| Scénario threat model | S4, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
⚠️ Rappel : ip_forward = 1 est requis par Proxmox. Le CIS recommande de le désactiver « si le système n'est pas un routeur », mais un hyperviseur PVE est un routeur pour ses VM. Ne PAS désactiver.
🔍 Audit
Audit :
sysctl net.ipv4.ip_forward
Résultat attendu : = 1 (requis par PVE)
sysctl net.ipv4.conf.all.rp_filter
Résultat attendu : = 1 (anti-spoofing actif)
**Remédiation** : Voir Phase 1 (1.2.2) pour la configuration complète des sysctl réseau.
---
4.4 — Checklist post-Phase 4
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ésentesNavigation : ← 05-acces-authentification.md | 07-stockage-chiffrement.md →
-e
07 — Phase 5 : Stockage et chiffrement
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Scénarios du threat model : S2, S9, S10
5.1 — Chiffrement au repos
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 3.6 — Encrypt Data on End-User Devices |
| MITRE ATT&CK | T1005 (Data from Local System), M1041 (Encrypt Sensitive Information) |
| ISO 27001:2022 | A.8.24 — Use of cryptography |
| PCI DSS v4.0 | 3.5.1 |
| Scénario threat model | S10 (accès physique) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
Vérifier LUKS
lsblk -f | grep -i crypt && echo "LUKS: PASS" || echo "LUKS: non détecté"
Vérifier ZFS encryption
zfs get encryption -r rpool 2>/dev/null | grep -v "off" | grep -v "NAME" && echo "ZFS encryption: PASS" || echo "ZFS encryption: non détecté"
Vérifier que /var/lib/vz est sur un volume chiffré
df /var/lib/vz | tail -1
Croiser avec lsblk -f pour vérifier si le device sous-jacent est chiffré
**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.
---
5.2 — Chiffrement en transit
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢 (clusters Ceph uniquement) |
| CIS Controls v8 | 3.10 — Encrypt Sensitive Data in Transit |
| MITRE ATT&CK | T1040 (Network Sniffing), T1557 (AitM), M1041 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S9 (interception trafic) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Surcoût performance ~5-10% sur le throughput Ceph (dépend du CPU et de la bande passante réseau).
🔍 Audit
Audit :
Vérifier le mode messenger
ceph config get mon ms_cluster_mode 2>/dev/null
Résultat attendu : secure
ceph config get osd ms_cluster_mode 2>/dev/null
Résultat attendu : secure
**Remédiation** :Forcer le mode secure (chiffré) pour toutes les communications
ceph config set global ms_cluster_mode secure
ceph config set global ms_service_mode secure
ceph config set global ms_client_mode secure
Vérifier
ceph config dump | grep ms_
**Valeur par défaut** : `crc` (intégrité uniquement, pas de chiffrement).
**Rollback** : `ceph config set global ms_cluster_mode crc`
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, M1041 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
NFS :
- Restreindre les exports par IP :
/etc/exportssur le serveur NFS ne doit lister que les IPs des nœuds PVE - Utiliser NFS v4 (pas v3) — supporte Kerberos pour l'authentification
- Isoler le trafic NFS sur le VLAN stockage (Phase 4)
iSCSI :
- Activer CHAP mutuel (authentification bidirectionnelle)
- Restreindre les initiateurs autorisés (LUN masking/zoning)
- Isoler sur le VLAN stockage
5.3 — Stockage Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 4.8 |
| MITRE ATT&CK | T1499.001 (OS Exhaustion), M1022 |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S2 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
findmnt /var/lib/vz && echo "PASS: partition séparée" || echo "INFO: sur le root fs"
df -h /var/lib/vz /
**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.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 3.3, 6.1 |
| MITRE ATT&CK | T1005, M1022 |
| ISO 27001:2022 | A.8.3 |
| PCI DSS v4.0 | 7.2.1 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
ls -la /var/lib/vz/
Résultat attendu : propriétaire root, permissions 755 ou plus restrictives
ls -la /var/lib/vz/images/ /var/lib/vz/dump/ 2>/dev/null
---
5.4 — Checklist post-Phase 5
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éesNavigation : ← 06-reseau-segmentation.md | 08-isolation-vm-ct.md →
-e
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Scénarios du threat model : S3, S8 Sources : BSI KVMSec v1.0.1, QEMU Security Documentation, OpenStack Security Guide
Ce chapitre couvre un domaine que les autres guides Proxmox ne traitent pas : le durcissement de la couche de virtualisation elle-même.
6.1 — Isolation QEMU/KVM
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.1, 10.5 |
| MITRE ATT&CK | T1611 (Escape to Host), T1068 (Exploitation for Privilege Escalation), M1050 (Exploit Protection) |
| ISO 27001:2022 | A.8.7, A.8.9 |
| PCI DSS v4.0 | 6.2.4 |
| Scénario threat model | S3 (VM escape) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nul. Seccomp est activé par défaut dans QEMU sur Proxmox.
🔍 Audit
Audit :
Vérifier seccomp sur un processus QEMU en cours
(remplacer <PID> par le PID d'un processus qemu)
QEMU_PID=$(pgrep -f "qemu-system" | head -1)
[ -n "$QEMU_PID" ] && grep -c "Seccomp" /proc/$QEMU_PID/status && echo "Seccomp mode:" && grep "Seccomp" /proc/$QEMU_PID/status || echo "Aucune VM en cours"
Résultat attendu : Seccomp: 2 (filter mode)
Vérifier la ligne de commande QEMU (ne doit PAS contenir -sandbox off)
ps aux | grep qemu | grep -c "sandbox off"
Résultat attendu : 0
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.1 |
| MITRE ATT&CK | T1003 (OS Credential Dumping — side channel), M1050 |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S3 (VM escape — side channel) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Augmentation de la consommation mémoire (pas de déduplication). Pertinent uniquement en multi-tenant ou si les VM hébergent des tenants non fiables.
⚠️ CORRECTION vs guide HomeSecExplorer : Le guide HSE recommande echo 2 > /sys/kernel/mm/ksm/run mais oublie de désactiver ksmtuned qui peut réactiver KSM automatiquement.
🔍 Audit
Audit :
cat /sys/kernel/mm/ksm/run
Résultat attendu : 0 (désactivé)
systemctl is-active ksmtuned 2>/dev/null
Résultat attendu : inactive
**Remédiation** :Désactiver KSM immédiatement
echo 0 > /sys/kernel/mm/ksm/run
Désactiver ksmtuned (peut réactiver KSM)
systemctl disable --now ksmtuned 2>/dev/null
Rendre persistant
echo "KSM_ENABLED=0" > /etc/default/ksm 2>/dev/null
cat > /etc/tmpfiles.d/disable-ksm.conf << 'EOF'
w /sys/kernel/mm/ksm/run - - - - 0
EOF
**Valeur par défaut** : KSM activé (`run = 1`) sur PVE pour économiser la mémoire.
**Rollback** : `echo 1 > /sys/kernel/mm/ksm/run`
---
| Profile Applicability | Level 1 — Server (si passthrough utilisé) |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.1 |
| MITRE ATT&CK | T1611 (Escape to Host), T1068, M1050 |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S8 (PCI/DMA) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nul si IOMMU est déjà activé. Peut nécessiter une modification BIOS + paramètre kernel.
🔍 Audit
Audit :
Vérifier IOMMU actif
dmesg | grep -i "IOMMU enabled\|DMAR\|AMD-Vi"
Résultat attendu : lignes indiquant IOMMU activé
Vérifier les groupes IOMMU
find /sys/kernel/iommu_groups/ -type l | head -20
Résultat attendu : groupes avec devices assignés
Vérifier les paramètres kernel
cat /proc/cmdline | grep -o "intel_iommu=on\|amd_iommu=on\|iommu=pt"
Résultat attendu : intel_iommu=on iommu=pt (ou amd_iommu=on)
**Remédiation** :
1. Activer VT-d (Intel) ou AMD-Vi dans le BIOS
2. Ajouter dans `/etc/default/grub` :Intel :
GRUB_CMDLINE_LINUX_DEFAULT="... intel_iommu=on iommu=pt"
AMD :
GRUB_CMDLINE_LINUX_DEFAULT="... amd_iommu=on iommu=pt"
update-grub && reboot
**Règle** : Ne JAMAIS passer un device PCI à une VM non fiable sans IOMMU vérifié fonctionnel.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 4.8, 16.13 |
| MITRE ATT&CK | T1611, M1042 (Disable or Remove Feature) |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
| Paramètre | Recommandation | Justification |
|---|---|---|
| Machine type | q35 |
Meilleure isolation que i440fx, support IOMMU natif |
| Floppy | Retirer | Device legacy inutile, surface d'attaque |
| Serial/Parallel ports | Retirer si non utilisés | Réduction surface d'attaque |
| USB tablet | Remplacer par tablet: 0 + VirtIO |
Évite l'émulation USB |
| CPU type | host ou modèle spécifique |
host = meilleure performance ; modèle = meilleure compatibilité migration |
| Ballooning | Désactiver si multi-tenant | Évite les fuites d'info mémoire |
Vérifier la configuration d'une VM
qm config <VMID> | grep -E "machine|cpu|balloon|serial|parallel"
---
6.2 — Isolation LXC
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 4.1, 5.4 |
| MITRE ATT&CK | T1611, M1026 |
| ISO 27001:2022 | A.8.7, A.8.9 |
| Scénario threat model | S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
Lister les conteneurs et leur mode
for ctid in $(pct list 2>/dev/null | tail -n+2 | awk '{print $1}'); do
unpriv=$(pct config $ctid | grep "unprivileged" | awk '{print $2}')
echo "CT $ctid: unprivileged=$unpriv"
done
Résultat attendu : unprivileged=1 pour tous les conteneurs
**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.
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 4.1 |
| MITRE ATT&CK | T1499 (Endpoint DoS), M1038 (Execution Prevention) |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔍 Audit
Audit :
Vérifier les limites d'une VM
qm config <VMID> | grep -E "memory|cores|cpulimit|bwlimit"
Résultat attendu : limites définies (pas de ressources illimitées)
**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)
---
6.3 — Checklist post-Phase 6
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"Navigation : ← 07-stockage-chiffrement.md | 09-monitoring-detection.md →
-e
09 — Phase 7 : Monitoring et détection
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Scénarios du threat model : S1-S10 (détection transversale)
7.1 — Collecte de métriques et alerting
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 (🟡 recommandé 🏠) |
| CIS Controls v8 | 8.2 — Collect Audit Logs, 8.11 — Conduct Audit Log Reviews |
| MITRE ATT&CK | T1070 (Indicator Removal), M1028 (OS Configuration) |
| ISO 27001:2022 | A.8.15, A.8.16 — Monitoring activities |
| PCI DSS v4.0 | 10.4.1 |
| Scénario threat model | Tous |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Option 1 : Proxmox Metric Server intégré (vers InfluxDB ou Graphite)
Configurer dans Datacenter > Metric Server
Option 2 : Prometheus + pve_exporter (recommandé)
Déployer dans une VM dédiée, pas sur l'hyperviseur lui-même
pve_exporter : https://github.com/prometheus-pve/prometheus-pve-exporter
**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) |
---
7.2 — Détection d'intrusion
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 8.5 — Collect Detailed Audit Logs |
| MITRE ATT&CK | T1070 (Indicator Removal), T1554 (Compromise Client Software), M1028 |
| ISO 27001:2022 | A.8.15, A.8.16 |
| PCI DSS v4.0 | 11.5.2 |
| Scénario threat model | S6, S7 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
apt install -y aide aide-common
Initialiser la base de données (APRÈS le hardening, pas avant)
aideinit
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
Programmer un scan quotidien
cat > /etc/cron.daily/aide-check << 'EOF'
#!/bin/bash
/usr/bin/aide --check | mail -s "AIDE report $(hostname)" admin@example.com
EOF
chmod +x /etc/cron.daily/aide-check
**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.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 8.2, 8.9 — Centralize Audit Logs |
| MITRE ATT&CK | T1070.002 (Clear Linux Logs), M1029 (Remote Data Storage) |
| ISO 27001:2022 | A.8.15 |
| PCI DSS v4.0 | 10.3.3 |
| Scénario threat model | S6 (insider) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔧 Remédiation
Remédiation :
Option A — rsyslog vers un serveur distant :
Dans /etc/rsyslog.d/remote.conf :
. @@logserver.example.com:514
@@ = TCP (recommandé), @ = UDP
**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.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 4.1 |
| Scénario threat model | Tous |
| Statut PVE 9 | 🧪 En développement |
Description :
Description :
🔧 Remédiation
Remédiation :
Télécharger et exécuter (quand disponible)
git clone https://github.com/<repo>/proxmox-hardening-guide-fr.git
cd proxmox-hardening-guide-fr/scripts
chmod +x audit.sh
./audit.sh
Résultat : rapport JSON + score de conformité
Programmer un audit mensuel
crontab -e
0 6 1 /opt/proxmox-hardening/scripts/audit.sh > /var/log/hardening-audit-$(date +\%Y\%m).json
---
7.3 — Checklist post-Phase 7
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é mensuellementNavigation : ← 08-isolation-vm-ct.md | 10-maintenance-continue.md →
-e
10 — Phase 8 : Maintenance et conformité continue
Version : 0.2.0 Date : 2026-03-20 Licence : CC BY-SA 4.0 Scénarios du threat model : Tous
8.1 — Gestion des patches
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 7.1, 7.4 |
| MITRE ATT&CK | M1051 (Update Software) |
| ISO 27001:2022 | A.8.8 |
| PCI DSS v4.0 | 6.3.1 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
- Liste de diffusion Proxmox :
pve-announce@lists.proxmox.com - Forum Proxmox — section Security
- Flux RSS Debian Security Advisories : https://www.debian.org/security/dsa
- CVE tracking : https://app.opencve.io (filtrer sur
proxmox,qemu,linux kernel)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 7.3 |
| Scénario threat model | S1, S3, S7 |
| Statut PVE 9 | ✅ Validé |
Remédiation : Voir Phase 2 (2.4.1) pour la procédure de rolling update détaillée.
Fréquences recommandées :
| Type de mise à jour | Fréquence | Procédure |
|---|---|---|
| Sécurité Debian (via unattended-upgrades) | Automatique quotidien | Automatisé Phase 1 |
| Paquets Proxmox (non-security) | Mensuel | Test lab → rolling update |
| Kernel PVE | Trimestriel ou sur CVE critique | Test lab → rolling update → reboot |
| Mise à jour majeure (PVE 9 → 10) | Annuel | Test complet → migration planifiée |
8.2 — Revue périodique
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 5.1, 6.1, 6.2 |
| MITRE ATT&CK | M1026, M1018 |
| ISO 27001:2022 | A.5.15, A.5.18 |
| PCI DSS v4.0 | 7.2.4, 8.6.3 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
Checklist de revue trimestrielle :
1. Lister tous les utilisateurs
pveum user list
2. Lister les ACL effectives
pveum acl list
3. Lister les tokens API
for user in $(pveum user list --output-format json 2>/dev/null | jq -r '.[].userid'); do
echo "=== $user ==="
pveum user token list "$user" 2>/dev/null
done
4. Vérifier les utilisateurs inactifs (pas de login récent)
Croiser avec les logs pveproxy
5. Vérifier les règles firewall
cat /etc/pve/firewall/cluster.fw
6. Vérifier la 2FA
cat /etc/pve/priv/tfa.cfg 2>/dev/null | wc -l
Comparer avec le nombre d'utilisateurs actifs
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
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 5.2 |
| MITRE ATT&CK | T1552, M1027 |
| ISO 27001:2022 | A.5.17 |
| PCI DSS v4.0 | 8.3.9, 8.6.3 |
| Scénario threat model | S1, S6 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
| Secret | Fréquence de rotation | Méthode |
|---|---|---|
| Tokens API | Annuelle ou sur incident | pveum user token remove + add |
| Clés SSH admin | Annuelle | Régénérer + redistribuer |
| Mots de passe root | Semestrielle | passwd sur chaque nœud |
| Certificats TLS (ACME) | Automatique (90j) | Géré par PVE |
| Certificats auto-signés | Annuelle | pvecm updatecerts --force |
8.3 — Documentation vivante
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 1.1, 2.1 |
| ISO 27001:2022 | A.5.9 |
| Statut PVE 9 | ✅ Validé |
Remédiation : Mettre à jour après chaque changement :
- Inventaire matériel (Phase 0, 0.1.5)
- Schéma réseau / VLAN
- Journal des changements (etckeeper, voir Phase 2, 2.5.1)
- Liste des déviations par rapport à ce guide (avec justification, acceptation du risque, approbation)
8.4 — Checklist post-Phase 8
PATCHES
[ ] 8.1.1 — Veille sécurité activée (mailing list, RSS, CVE tracking)
[ ] 8.1.2 — Procédure de mise à jour documentée et suivie
REVUE
[ ] 8.2.1 — Revue trimestrielle accès/permissions effectuée
[ ] 8.2.2 — Rotation des secrets planifiée
DOCUMENTATION
[ ] 8.3.1 — Inventaire à jour
[ ] 8.3.1 — Schéma réseau à jour
[ ] 8.3.1 — Journal des changements tenuNavigation : ← 09-monitoring-detection.md | 11-backup-dr.md →
11 — Phase 9 : Sauvegardes et reprise d'activité
Version : 0.2.0 Date : 2026-03-20 Licence : CC BY-SA 4.0 Scénarios du threat model : S2 (ransomware), S10
9.1 — Stratégie de sauvegarde
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 11.1 — Establish and Maintain a Data Recovery Process, 11.2 — Perform Automated Backups, 11.3 — Protect Recovery Data |
| MITRE ATT&CK | T1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery), M1053 (Data Backup) |
| ISO 27001:2022 | A.8.13 — Information backup |
| PCI DSS v4.0 | 9.4.1, 12.10.1 |
| Scénario threat model | S2 (ransomware) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
- 3 copies des données
- 2 types de supports différents
- 1 copie hors site
- 1 copie hors ligne ou immuable
- 0 erreur de restauration vérifiée
🔧 Remédiation
Remédiation :
Architecture de backup recommandée :
| Copie | Support | Emplacement | Immutabilité | Rétention |
|---|---|---|---|---|
| 1 — Primaire | PBS local | Même site | ⚠️ Non | 7 jours |
| 2 — Réplica | PBS distant | Site secondaire | ✅ Retention lock | 30 jours |
| 3 — Archive | Stockage objet (S3) ou bandes | Hors site | ✅ WORM/immutable | 90+ jours |
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 3.6, 11.3 |
| MITRE ATT&CK | T1486, T1490, M1053, M1041 |
| ISO 27001:2022 | A.8.13, A.8.24 |
| PCI DSS v4.0 | 3.5.1 |
| Scénario threat model | S2, S10 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
1. Générer une clé de chiffrement
proxmox-backup-client key create /etc/pve/priv/backup-encryption-key.json
2. Configurer le job de backup dans PVE pour utiliser cette clé
Via l'interface web : Datacenter > Backup > Add
Encryption Key : /etc/pve/priv/backup-encryption-key.json
3. ESCROWER LA CLÉ (CRITIQUE)
Copier la clé dans un endroit sécurisé HORS du cluster PVE :
- Password manager hors ligne
- Coffre-fort physique (impression du paperkey)
- HSM
Si la clé est perdue, les backups sont IRRÉCUPÉRABLES
proxmox-backup-client key show /etc/pve/priv/backup-encryption-key.json
**⚠️ Point critique** : L'escrow de la clé de chiffrement est **non négociable**. Le jour de la recovery n'est pas le moment d'improviser. Tester la restauration avec la clé escrow AVANT d'en avoir besoin.
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 11.3, 11.4 |
| MITRE ATT&CK | T1490 (Inhibit System Recovery), M1053 |
| ISO 27001:2022 | A.8.13 |
| PCI DSS v4.0 | 9.4.1 |
| Scénario threat model | S2 (ransomware) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Sur le serveur PBS :
Configurer la protection sur le datastore
Via l'interface PBS : Datastore > Edit > Protection
Ou via CLI :
proxmox-backup-manager datastore update <datastore> --keep-last 7 --keep-daily 30
Les backups dans la fenêtre de rétention ne peuvent pas être supprimés
même avec un token valide
**Mesures complémentaires** :
- Le token PVE utilisé pour les backups ne doit PAS avoir le privilège de suppression sur PBS
- PBS doit être sur un réseau/serveur séparé du cluster PVE
- L'accès admin PBS doit utiliser des credentials différents de PVE
---
9.2 — Sauvegardes hôte
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| CIS Controls v8 | 11.2 |
| ISO 27001:2022 | A.8.13 |
| Scénario threat model | S2, S4 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
Sauvegarder les configs réseau et firewall
tar czf /var/backups/network-config-$(date +%Y%m%d).tar.gz \
/etc/network/interfaces \
/etc/pve/firewall/ \
/etc/ssh/sshd_config.d/ \
/etc/sysctl.d/ \
/etc/fail2ban/ \
/etc/default/pveproxy \
2>/dev/null
---
9.3 — Tests de reprise
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 11.5 — Test Data Recovery |
| MITRE ATT&CK | M1053 |
| ISO 27001:2022 | A.5.29, A.5.30 |
| PCI DSS v4.0 | 12.10.2 |
| Scénario threat model | S2 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Protocole de drill trimestriel :
- Sélectionner une VM de test (ou clone d'une VM de production)
- Restaurer depuis PBS vers un nœud de test
- Vérifier le démarrage de la VM
- Vérifier l'intégrité des données applicatives
- Mesurer le temps total de restauration (RTO)
- Documenter les résultats :
- Date du drill
- VM restaurée
- Source du backup (local/distant/archive)
- Clé de chiffrement utilisée (escrow vérifié)
- RTO mesuré
- Résultat : succès/échec + notes
Point critique : Le drill DOIT tester la restauration avec la clé escrow (pas la clé sur le nœud PVE). C'est la seule façon de vérifier que l'escrow fonctionne.
9.4 — Checklist post-Phase 9
STRATÉGIE
[ ] 9.1.1 — Règle 3-2-1-1-0 implémentée
[ ] 9.1.2 — PBS configuré avec chiffrement client-side
[ ] 9.1.2 — Clé de chiffrement escrow hors du cluster PVE
[ ] 9.1.3 — Immutabilité activée sur PBS (anti-ransomware)
CONFIGS
[ ] 9.2.1 — /etc/pve sauvegardé (cron quotidien)
[ ] 9.2.1 — Configs réseau/firewall/SSH sauvegardées
TESTS
[ ] 9.3.1 — Drill de restauration effectué et documenté
[ ] 9.3.1 — RTO/RPO mesurés et conformes aux objectifs
[ ] 9.3.1 — Escrow de la clé vérifié lors du drillNavigation : ← 10-maintenance-continue.md | 12-experimental.md →
-e
Conclusion
Pour un accompagnement personnalisé, contactez notre équipe.
Plongez dans le guide complet
Lecture en ligne avec sommaire interactif, pagination par chapitre et navigation rapide. Ou téléchargez le PDF.