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 :

1.2.1 Plan de management (contrôle)

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.

1.2.2 Plan de données (workloads)

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).

1.2.3 Plan cluster

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).

1.2.4 Plan physique

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.

S1 Compromission via SSH ou l'interface web

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

S2 Ransomware ciblant l'hyperviseur et les backups

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

S3 Évasion de VM (VM escape)

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

S4 Mouvement latéral via le cluster

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

S5 Compromission du BMC/IPMI

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	Réf.	Priorité
Isolation BMC sur VLAN OOB dédié	0.1.2	🔴 Critique
Changement credentials par défaut	0.1.2	🔴 Critique
Désactivation protocoles non chiffrés	0.1.2	🔴 Critique
Mise à jour firmware BMC	0.1.1	🔴 Critique
Certificats TLS sur interface web BMC	0.1.2	🟡 Important

S6 Insider malveillant ou négligent

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

S7 Attaque supply chain (dépôts, paquets)

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

S8 Exploitation du PCI passthrough / accès DMA

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

S9 Interception du trafic inter-nœuds

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

S10 Accès physique non autorisé

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

0.1.1 Mise à jour firmware, BIOS et microcode CPU

Level 1

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.

---

0.1.2 Sécurisation BMC / IPMI / iDRAC / iLO

Level 1

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

---

0.1.3 Activer Secure Boot (UEFI)

Level 2

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.**

---

0.1.4 Activer et configurer TPM 2.0

Level 2

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)

---

0.1.5 Documenter l'inventaire matériel

Level 1

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

0.2.1 Sélectionner la méthode d'installation

Level 1

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.

0.2.2 Configurer le partitionnement selon CIS

Level 1

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.

---

0.2.3 Chiffrer les disques à l'installation

Level 2

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

---

0.2.4 Planifier l'architecture réseau

Level 1

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

Table des matières Chapitre 2 — OS Debian durci →

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

1.1.1 Configurer les dépôts Proxmox et vérifier les signatures GPG

Level 1

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).

---

1.1.2 Configurer les mises à jour automatiques de sécurité

Level 1

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).

---

1.1.3 Supprimer les paquets inutiles

Level 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

1.2.1 Configurer un mot de passe GRUB

Level 1

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`.

---

1.2.2 Appliquer les paramètres sysctl réseau

Level 1

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.

---

1.2.3 Appliquer les paramètres sysctl kernel

Level 2

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`

---

1.2.4 Désactiver les modules kernel inutiles

Level 1

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`

---

1.2.5 Appliquer les paramètres de démarrage kernel

Level 2

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-grub

NE 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

1.3.1 Configurer la politique de mots de passe

Level 1

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é.

---

1.3.2 Configurer le verrouillage après échecs d'authentification

Level 1

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.

---

1.3.3 Configurer le timeout d'inactivité shell

Level 1

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 TMOUT

Valeur par défaut : Pas de timeout.

1.3.4 Configurer la bannière de connexion

Level 1

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

1.4.1 Installer et configurer auditd

Level 2

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`

---

1.4.2 Configurer journald en mode persistant

Level 1

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=yes

systemctl restart systemd-journald

Valeur par défaut : Storage=auto (persistant si /var/log/journal existe, sinon volatile).

1.5 — Services et processus

1.5.1 Désactiver les services inutiles

Level 1

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

1.5.2 Masquer les services Proxmox non utilisés

Level 2

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

1.6.1 Vérifier qu'AppArmor est actif

Level 1

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 attendus

Navigation : ← 02-pre-installation.md | 04-proxmox-specifique.md →

-e

← Chapitre 1 — Threat Model Table des matières Chapitre 3 — Proxmox & Auth →

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)

2.1.1 Durcir la configuration TLS de pveproxy

Level 1

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.

---

2.1.2 Configurer des certificats Let's Encrypt / ACME

Level 1

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`).

---

2.1.3 Restreindre l'accès au Web UI par IP

Level 1

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.

---

2.1.4 Désactiver la console noVNC si non utilisée

Level 2

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

2.2.1 Préférer les tokens API aux mots de passe

Level 1

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`).

---

2.2.2 Restreindre l'accès API par IP

Level 2

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).

2.2.3 Activer l'audit des appels API

Level 2

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

2.3.1 Chiffrer les communications Corosync

Level 1

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.

---

2.3.2 Sécuriser le filesystem cluster `/etc/pve`

Level 1

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.

---

2.3.3 Sécuriser les migrations live

Level 2

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

2.4.1 Définir une stratégie de mise à jour PVE

Level 1

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 nested

apt 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.

---

2.4.2 Gérer les versions kernel

Level 2

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

2.5.1 Suivre les modifications de configuration avec etckeeper

Level 2

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 secure

Navigation : ← 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

3.1.1 Durcir la configuration sshd

Level 1

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 :

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

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

---

3.1.2 Durcir les algorithmes cryptographiques SSH (ssh-audit)

Level 1

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)

3.2.1 Configurer TOTP pour les comptes administrateurs

Level 1

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.

---

3.2.2 Configurer WebAuthn / FIDO2

Level 2

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)

3.3.1 Appliquer le principe de moindre privilège

