04 — Phase 2 : Durcissement spécifique Proxmox VE
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, Documentation Proxmox VE 9 Scénarios du threat model : S1, S3, S4, S6, S9
2.1 — Interface web (pveproxy)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox (hors CIS) |
| CIS Controls v8 | 3.10 — Encrypt Sensitive Data in Transit |
| MITRE ATT&CK | T1557 (Adversary-in-the-Middle), T1040 (Network Sniffing), M1041 (Encrypt Sensitive Information) |
| ISO 27001:2022 | A.8.24 — Use of cryptography |
| PCI DSS v4.0 | 4.2.1 — Strong cryptography for transmission |
| Scénario threat model | S1, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Faible. Les navigateurs modernes supportent tous TLS 1.2+ avec AES-GCM et ChaCha20. Seuls les clients très anciens (IE < 11, Android < 5) seraient affectés.
🔍 Audit
Audit :
Vérifier la configuration existante
cat /etc/default/pveproxy 2>/dev/null
Résultat attendu : fichier présent avec CIPHERS et HONOR_CIPHER_ORDER
Tester les ciphers acceptés (depuis un autre hôte)
nmap --script ssl-enum-ciphers -p 8006 <PVE_IP>
Résultat attendu : uniquement TLS 1.2 et 1.3, pas de ciphers CBC
Alternative avec openssl
openssl s_client -connect <PVE_IP>:8006 -tls1_1 2>&1 | grep -i "handshake"
Résultat attendu : handshake failure (TLS 1.1 refusé)
**Remédiation** :
Créer ou modifier `/etc/default/pveproxy` :Ciphers TLS 1.2 — uniquement AEAD (GCM, ChaCha20), pas de CBC
CIPHERS="ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"
Ciphers TLS 1.3 (défauts OpenSSL, déjà sécurisés)
CIPHERSUITES="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
Le serveur choisit le cipher (pas le client)
HONOR_CIPHER_ORDER=1
Désactiver TLS < 1.2 explicitement
(normalement déjà désactivé via OpenSSL sur Debian 13, mais par sécurité)
Note : pveproxy désactive SSL 2/3 inconditionnellement
systemctl restart pveproxy
**Valeur par défaut** : Le fichier `/etc/default/pveproxy` n'existe pas par défaut. Pveproxy utilise les ciphers par défaut d'OpenSSL (incluant des ciphers CBC SHA-256/SHA-384).
**Rollback** : `rm /etc/default/pveproxy && systemctl restart pveproxy`
**Spécificité PVE** : Pveproxy est un daemon Perl utilisant AnyEvent::TLS. La configuration se fait exclusivement via `/etc/default/pveproxy` — il n'y a pas de fichier de configuration Apache/Nginx.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, M1041 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite un FQDN résolvable et un accès réseau pour la validation ACME (HTTP-01 ou DNS-01).
🔍 Audit
Audit :
Vérifier le certificat actuel
openssl x509 -in /etc/pve/local/pve-ssl.pem -text -noout | grep -E "Issuer:|Not After"
Résultat attendu : Issuer != "Proxmox Virtual Environment" (pas auto-signé)
Not After : date dans le futur
Vérifier la configuration ACME
pvenode acme account list 2>/dev/null
**Remédiation** :1. Enregistrer un compte ACME
pvenode acme account register default <email@example.com> --directory https://acme-v02.api.letsencrypt.org/directory
2. Configurer le challenge (HTTP-01 ou DNS-01)
HTTP-01 (le port 80 doit être accessible depuis internet) :
pvenode config set --acme domains=<fqdn>
pvenode acme cert order
DNS-01 (recommandé si le serveur n'est pas directement accessible) :
Configurer le plugin DNS dans Datacenter > ACME
**Valeur par défaut** : Certificats auto-signés générés à l'installation.
**Spécificité PVE** : Proxmox intègre nativement le support ACME dans l'interface web (Datacenter > ACME, puis Node > System > Certificates). Le renouvellement automatique est géré par un timer systemd (`pve-daily-update.timer`).
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.2 — Establish and Maintain a Firewall Rule Set, 13.1 — Centralize Security Event Alerting |
| MITRE ATT&CK | T1190 (Exploit Public-Facing Application), M1030 (Network Segmentation), M1035 (Limit Access to Resource) |
| ISO 27001:2022 | A.8.20 — Network security |
| PCI DSS v4.0 | 1.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible, mais risque de lock-out si l'IP d'administration change. Toujours conserver un accès console hors-bande.
🔍 Audit
Audit :
Vérifier la configuration ACL pveproxy
grep -E "ALLOW_FROM|DENY_FROM|POLICY" /etc/default/pveproxy 2>/dev/null
Résultat attendu : ALLOW_FROM configuré, DENY_FROM="all", POLICY="deny"
Vérifier les règles firewall PVE pour le port 8006
pvesh get /cluster/firewall/rules 2>/dev/null | grep 8006
**Remédiation** :
**Méthode 1 — ACL pveproxy** (simple, appliquée au niveau applicatif) :
Dans `/etc/default/pveproxy` :Autoriser uniquement les réseaux d'administration
ALLOW_FROM="10.0.10.0/24,192.168.1.0/24"
DENY_FROM="all"
POLICY="deny"
systemctl restart pveproxy
**Méthode 2 — Firewall PVE** (recommandée, plus granulaire) :
Voir Phase 4 (4.2.2) pour la configuration complète des règles firewall par nœud.
**Méthode combinée** (🌐 recommandée) : Les deux méthodes sont complémentaires — la défense en profondeur.
**Valeur par défaut** : Aucune restriction. Pveproxy accepte les connexions de toutes les IP.
**Rollback** : Supprimer les lignes ALLOW_FROM/DENY_FROM/POLICY de `/etc/default/pveproxy` et `systemctl restart pveproxy`. Si lock-out : accéder via console et modifier le fichier.
**Spécificité PVE** : La syntaxe ALLOW_FROM accepte les notations CIDR, les plages IP, et les adresses individuelles séparées par des virgules. `LISTEN_IP` peut aussi restreindre l'interface d'écoute mais ne supporte qu'une seule IP.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.8 |
| MITRE ATT&CK | T1021.005 (VNC), M1042 (Disable or Remove Feature) |
| ISO 27001:2022 | A.8.9 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ⚠️ Partiel — spiceproxy masquable, noVNC intégré à pveproxy |
Description :
Description :
Rationale :
Rationale :
Impact : Moyen. Plus de console graphique pour les VM depuis l'interface web PVE. L'accès SSH aux VM reste fonctionnel.
🔧 Remédiation
Remédiation :
Désactiver SPICE proxy (port 3128)
systemctl mask --now spiceproxy.service
Note : utiliser 'mask' car pve-manager le réactive avec 'disable'
noVNC est intégré dans pveproxy et ne peut pas être désactivé séparément
→ Restreindre l'accès à pveproxy (2.1.3) est la meilleure mitigation
**Valeur par défaut** : spiceproxy actif et en écoute sur le port 3128.
**Rollback** : `systemctl unmask spiceproxy.service && systemctl start spiceproxy`
---
2.2 — API Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 5.2 — Use Unique Passwords, 5.4 — Restrict Administrator Privileges |
| MITRE ATT&CK | T1078 (Valid Accounts), T1552 (Unsecured Credentials), M1026 (Privileged Account Management) |
| ISO 27001:2022 | A.5.17, A.8.5 |
| PCI DSS v4.0 | 8.3.1, 8.6.1 |
| Scénario threat model | S1, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite de reconfigurer les outils d'automatisation existants.
🔍 Audit
Audit :
Lister les tokens API existants
pveum user token list <user>@<realm>
Résultat attendu : tokens dédiés par outil/service
Vérifier qu'aucun script n'utilise de mot de passe en dur
grep -rn "password\|PVE_PASSWORD" /root/ /home/ /opt/ /etc/cron* 2>/dev/null
Résultat attendu : aucune correspondance
**Remédiation** :Créer un token API pour Ansible (exemple)
pveum user token add ansible@pve ansible-token --privsep 1
privsep=1 : le token a ses propres privilèges (séparés de l'utilisateur)
privsep=0 : le token hérite des privilèges de l'utilisateur
Attribuer uniquement les privilèges nécessaires
pveum acl modify / --token 'ansible@pve!ansible-token' --role PVEVMAdmin
Le token sera affiché une seule fois — le stocker de manière sécurisée
**Valeur par défaut** : Aucun token API créé.
**Spécificité PVE** : Avec `--privsep 1`, le token a des privilèges indépendants de l'utilisateur parent, ce qui permet le moindre privilège. La rotation des tokens se fait par suppression + recréation (`pveum user token remove` puis `add`).
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.2, 13.1 |
| MITRE ATT&CK | T1190, M1030 |
| ISO 27001:2022 | A.8.20 |
| PCI DSS v4.0 | 1.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Remédiation : Voir 2.1.3 (même mécanisme ALLOW_FROM/DENY_FROM).
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 8.2, 8.5 |
| MITRE ATT&CK | T1070 (Indicator Removal), M1028 (OS Configuration) |
| ISO 27001:2022 | A.8.15 |
| PCI DSS v4.0 | 10.2.1 |
| Scénario threat model | S6 (insider) |
| Statut PVE 9 | ✅ Validé (logs pveproxy natifs) |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Vérifier que les logs API existent et sont alimentés
ls -la /var/log/pveproxy/access.log
tail -5 /var/log/pveproxy/access.log
Résultat attendu : fichier existant avec des entrées récentes
Vérifier la rotation des logs
cat /etc/logrotate.d/pveproxy 2>/dev/null
**Remédiation** :
Les logs API sont actifs par défaut. S'assurer de leur centralisation :Configurer rsyslog pour forwarder les logs pveproxy
(voir Phase 7 — 7.2.3 pour la centralisation complète)
**Valeur par défaut** : Logs actifs dans `/var/log/pveproxy/access.log`. Rotation via logrotate.
**Spécificité PVE** : Le format des logs pveproxy est spécifique (pas du Common Log Format standard). Les parseurs Fail2Ban doivent être adaptés (voir Phase 3 — 3.4.2).
---
2.3 — Cluster Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢 (clusters uniquement) |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.10, 12.6 |
| MITRE ATT&CK | T1557 (AitM), T1040 (Network Sniffing), M1041 (Encrypt Sensitive Information) |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S4 (mouvement latéral cluster) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Surcoût CPU négligeable avec AES-NI.
🔍 Audit
Audit :
Vérifier la configuration Corosync
grep -E "crypto_cipher|crypto_hash" /etc/corosync/corosync.conf
Résultat attendu :
crypto_cipher: aes256
crypto_hash: sha256
**Remédiation** :
**Lors de la création du cluster** (méthode recommandée) :
Le chiffrement est activé par défaut lors de la création d'un cluster PVE 9 via l'interface web ou `pvecm create`.
**Sur un cluster existant** (nécessite un redémarrage de Corosync sur tous les nœuds) :
Modifier `/etc/corosync/corosync.conf` dans la section `totem` :totem {
...existant...
crypto_cipher: aes256
crypto_hash: sha256
}
Appliquer sur TOUS les nœuds simultanément (fenêtre de maintenance)
systemctl restart corosync
**Valeur par défaut** : Sur PVE 9, le chiffrement Corosync est activé par défaut à la création du cluster (`aes256` + `sha256`). Sur les clusters migrés depuis PVE 7/8, il peut être désactivé.
**Rollback** : Remettre `crypto_cipher: none` et `crypto_hash: none`, redémarrer Corosync sur tous les nœuds.
**Spécificité PVE** : Le réseau Corosync doit être sur un VLAN dédié (voir Phase 4). Même avec le chiffrement activé, un réseau partagé expose le trafic à des attaques de déni de service ciblant Corosync.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏢 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.3, 4.1 |
| MITRE ATT&CK | T1552.004 (Private Keys), T1213 (Data from Information Repositories) |
| ISO 27001:2022 | A.8.3, A.8.12 |
| PCI DSS v4.0 | 3.5.1, 7.2.1 |
| Scénario threat model | S4, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Vérifier les permissions
ls -la /etc/pve/
Résultat attendu : propriétaire root:www-data, permissions restrictives
Vérifier qu'une sauvegarde récente existe
ls -la /var/lib/pve-cluster/backup/ 2>/dev/null
ou vérifier les sauvegardes PBS
Vérifier les changements récents (si etckeeper/git configuré)
cd /etc/pve && git log --oneline -5 2>/dev/null
**Remédiation** :1. Sauvegarder régulièrement /etc/pve
Via vzdump (inclus dans les backups PVE) ou manuellement :
tar czf /root/pve-config-backup-$(date +%Y%m%d).tar.gz /etc/pve/
2. Optionnel : suivre les changements avec etckeeper
apt install -y etckeeper
cd /etc/pve
git init
git add -A
git commit -m "Initial PVE config snapshot"
3. Programmer une sauvegarde automatique
cat > /etc/cron.daily/backup-pve-config << 'EOF'
#!/bin/bash
tar czf /var/backups/pve-config-$(date +%Y%m%d).tar.gz /etc/pve/ 2>/dev/null
find /var/backups/ -name "pve-config-*.tar.gz" -mtime +30 -delete
EOF
chmod +x /etc/cron.daily/backup-pve-config
**Valeur par défaut** : `/etc/pve` géré par pmxcfs, pas de sauvegarde automatique dédiée.
**Spécificité PVE** : `/etc/pve` est un mount FUSE. Il n'est pas accessible si `pve-cluster` n'est pas actif. Les modifications sont propagées automatiquement à tous les nœuds du cluster. La surveillance via auditd (configurée en Phase 1, 1.4.1) détecte les modifications.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, T1040 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S9 (interception trafic) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Moyen. Le chiffrement de la migration augmente la durée de migration et la charge CPU. L'impact dépend de la taille de la mémoire VM et de la bande passante réseau.
🔍 Audit
Audit :
Vérifier la configuration de migration
grep -E "migration:|migration_type" /etc/pve/datacenter.cfg 2>/dev/null
Résultat attendu : migration: secure
ou migration_network configuré sur un réseau dédié
**Remédiation** :
Via l'interface web : Datacenter > Options > Migration Settings
Via la CLI, modifier `/etc/pve/datacenter.cfg` :Forcer le chiffrement des migrations
migration: secure
Utiliser un réseau dédié pour les migrations (VLAN cluster)
migration_network: 10.0.40.0/24
**Valeur par défaut** : `migration: secure` est le défaut sur PVE 9 (vérifier sur les clusters migrés depuis des versions antérieures).
**Rollback** : Modifier `migration: insecure` dans `/etc/pve/datacenter.cfg`.
**Spécificité PVE** : Le mode `secure` utilise un tunnel SSH chiffré pour le transfert mémoire. Le mode `insecure` envoie les données en clair sur un port TCP éphémère (60000-60050). Même en mode `secure`, isoler le trafic de migration sur un VLAN dédié est recommandé pour la performance et la sécurité.
---
2.4 — Gestion des mises à jour Proxmox
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 1.2.2.1 (complémentaire) |
| CIS Controls v8 | 7.1, 7.3, 7.4 |
| MITRE ATT&CK | T1190, T1068, M1051 (Update Software) |
| ISO 27001:2022 | A.8.8 |
| PCI DSS v4.0 | 6.3.3 |
| Scénario threat model | S1, S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : La procédure elle-même n'a pas d'impact. L'application des mises à jour nécessite une fenêtre de maintenance avec reboot potentiel.
🔧 Remédiation
Remédiation :
Procédure de mise à jour recommandée :
- Veille : s'abonner aux listes de diffusion Proxmox et surveiller les advisories
Vérifier les mises à jour disponibles
apt update
apt list --upgradable 2>/dev/null | grep pve
2. **Test en lab** : appliquer les mises à jour sur un nœud de test ou un PVE nestedapt dist-upgrade # Sur le nœud de test
Vérifier : boot, Web UI, création VM, migration, stockage
3. **Rolling update en production** (un nœud à la fois) :Sur chaque nœud, un par un :
a) Migrer les VM critiques vers un autre nœud
b) Appliquer les mises à jour
apt dist-upgrade
c) Redémarrer si nécessaire (nouveau kernel)
reboot
d) Vérifier :
pveversion -v # Version PVE
uname -r # Kernel
systemctl status pveproxy pvedaemon corosync
pvecm status # Statut cluster
e) Passer au nœud suivant
4. **Documentation** : noter les versions avant/après dans le journal des changements
**Valeur par défaut** : Pas de procédure définie. Les mises à jour sont à l'initiative de l'administrateur.
**Spécificité PVE** : Sur PVE 9, les breaking changes kernel 6.17 incluent le renommage d'interfaces réseau, des incompatibilités NVIDIA vGPU/DRBD, et des régressions AppArmor LXC. Toujours consulter les release notes avant une mise à jour kernel.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 2.2 |
| MITRE ATT&CK | T1068, M1051 |
| ISO 27001:2022 | A.8.8 |
| Scénario threat model | S3 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
Lister les kernels installés
dpkg -l | grep pve-kernel | grep "^ii"
Résultat attendu : au moins 2 versions
Vérifier le kernel actif
uname -r
**Remédiation** :Conserver les anciens kernels (ne pas purger automatiquement)
Proxmox garde par défaut les anciens kernels
Pour épingler une version kernel (stabilité) :
apt-mark hold pve-kernel-<version>
Exemple :
apt-mark hold pve-kernel-6.12.6-1-pve
Pour désépingler :
apt-mark unhold pve-kernel-<version>
**Valeur par défaut** : Proxmox conserve les anciens kernels installés. Pas d'épinglage.
---
2.5 — Configuration PVE sécurisée
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.1, 8.2 |
| MITRE ATT&CK | T1070 (Indicator Removal), M1028 |
| ISO 27001:2022 | A.8.9, A.8.15 |
| PCI DSS v4.0 | 10.2.1 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
🔍 Audit
Audit :
dpkg -l etckeeper | grep -q "^ii" && echo "PASS" || echo "FAIL"
cd /etc && git log --oneline -3 2>/dev/null && echo "PASS: historique git" || echo "FAIL: pas d'historique"
**Remédiation** :apt install -y etckeeper
etckeeper s'initialise automatiquement et commite après chaque apt install/upgrade
Pour le filesystem cluster /etc/pve (voir 2.3.2)
**Valeur par défaut** : etckeeper non installé.
---
2.6 — Checklist post-Phase 2
INTERFACE WEB
[ ] 2.1.1 — Ciphers TLS durcis dans /etc/default/pveproxy
[ ] 2.1.2 — Certificats Let's Encrypt / ACME configurés (🏢🌐)
[ ] 2.1.3 — Accès Web UI restreint par IP
[ ] 2.1.4 — spiceproxy masqué si non utilisé (Level 2)
API
[ ] 2.2.1 — Tokens API utilisés (pas de mots de passe dans les scripts)
[ ] 2.2.2 — Accès API restreint par IP (Level 2)
[ ] 2.2.3 — Logs API collectés et centralisés
CLUSTER
[ ] 2.3.1 — Chiffrement Corosync activé (aes256 + sha256)
[ ] 2.3.2 — /etc/pve sauvegardé régulièrement
[ ] 2.3.3 — Migration configurée en mode secure + réseau dédié
MISES À JOUR
[ ] 2.4.1 — Procédure de mise à jour PVE documentée
[ ] 2.4.2 — Au moins 2 kernels installés
CONFIGURATION
[ ] 2.5.1 — etckeeper installé et fonctionnel (Level 2)
VALIDATION
[ ] Web UI accessible sur HTTPS avec certificat valide
[ ] sslscan/<PVE_IP>:8006 : uniquement TLS 1.2+ et ciphers AEAD
[ ] API fonctionnelle avec tokens
[ ] Cluster : pvecm status OK
[ ] Migration test : réussie en mode secureNavigation : ← 03-os-debian-durci.md | 05-acces-authentification.md →
-e
05 — Phase 3 : Accès et authentification
Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, Documentation Proxmox VE 9 Scénarios du threat model : S1, S4, S6
3.1 — Durcissement SSH
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 5.1.1 à 5.1.22 |
| CIS Controls v8 | 4.1, 5.2, 5.4 |
| MITRE ATT&CK | T1021.004 (SSH), T1110 (Brute Force), T1078 (Valid Accounts), M1032 (Multi-factor Authentication), M1035 (Limit Access) |
| ISO 27001:2022 | A.5.17, A.8.5, A.8.20 |
| PCI DSS v4.0 | 2.2.1, 8.2.1, 8.3.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact :
Moyen. Nécessite de configurer les clés SSH avant de désactiver l'authentification par mot de passe. Risque de lock-out si mal exécuté.
⚠️ SPÉCIFICITÉ PVE CRITIQUE — PermitRootLogin :
Proxmox utilise SSH root entre les nœuds du cluster pour les migrations live, la réplication, et les opérations cluster. Désactiver complètement le login root SSH casse le cluster.
La configuration recommandée est :
Désactiver le login root par mot de passe MAIS autoriser les clés
PermitRootLogin prohibit-password
Pour les clusters : autoriser root uniquement depuis le réseau cluster
Match Address 10.0.40.0/24
PermitRootLogin prohibit-password
**Audit** :Vérifier les paramètres critiques
sshd -T 2>/dev/null | grep -Ei "permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding|protocol"
Résultat attendu :
permitrootlogin prohibit-password
passwordauthentication no
pubkeyauthentication yes
maxauthtries 3
x11forwarding no
**Remédiation** :
**Étape 1 — Préparer les clés SSH AVANT de modifier sshd** :Sur votre poste d'administration :
ssh-keygen -t ed25519 -C "admin@pve"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<PVE_IP>
Tester que la connexion par clé fonctionne
ssh -i ~/.ssh/id_ed25519 root@<PVE_IP>
!! NE PAS fermer cette session !!
**Étape 2 — Modifier la configuration sshd** :
Créer `/etc/ssh/sshd_config.d/hardening.conf` :=== Authentification ===
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30
=== Protocole ===
(SSH protocol 1 est obsolète depuis longtemps — CIS 5.1.1)
Protocol 2 est le seul supporté sur OpenSSH récent
=== Fonctionnalités inutiles ===
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitUserEnvironment no
DisableForwarding yes
=== Bannière ===
Banner /etc/issue.net
=== Timeouts ===
ClientAliveInterval 300
ClientAliveCountMax 2
=== Logging ===
LogLevel VERBOSE
**Étape 3 — Tester et appliquer** :Valider la syntaxe
sshd -t
Résultat attendu : aucune erreur
Redémarrer sshd
systemctl restart sshd
TESTER IMMÉDIATEMENT depuis un NOUVEAU terminal
ssh -i ~/.ssh/id_ed25519 root@<PVE_IP>
Si ça fonctionne → OK
Si ça échoue → utiliser la session existante pour corriger
**Valeur par défaut** : `PasswordAuthentication yes`, `PermitRootLogin yes`, `MaxAuthTries 6`, `X11Forwarding yes`.
**Rollback** : `rm /etc/ssh/sshd_config.d/hardening.conf && systemctl restart sshd`
**Spécificité PVE** :
- **Ne JAMAIS mettre `PermitRootLogin no`** sur un nœud cluster — casse les migrations et la réplication
- `prohibit-password` autorise les clés SSH root (nécessaire au cluster) mais interdit les mots de passe
- Pour la configuration SSH client des peers cluster (compatibilité clés RSA PVE), voir la section ssh-audit ci-dessous
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | 5.1.6 à 5.1.10 |
| CIS Controls v8 | 3.10 |
| MITRE ATT&CK | T1557, M1041 |
| ISO 27001:2022 | A.8.24 |
| PCI DSS v4.0 | 4.2.1 |
| Scénario threat model | S1, S9 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Les clients SSH modernes supportent tous les algorithmes recommandés. Les clients très anciens (PuTTY < 0.75, OpenSSH < 7.6) pourraient être impactés.
🔍 Audit
Audit :
Installer et exécuter ssh-audit
apt install -y ssh-audit 2>/dev/null || pip install ssh-audit --break-system-packages
ssh-audit localhost
Résultat attendu : pas de lignes en rouge (fail) ou orange (warn)
**Remédiation** :
Ajouter dans `/etc/ssh/sshd_config.d/hardening.conf` :=== Algorithmes (ssh-audit Debian 13 server guide) ===
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
**Configuration SSH client pour les peers cluster** :
Proxmox stocke des clés hôte RSA dans `/etc/pve/nodes/*/ssh_known_hosts`. Pour éviter les warnings lors des opérations cluster tout en utilisant Ed25519 pour l'accès externe :
Créer `/root/.ssh/config` sur chaque nœud :=== Peers cluster — utiliser les clés RSA ===
Host pve-node 10.0.40.
HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms rsa-sha2-512,rsa-sha2-256
=== Accès externe — Ed25519 préféré ===
Host *
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
systemctl restart sshd
**Valeur par défaut** : Algorithmes par défaut d'OpenSSL/OpenSSH incluant des options legacy.
---
3.2 — Authentification multi-facteurs (2FA)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 6.3 — Require MFA for Externally-Exposed Applications, 6.4 — Require MFA for Remote Network Access, 6.5 — Require MFA for Administrative Access |
| MITRE ATT&CK | T1078 (Valid Accounts), T1110 (Brute Force), M1032 (Multi-factor Authentication) |
| ISO 27001:2022 | A.8.5 — Secure authentication |
| PCI DSS v4.0 | 8.4.1, 8.4.2, 8.4.3 |
| Scénario threat model | S1, S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite une app TOTP (FreeOTP, Google Authenticator, Aegis, etc.) et une procédure de récupération documentée.
⚠️ CORRECTION vs guide HomeSecExplorer : La syntaxe pveum realm modify <<pam>> --tfa type=<<oath>> est incorrecte et échoue. La bonne procédure est via l'interface web ou /etc/pve/domains.cfg.
🔍 Audit
Audit :
Vérifier si le 2FA est configuré pour les utilisateurs
cat /etc/pve/priv/tfa.cfg 2>/dev/null | head -5
Résultat attendu : entrées TFA pour les utilisateurs
Vérifier si un realm impose le 2FA
grep -i "tfa" /etc/pve/domains.cfg 2>/dev/null
**Remédiation** :
**Procédure recommandée (via interface web)** :
1. Se connecter à l'interface web PVE (`https://<PVE_IP>:8006`)
2. Aller dans **Datacenter > Permissions > Two Factor**
3. Cliquer **Add > TOTP**
4. Scanner le QR code avec votre app authenticator
5. Entrer le code de vérification
6. **Générer des Recovery Keys** (IMPÉRATIF — les stocker hors ligne)
**Pour imposer le 2FA au niveau du realm** :
- Via l'interface web : **Datacenter > Permissions > Realms** > sélectionner `pam` > **Edit** > **TFA** : sélectionner "OATH (TOTP)"
- ⚠️ Si vous sélectionnez "OATH (TOTP)" comme exigence du realm, **seul** TOTP sera accepté (pas WebAuthn). Pour autoriser TOTP ou WebAuthn au choix de l'utilisateur, laisser le champ TFA du realm à "none" et imposer le 2FA par politique organisationnelle.
**Procédure de récupération en cas de perte du token** :Via SSH (toujours accessible avec les clés) :
Option 1 : utiliser une Recovery Key
Option 2 : supprimer le TFA de l'utilisateur
Éditer /etc/pve/priv/tfa.cfg et supprimer la ligne de l'utilisateur concerné
Ou supprimer tout le TFA :
rm /etc/pve/priv/tfa.cfg
⚠️ Ceci supprime le 2FA de TOUS les utilisateurs
**Valeur par défaut** : Aucun 2FA configuré.
**Spécificité PVE** : Le 2FA PVE est indépendant du 2FA PAM système. Il protège l'interface web et l'API REST, mais PAS l'accès SSH (qui est protégé par les clés SSH). C'est la combinaison des deux (clés SSH + 2FA web) qui assure la protection complète.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 6.3, 6.4, 6.5 |
| MITRE ATT&CK | T1078, T1110, T1566 (Phishing), M1032 |
| ISO 27001:2022 | A.8.5 |
| PCI DSS v4.0 | 8.4.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Nécessite un certificat TLS valide (pas auto-signé) et la configuration WebAuthn dans PVE.
Prérequis :
- Certificat TLS valide sur le nœud PVE (voir Phase 2, 2.1.2)
- Hardware key (YubiKey, SoloKeys) ou platform authenticator (Touch ID, Windows Hello, Android)
🔧 Remédiation
Remédiation :
- Origin :
https://<votre-fqdn>:8006 - Relying Party :
<votre-fqdn> - ID :
<votre-domaine>
- Datacenter > Permissions > Two Factor > Add > WebAuthn
- Enregistrer votre clé ou authenticator
Valeur par défaut : WebAuthn non configuré.
Spécificité PVE : En cluster, le WebAuthn Relying Party doit correspondre au domaine par lequel vous accédez au cluster. Si vous accédez via des noms différents par nœud, WebAuthn ne fonctionnera que pour le domaine configuré. Un load balancer ou DNS round-robin avec un FQDN unique est recommandé.
3.3 — RBAC Proxmox (contrôle d'accès basé sur les rôles)
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 5.4 — Restrict Administrator Privileges, 6.1 — Establish an Access Granting Process, 6.8 — Define and Maintain Role-Based Access Control |
| MITRE ATT&CK | T1078 (Valid Accounts), M1026 (Privileged Account Management), M1018 (User Account Management) |
| ISO 27001:2022 | A.5.15, A.5.18, A.8.2 |
| PCI DSS v4.0 | 7.2.1, 7.2.2 |
| Scénario threat model | S6 (insider) |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Faible. Nécessite la création de comptes et l'attribution de rôles.
🔍 Audit
Audit :
Lister les utilisateurs
pveum user list
Résultat attendu : des comptes nominatifs en plus de root@pam
Vérifier les ACL
pveum acl list
Résultat attendu : ACL par utilisateur/groupe, pas de '/' attribué à tout le monde
Vérifier les connexions récentes avec root@pam
journalctl -u pvedaemon --since "7 days ago" | grep "root@pam" | grep "successful" | tail -5
Résultat attendu : minimal (root@pam ne devrait pas être utilisé quotidiennement)
**Remédiation** :1. Créer un groupe d'administrateurs
pveum group add admins --comment "Administrateurs PVE"
2. Créer des comptes nominatifs
pveum user add alice@pve --firstname Alice --lastname Dupont --email alice@example.com --groups admins
pveum passwd alice@pve
3. Attribuer le rôle Administrator au groupe sur /
pveum acl modify / --group admins --role Administrator
4. Imposer le 2FA pour ces comptes (voir 3.2.1)
5. Documenter la procédure d'utilisation de root@pam :
→ uniquement pour les opérations de maintenance système
→ uniquement via SSH avec clé
→ jamais via l'interface web en usage quotidien
**Rôles prédéfinis utiles PVE** :
| Rôle | Privilèges | Usage type |
|------|-----------|------------|
| `Administrator` | Tous | Admin infra (à limiter au strict nécessaire) |
| `PVEVMAdmin` | Gestion VM complète | Opérateur VM |
| `PVEVMUser` | Console, start/stop | Utilisateur VM |
| `PVEAuditor` | Lecture seule | Auditeur, monitoring |
| `PVEDatastoreUser` | Backup, restore | Opérateur backup |
**Valeur par défaut** : Seul `root@pam` existe avec tous les privilèges.
**Spécificité PVE** :
- Les nouveaux privilèges PVE 9 incluent `VM.Replicate` (ajouté) et `VM.Monitor` (supprimé). Vérifier les rôles custom après une mise à jour majeure.
- Préférer les groupes aux ACL individuelles pour faciliter la maintenance.
- Les ACL PVE supportent les chemins : `/`, `/vms/<vmid>`, `/storage/<storage>`, `/pool/<pool>`.
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢🌐 |
| CIS Controls v8 | 6.8 |
| MITRE ATT&CK | M1026 |
| ISO 27001:2022 | A.5.15, A.5.18 |
| PCI DSS v4.0 | 7.2.2 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
🔧 Remédiation
Remédiation :
Rôle "opérateur VM" (start/stop/console, pas de create/delete)
pveum role add VMOperator --privs "VM.Console VM.PowerMgmt VM.Monitor VM.Audit"
Rôle "admin backup" (backup/restore uniquement)
pveum role add BackupAdmin --privs "Datastore.AllocateSpace Datastore.Audit VM.Backup"
Rôle "lecteur réseau" (audit réseau uniquement)
pveum role add NetAuditor --privs "SDN.Audit Sys.Audit"
---
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🏢 |
| CIS Controls v8 | 5.6, 6.1, 6.7 |
| MITRE ATT&CK | T1078.002 (Domain Accounts), M1026 |
| ISO 27001:2022 | A.5.16, A.5.17 |
| PCI DSS v4.0 | 7.2.1, 8.2.1 |
| Scénario threat model | S6 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Impact : Moyen. Dépendance à l'infrastructure LDAP/AD.
🔧 Remédiation
Remédiation :
Ajouter un realm LDAP
pveum realm add myldap --type ldap \
--base-dn "ou=People,dc=example,dc=com" \
--bind-dn "cn=pve-readonly,dc=example,dc=com" \
--server1 ldap.example.com \
--port 636 \
--secure 1 \
--user-attr uid
⚠️ TOUJOURS utiliser LDAPS (port 636) ou StartTLS
Ne JAMAIS utiliser LDAP en clair (port 389) → credentials transitent en clair
Synchroniser les groupes
pveum realm sync myldap
**Valeur par défaut** : Seuls les realms `pam` et `pve` sont configurés.
**Spécificité PVE** : La synchronisation LDAP importe les utilisateurs et groupes dans `/etc/pve/user.cfg`. Les mots de passe ne sont PAS stockés dans PVE (authentification relayée vers le serveur LDAP).
---
3.4 — Protection brute-force
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Complémentaire |
| CIS Controls v8 | 4.1, 13.1 |
| MITRE ATT&CK | T1110 (Brute Force), M1036 (Account Use Policies) |
| ISO 27001:2022 | A.8.5, A.8.16 |
| PCI DSS v4.0 | 8.3.4 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
🔧 Remédiation
Remédiation :
apt install -y fail2ban
La jail SSH est préconfigurée, il suffit de l'activer
cat > /etc/fail2ban/jail.d/sshd.conf << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 2d
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 30d
EOF
systemctl enable --now fail2ban
**Notes** : Le `bantime.increment` est crucial — après le premier ban de 1h, le deuxième sera de 24h, le troisième de 48h, etc. Rend le brute-force véritablement impraticable.
---
| Profile Applicability | Level 1 — Server |
| Applicabilité PVE | 🏠🏢🌐 |
| Réf. CIS Debian 13 | Spécifique Proxmox |
| CIS Controls v8 | 4.1, 13.1 |
| MITRE ATT&CK | T1110, T1190, M1036 |
| ISO 27001:2022 | A.8.5, A.8.16 |
| PCI DSS v4.0 | 8.3.4 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
⚠️ CORRECTION CRITIQUE : Sur PVE 9, syslog n'est plus installé par défaut. La configuration Fail2Ban doit utiliser le backend systemd (journal), PAS /var/log/daemon.log ou /var/log/syslog. Les guides qui pointent vers ces fichiers ne fonctionnent PAS sur PVE 9.
Impact : Faible. Risque de faux positif si findtime est trop court.
🔍 Audit
Audit :
Vérifier que le jail proxmox est actif
fail2ban-client status proxmox 2>/dev/null
Résultat attendu : jail active avec nombre de bans
Tester le regex contre le journal
fail2ban-regex systemd-journal /etc/fail2ban/filter.d/proxmox.conf
Résultat attendu : "Failregex: X total" (X > 0 si des échecs existent)
**Remédiation** :
**Filtre** — Créer `/etc/fail2ban/filter.d/proxmox.conf` :[INCLUDES]
before = common.conf
[Definition]
failregex = pvedaemon\[.authentication failure; rhost=<HOST> user=. msg=.*
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
ignoreregex =
**Jail** — Créer `/etc/fail2ban/jail.d/proxmox.conf` :[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 30d
systemctl restart fail2ban
Vérifier
fail2ban-client status proxmox
**Validation** :Provoquer un échec d'authentification volontaire via l'interface web
(mauvais mot de passe), puis vérifier :
fail2ban-regex systemd-journal /etc/fail2ban/filter.d/proxmox.conf
Résultat attendu : au moins 1 match
**Valeur par défaut** : Fail2Ban non installé. Aucune protection brute-force sur le port 8006.
**Rollback** : `apt purge fail2ban`
**Spécificité PVE** :
- Le `journalmatch = _SYSTEMD_UNIT=pvedaemon.service` est essentiel pour la performance — sans lui, Fail2Ban scanne TOUT le journal systemd.
- Penser aussi à protéger le realm PAM : si PAM est un realm de login disponible, ajouter le jail `pam-generic` standard de Fail2Ban.
- En cluster, Fail2Ban doit être installé sur **chaque nœud** individuellement (la configuration n'est pas synchronisée via pmxcfs).
---
3.5 — Accès VPN
| Profile Applicability | Level 2 — Server |
| Applicabilité PVE | 🌐 |
| Réf. CIS Debian 13 | Spécifique infrastructure |
| CIS Controls v8 | 12.7 — Ensure Remote Devices Use a VPN |
| MITRE ATT&CK | T1133 (External Remote Services), M1030 (Network Segmentation), M1037 (Filter Network Traffic) |
| ISO 27001:2022 | A.8.20, A.8.22 |
| PCI DSS v4.0 | 1.2.1, 2.2.7, 4.2.1 |
| Scénario threat model | S1 |
| Statut PVE 9 | ✅ Validé |
Description :
Description :
Rationale :
Rationale :
Impact : Moyen. Nécessite une configuration VPN sur chaque poste d'administration. Si le VPN est inaccessible, l'administration du serveur l'est aussi (prévoir un accès console OOB de secours).
🔧 Remédiation
Remédiation :
apt install -y wireguard
Générer les clés serveur
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
chmod 600 /etc/wireguard/server.key
Créer `/etc/wireguard/wg0.conf` :[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = <contenu de /etc/wireguard/server.key>
Post-up : autoriser le trafic VPN vers les ports management
PostUp = iptables -A INPUT -i wg0 -j ACCEPT
PostDown = iptables -D INPUT -i wg0 -j ACCEPT
[Peer]
Poste admin 1
PublicKey = <clé publique du client>
AllowedIPs = 10.10.10.2/32
systemctl enable --now wg-quick@wg0
Vérifier
wg show
Puis restreindre l'accès SSH et web UI au VPN uniquement (via firewall PVE ou pveproxy ALLOW_FROM, voir Phase 2 et Phase 4).
**Valeur par défaut** : WireGuard non installé.
**Spécificité PVE** :
- Idéalement, WireGuard ne devrait PAS tourner sur l'hyperviseur lui-même mais dans une VM ou un conteneur dédié, ou sur un routeur externe. Cela évite qu'un bug WireGuard compromette directement l'hyperviseur. En pratique pour un serveur unique chez un hébergeur, le faire tourner sur l'hôte est acceptable.
- **Alternatives** : OpenVPN, Tailscale/Headscale (mesh VPN sans configuration NAT), ZeroTier.
---
3.6 — Checklist post-Phase 3
SSH
[ ] 3.1.1 — Clés SSH configurées et testées AVANT modification sshd
[ ] 3.1.1 — PasswordAuthentication no
[ ] 3.1.1 — PermitRootLogin prohibit-password (pas 'no' en cluster !)
[ ] 3.1.1 — MaxAuthTries 3, X11Forwarding no
[ ] 3.1.2 — Algorithmes ssh-audit appliqués
[ ] 3.1.2 — Config SSH client pour peers cluster (/root/.ssh/config)
2FA
[ ] 3.2.1 — TOTP configuré pour tous les comptes admin
[ ] 3.2.1 — Recovery keys générées et stockées hors ligne
[ ] 3.2.2 — WebAuthn configuré (Level 2, 🏢🌐)
RBAC
[ ] 3.3.1 — Comptes nominatifs créés (root@pam non utilisé quotidiennement)
[ ] 3.3.1 — Groupes et rôles attribués
[ ] 3.3.2 — Rôles custom créés si nécessaire (Level 2)
[ ] 3.3.3 — LDAP/AD intégré si applicable (Level 2, 🏢)
FAIL2BAN
[ ] 3.4.1 — Jail SSH active et testée
[ ] 3.4.2 — Jail Proxmox web UI active avec backend systemd
[ ] 3.4.2 — Regex validé : fail2ban-regex systemd-journal proxmox.conf
VPN (🌐)
[ ] 3.5.1 — WireGuard déployé (si serveur exposé internet)
[ ] 3.5.1 — SSH et web UI accessibles uniquement via VPN
VALIDATION
[ ] Connexion SSH par clé fonctionnelle
[ ] Connexion web UI avec 2FA fonctionnelle
[ ] Fail2Ban : tester un échec d'auth et vérifier le ban
[ ] En cluster : migration live fonctionnelle (SSH root entre nœuds)
[ ] Procédure de récupération 2FA documentée et testéeNavigation : ← 04-proxmox-specifique.md | 06-reseau-segmentation.md →
-e