Level 1

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>`.

---

3.3.2 Créer des rôles personnalisés

Level 2

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"

---

3.3.3 Intégrer LDAP/Active Directory

Level 2

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

3.4.1 Configurer Fail2Ban pour SSH

Level 1

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.

---

3.4.2 Configurer Fail2Ban pour le Web UI Proxmox

Level 1

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

3.5.1 Déployer WireGuard pour l'administration

Level 2

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ée

Navigation : ← 04-proxmox-specifique.md | 06-reseau-segmentation.md →

-e

← Chapitre 2 — OS Debian Table des matières Chapitre 4 — Réseau & Stockage →

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

4.1.1 Implémenter la segmentation VLAN

Level 1

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.

---

4.1.2 Configurer un bridge par zone de sécurité

Level 2

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

4.2.1 Activer le firewall avec une politique restrictive

Level 1

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é.

---

4.2.2 Configurer les règles par nœud

Level 1

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

---

4.2.3 Utiliser les Security Groups pour les VM

Level 1

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.

---

4.2.4 Contrôler la politique FORWARD et son impact cluster

Level 2

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`

---

4.2.5 Considérer le backend nftables

Level 2

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: 1

Valeur 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

4.3.1 Contrôler l'IP forwarding

Level 1

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ésentes

Navigation : ← 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

5.1.1 Vérifier le chiffrement des données au repos

Level 2

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

5.2.1 Activer le chiffrement Ceph en transit (Messenger v2)

Level 2

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`

---

5.2.2 Sécuriser les connexions stockage NFS/iSCSI

Level 2

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/exports sur 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

5.3.1 Isoler `/var/lib/vz` du root filesystem

Level 1

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.

---

5.3.2 Sécuriser les permissions des datastores

Level 1

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ées

Navigation : ← 06-reseau-segmentation.md | 08-isolation-vm-ct.md →

-e

← Chapitre 3 — Proxmox & Auth Table des matières Chapitre 5 — Isolation & Monitoring →

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

6.1.1 Vérifier les filtres seccomp pour QEMU

Level 2

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.

---

6.1.2 Désactiver KSM en environnement multi-tenant

Level 2

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`

---

6.1.3 Vérifier l'isolation IOMMU pour le PCI passthrough

Level 1

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.

---

6.1.4 Optimiser la configuration machine des VM

Level 2

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

---

6.2 — Isolation LXC

6.2.1 Utiliser des conteneurs non privilégiés par défaut

Level 1

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.

6.2.2 Appliquer les limites cgroup v2

Level 1

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

7.1.1 Déployer une solution de monitoring

Level 1

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

7.2.1 Déployer AIDE (Advanced Intrusion Detection Environment)

Level 2

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.

---

7.2.2 Centraliser les logs hors du contrôle des admins PVE

Level 2

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.

---

7.2.3 Exécuter le script d'audit du guide

Level 1

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é mensuellement

Navigation : ← 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

8.1.1 Veille sécurité Proxmox

Level 1

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)

8.1.2 Procédure de mise à jour documentée

Level 1

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

8.2.1 Revue trimestrielle des accès et permissions

Level 1

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

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

8.2.2 Rotation des secrets

Level 2

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

8.3.1 Maintenir l'inventaire et les schémas à jour

Level 1

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 tenu

Navigation : ← 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

9.1.1 Implémenter la règle 3-2-1-1-0

Level 1

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

9.1.2 Configurer PBS avec chiffrement client-side

Level 1

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.

9.1.3 Activer l'immutabilité des backups (anti-ransomware)

Level 1

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

9.2.1 Sauvegarder `/etc/pve` et les configs critiques

Level 1

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

9.3.1 Effectuer des drills de restauration trimestriels

Level 2

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 drill

Navigation : ← 10-maintenance-continue.md | 12-experimental.md →

-e

← Chapitre 4 — Réseau & Stockage Table des matières

Conclusion

Pour un accompagnement personnalisé, contactez notre équipe.

Nous contacter

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

Présentation

Ce qui le différencie

Base de référence

Structure du guide

Quickstart

Prérequis

Par où commencer ?

Règles d'or

Corrections notables vs guides existants

Format des contrôles

X.Y.Z — Titre du contrôle

Avertissements

Contribuer

Licence

01 — Modèle de menaces Proxmox VE

1.1 — Objectif et portée

Pourquoi un modèle de menaces ?

Portée

1.2 — Surfaces d'attaque

1.3 — Profils d'environnement

1.4 — Scénarios d'attaque

Description :

Description :

Description :

Description :

Description :

Description :

Description :

Description :

Description :

Description :

1.5 — Matrice menaces ↔ phases du guide

1.6 — Priorisation par profil

🏠 Homelab — Top 5 actions

🏢 Production — Top 10

🌐 Exposé internet — Ajouts critiques

1.7 — Références

02 — Phase 0 : Avant l'installation

Conventions du format

0.1 — Préparation matérielle

Description :

Rationale :

🔍 Audit

Version BIOS/UEFI

Résultat attendu : version correspondant à la dernière release constructeur

Version microcode CPU

ou :

Résultat attendu : version récente (comparer avec les advisories Intel/AMD)

Vérification des mitigations CPU actives

Résultat attendu : "Mitigation:" sur chaque ligne (pas "Vulnerable")

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 :

Intel

AMD

3. Redémarrer pour appliquer

Description :

Rationale :

🔍 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)

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)

Vérifier : Auth Type = PASSWORD uniquement n'est pas acceptable

Résultat attendu : des méthodes d'authentification fortes

Description :

Rationale :

🔍 Audit

Résultat attendu : "SecureBoot enabled"

Alternative si mokutil non installé :

Résultat attendu : "Secure boot enabled"

Résultat attendu : modules présents et chargés

Description :

Rationale :

🔍 Audit

Résultat attendu : 2

Résultat attendu : lignes indiquant un TPM détecté et initialisé

Enregistrer la clé TPM pour un volume LUKS