Checklist de sécurité Proxmox : 2FA, RBAC, pare-feu, mises à jour et accès distant sécurisé

Modèle de menace en une page : ce que vous défendez

Proxmox est un plan de contrôle, pas seulement un hyperviseur. Si un attaquant accède à Proxmox, il n’obtient pas juste une VM.
Il peut monter des disques, snapshotter et exfiltrer des données, lire la sortie console (bonjour, secrets), attacher des ISO, et
modifier le réseau. « Root sur l’hôte » est catastrophique ; « admin dans l’UI » est souvent équivalent.

Ce qui tourne généralement mal

• Interface de gestion exposée (8006) à Internet, parfois avec authentification par mot de passe et sans 2FA.
• Opérateurs sur-permissionnés (« donnez-leur juste PVEAdmin pour qu’ils fassent leur travail ») qui devient permanent.
• Hypothèses sur le pare-feu : les gens pensent que le pare-feu du datacenter est « activé » parce que l’UI a une case à cocher.
• Évitement des correctifs parce que « on ne peut pas redémarrer ». Spoiler : vous le pouvez, ou vous redémarrerez à 3 h du matin lors d’un incident.
• Raccourcis d’accès distant : SSH depuis partout, jump boxes partagés, ou pire, comptes partagés.

Priorités de durcissement (opinionnées)

1. Rendre le plan de gestion inaccessible depuis les réseaux non fiables. VPN ou réseau admin dédié.
2. Appliquer 2FA pour tous les humains. Tokens pour l’automatisation.
3. Utiliser RBAC correctement : moindre privilège, rôles explicites, séparation entre « opérer des VMs » et « changer le cluster ».
4. Activer et vérifier le pare-feu au bon niveau, avec un défaut « deny » là où cela compte.
5. Patcher avec un plan : fenêtres de maintenance prévisibles, mises à jour échelonnées, et discipline de redémarrage.

Idée paraphrasée de Werner Vogels (fiabilité/ops) : « Tout échoue éventuellement ; concevez en supposant la défaillance, pas la perfection. »
C’est l’esprit à adopter ici.

Faits et contexte intéressants (pour arrêter de faire des erreurs de 2008)

• Fait 1 : Le port de gestion par défaut de Proxmox VE est 8006, et les scanners l’aiment parce qu’il est constant et bavard.
• Fait 2 : Le pare-feu Proxmox n’est pas « juste iptables ». Il compile des règles et les gère ; il faut vérifier les règles effectives sur l’hôte.
• Fait 3 : Le RBAC dans Proxmox est basé sur les chemins. Les permissions héritent dans l’arbre d’objets (datacenter → node → VM), ce qui est puissant et facile à surutiliser.
• Fait 4 : Les tokens API existent pour une raison : l’automatisation ne doit pas se connecter comme un humain. Les tokens peuvent être scindés et pivotés avec moins de drame.
• Fait 5 : Les réseaux de gestion sont devenus un modèle standard dans les années 2000 parce que les erreurs de « VLAN admin » coûtaient moins cher que « flotte entière compromise ».
• Fait 6 : Le « SSH uniquement mot de passe » a survécu plus longtemps qu’il ne le devrait parce que c’est pratique. La commodité n’est pas un contrôle ; c’est une responsabilité.
• Fait 7 : La culture de packaging de Debian favorise la stabilité, mais les correctifs de sécurité arrivent fréquemment. « Stable » n’est pas « statique ».
• Fait 8 : Le trafic de cluster (Corosync) a des besoins très différents du trafic de l’UI web ; le traiter comme du trafic utilisateur normal est une excellente façon d’inventer des pannes.

Checklists / plan étape par étape (faites ceci, pas des impressions)

Jour 0–1 : Arrêter l’hémorragie

1. Bloquer l’accès public à 8006 et SSH à la périphérie. Si vous ne pouvez pas, vous n’avez pas de plan de gestion — vous avez une API publique.
2. Activer le 2FA pour tous les utilisateurs interactifs. Aucune exception pour les comptes « temporaires ».
3. Auditer les utilisateurs/tokens. Supprimer les comptes obsolètes, pivoter les secrets, supprimer les connexions partagées.
4. Confirmer l’état du pare-feu (datacenter + nœud) et vérifier les règles effectives sur l’hôte.
5. Ligne de base de correctifs : mettre tous les nœuds à jour avec les correctifs de sécurité ; planifier les redémarrages.

Semaine 1 : Rendre ça ennuyeux

1. Définir les rôles RBAC pour les tâches courantes (opérateur VM, opérateur sauvegarde, admin stockage, admin cluster).
2. Isoler la gestion sur un réseau admin ou VPN, et lier les services à ce réseau quand c’est praticable.
3. Durcir SSH (clés, pas de login root, sources restreintes).
4. Journalisation et alerting : suivre les échecs d’auth, les changements de configuration et les drops du pare-feu.

Mois 1 : Réduire le rayon d’impact

1. Séparer les responsabilités : les changements de membership du cluster et les modifications de stockage doivent être limités à un petit nombre de personnes.
2. Tester les chemins de restauration et verrouiller le stockage des sauvegardes ; les sauvegardes sont la première cible d’exfiltration après les données primaires.
3. Documenter les runbooks pour la réponse aux incidents : perte d’un dispositif 2FA, compte compromis, reconstruction d’un nœud.

2FA qui réduit vraiment le risque (sans bloquer les admins)

Le 2FA n’est pas magique. C’est une ceinture de sécurité : il n’empêche pas les accidents ; il empêche qu’une mauvaise journée devienne catastrophique.
Utilisez TOTP ou WebAuthn selon votre culture et vos outils. En pratique, TOTP est le plus simple à déployer. WebAuthn est plus agréable quand votre organisation
maîtrise déjà les clés de sécurité et le cycle de vie des dispositifs.

Règles que j’applique en production

• 2FA requis pour tous les comptes humains ayant accès à l’UI ou au shell.
• Pas de comptes partagés. Les comptes partagés rendent les audits fictifs.
• Procédure break-glass existe, mais elle est triste : procédure scellée, stockée hors ligne, et utilisée avec une trace papier.
• L’automatisation utilise des tokens API, pas des mots de passe. Les tokens sont pivotés ; les humains sont sanctionnés s’ils intègrent des mots de passe dans des scripts.

Blague 1 : le 2FA, c’est comme le fil dentaire — tout le monde est d’accord que c’est une bonne idée, et puis ils « commencent la semaine prochaine » pendant trois ans.

Modes de défaillance à prévoir

• Dispositif perdu : si vous n’avez pas de workflow de récupération, votre « amélioration de sécurité » devient une indisponibilité.
• Dérive horaire : le TOTP échoue si l’horloge de l’hôte est mauvaise. NTP n’est pas optionnel.
• Malware d’enregistrement du presse-papiers et d’écran : le 2FA ne résout pas les endpoints compromis. Il augmente simplement la difficulté.

RBAC : conception des permissions pour des humains qui feront des erreurs

Le piège avec le RBAC de Proxmox est qu’il est à la fois puissant et trompeusement simple. Vous assignez un rôle à un utilisateur sur un chemin, et ça hérite.
Deux mois plus tard, quelqu’un se demande pourquoi un prestataire peut modifier le stockage sur tous les nœuds. Réponse : parce que vous lui avez donné des permissions sur /.

Pattern de conception RBAC qui marche

• Utiliser des groupes pour les humains. Assigner les rôles aux groupes, pas aux individus. Les individus vont et viennent ; les groupes sont la politique.
• Utiliser des chemins restreints. Assigner les opérateurs VM sur /vms ou sur des pools spécifiques, pas sur /.
• Séparer « opérer » de « changer l’infrastructure ». Démarrer/arrêter une VM n’est pas la même chose que d’ajouter du stockage ou d’ajouter un nœud au cluster.
• Limiter l’accès aux logs/audit. Les logs contiennent plus souvent des secrets que vous ne le pensez (cloud-init user-data, sortie console, tokens dans les variables d’environnement).

Rôles à définir (exemples)

• Opérateur VM : démarrer/arrêter, accès console, snapshot (éventuellement), mais pas de stockage, pas de modifications réseau.
• Opérateur Sauvegarde : lancer/surveiller les sauvegardes, restaurer vers un pool de quarantaine, mais pas modifier le réseau de production.
• Admin Stockage : configuration du stockage, réplication, tâches de purge. Pas le droit de changer l’auth utilisateur.
• Admin Cluster : rare. Peut changer l’adhésion au cluster, la config corosync, maintenance des nœuds.

Si vous ne pouvez pas expliquer un rôle en une phrase, ce n’est pas un rôle. C’est un seau.

Pare-feu pour Proxmox : hôte, datacenter, et « ne pas exposer l’UI »

Le pare-feu Proxmox peut être excellent. Il peut aussi être un placebo si vous ne comprenez pas ce qui est réellement appliqué.
La posture de sécurité ne doit jamais dépendre d’une seule case à cocher dans une GUI. Vous avez besoin d’une défense en profondeur : pare-feu de bord, isolation du réseau de gestion,
et contrôles au niveau de l’hôte.

Règles entrantes non négociables

• UI de gestion (8006) : seulement depuis le réseau admin / VPN.
• SSH (22) : seulement depuis le réseau admin / bastion.
• Trafic de cluster : uniquement entre les nœuds sur le réseau de cluster (et ne le NATez pas).
• Backends de stockage (NFS, iSCSI, Ceph, etc.) : seulement entre les participants concernés. Pas de « any to any ».

Default deny là où ça compte

Le modèle le plus sûr est un default-deny entrant sur les interfaces de gestion, avec des allow explicites. Pour les bridges VM, l’histoire dépend de votre modèle de locataires.
Si vous exécutez des charges internes et que vous faites confiance à vos politiques est-ouest, vous pouvez être moins strict. Si vous êtes multi-tenant,
supposez que vous hébergez des adversaires créatifs.

Ne confondez pas « peut pinguer » avec « est sûr »

La reachabilité ICMP vous dit presque rien. Les attaquants n’ont pas besoin de ping. Ils ont besoin d’un socket atteignable et d’une erreur.
Votre travail est de rendre le socket inaccessible depuis les endroits où il ne devrait pas exister.

Mises à jour et maintenance : patcher vite sans parier sur la disponibilité

La discipline des correctifs est un problème culturel déguisé en problème technique. La partie technique est simple : apt updates, redémarrer si nécessaire,
migrer les VMs, répéter. La partie culturelle est plus difficile : obtenir que la direction accepte que des fenêtres de maintenance planifiées coûtent moins cher
qu’une indisponibilité surprise.

Stratégie de patch production qui évolue

• Mises à jour échelonnées : ne mettez jamais à jour tous les nœuds en même temps. Un nœud d’abord, puis le reste.
• Fenêtre de maintenance : même si c’est juste une heure par semaine. Le prévisible bat l’héroïque.
• Politique de redémarrage : les mises à jour du kernel nécessitent un redémarrage. Oui, vous pouvez reporter ; non, vous ne devez pas le faire indéfiniment.
• Tester après mise à jour : quorum du cluster, montages de stockage, démarrage des VMs, sauvegardes et règles de pare-feu.

Blague 2 : « Nous ne redémarrons pas la production » est une excellente politique — jusqu’à ce que votre kernel redémarre la production pour vous au pire moment.

Correctifs de sécurité vs mises à jour de fonctionnalités

Séparez-les mentalement. Les correctifs de sécurité ont de l’urgence. Les mises à jour de fonctionnalités demandent de la prudence. En pratique sur Proxmox, vous ferez souvent les deux via apt,
donc votre processus doit inclure un contrôle de sanity rapide. Si vous êtes allergique au changement, vous êtes aussi allergique à la sécurité.

Accès distant sécurisé : VPN, bastions et hygiène SSH

La seule manière sûre de gérer Proxmox à distance est de réduire le nombre d’endroits depuis lesquels la gestion est joignable.
« Autorisé depuis Internet mais protégé par un gestionnaire de mots de passe » n’est pas une stratégie. C’est une confession.

Schémas préférés (choisissez-en un, ne improvisez pas)

1. VPN vers un réseau admin : modèle opérationnel le plus simple. Les admins s’authentifient au VPN, puis accèdent à Proxmox en privé.
2. Bastion / jump host : SSH au bastion avec une forte authentification, puis saut vers les nœuds Proxmox. Accès UI via port-forwarding ou proxy interne.
3. Réseau de gestion dédié accessible seulement via on-prem ou VPN : le modèle « entreprise ennuyeuse », et ce pour de bonnes raisons.

Règles de durcissement SSH qui ne ruinent pas la vie

• Clés seulement, pas d’authentification par mot de passe.
• Pas de login root via SSH. Utiliser sudo avec des utilisateurs audités.
• Limiter les IP sources aux sous-réseaux admin.
• Comptes admin séparés par personne ; utiliser des groupes et des règles sudo.

Accès Web UI sans ouvrir le monde

Si vous devez accéder à l’UI à distance, faites-le via VPN. Si vous ne pouvez pas, placez un reverse proxy devant avec une authentification forte et une liste d’IP autorisées
et acceptez que vous avez ajouté de la complexité. La complexité n’est pas un contrôle, mais elle peut être un contrôle compensatoire si vous l’exploitez bien.

Tâches d’audit avec commandes : quoi lancer, ce que ça signifie, décisions

Ce sont des tâches d’opérateur réelles. Lancez-les sur chaque nœud (ou centralement quand c’est noté). Pour chacune : commande, sortie d’exemple, ce que ça signifie,
et la décision que vous prenez.

Task 1: Verify Proxmox version and cluster state

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/9355359f (running kernel: 6.8.12-2-pve)
proxmox-ve/8.2.0 (running kernel: 6.8.12-2-pve)
pve-kernel-6.8/6.8.12-2

Ce que ça signifie : Vous êtes sur PVE 8.2.x avec un kernel spécifique. Si des nœuds différents rapportent des versions mineures différentes, vous êtes en territoire « ça marche jusqu’à ce que ça casse ».

Décision : Alignez les versions à travers le cluster avant de déboguer des comportements étranges ou déployer de nouvelles fonctionnalités.

Task 2: Check cluster health and quorum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 10:14:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Ce que ça signifie : Le quorum est sain. Si Quorate: No, ne changez pas la config du cluster ; vous êtes à une erreur d’une indisponibilité.

Décision : Si pas quorate, réparez d’abord le réseau entre les nœuds ; reportez les mises à jour et redémarrages.

Task 3: Confirm NTP/time sync (2FA depends on it)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:14:42 UTC
           Universal time: Sun 2025-12-28 10:14:42 UTC
                 RTC time: Sun 2025-12-28 10:14:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que ça signifie : L’horloge est synchronisée. Sinon, les échecs TOTP et les problèmes TLS apparaissent comme des fantômes.

Décision : Si non synchronisé, corrigez NTP avant de déployer ou d’exiger le 2FA.

Task 4: List users and identify local vs realm accounts

cr0x@server:~$ pveum user list
┌──────────────┬─────────┬───────────────────────┬────────────┬────────┬──────────────┐
│ userid       │ enable  │ expire                │ firstname  │ lastname│ email        │
╞══════════════╪═════════╪═══════════════════════╪════════════╪════════╪══════════════╡
│ root@pam     │ 1       │                       │            │        │              │
│ alice@pam    │ 1       │                       │ Alice      │ Ops    │              │
│ bob@pve      │ 1       │ 2026-01-31 00:00:00   │ Bob        │ Eng    │              │
└──────────────┴─────────┴───────────────┴────────────┴────────┴──────────────┘

Ce que ça signifie : Vous avez des utilisateurs dans différents realms (@pam, @pve). L’expiration existe ; utilisez-la pour les prestataires.

Décision : Désactivez ou expirez les comptes qui ne correspondent pas à une personne actuelle avec un ticket.

Task 5: Check 2FA/TOTP configuration for a user

cr0x@server:~$ pveum user get alice@pam
enable: 1
expire: 0
firstname: Alice
lastname: Ops
groups: ops
keys:
totp:
  enabled: 1
  issuer: pve
  realm: pam

Ce que ça signifie : TOTP est activé pour l’utilisateur. Si enabled: 0, il peut encore se connecter avec un mot de passe à moins que vous n’appliquiez une politique externe.

Décision : Exiger le 2FA pour les utilisateurs interactifs ; construire une méthode break-glass auditable.

Task 6: Review groups and role assignments (RBAC audit)

cr0x@server:~$ pveum group list
┌────────────┬────────┬─────────────┐
│ groupid    │ comment│ users       │
╞════════════╪════════╪═════════════╡
│ ops        │        │ alice@pam   │
│ vm-ops     │        │ bob@pve     │
└────────────┴────────┴─────────────┘

cr0x@server:~$ pveum acl list
┌────────────┬──────────┬───────────────┬───────────┐
│ path       │ type     │ ugid          │ roleid    │
╞════════════╪══════════╪═══════════════╪═══════════╡
│ /          │ group    │ ops           │ PVEAdmin  │
│ /vms       │ group    │ vm-ops        │ PVEVMAdmin│
└────────────┴──────────┴───────────────┴───────────┘

Ce que ça signifie : Le groupe ops a PVEAdmin sur /, ce qui est effectivement le « mode dieu ». C’est une sur-étendue courante.

Décision : Retirez les rôles larges de /. Donnez PVEAdmin seulement à un petit groupe d’admin cluster, et scopez les autres aux pools/chemins.

Task 7: Inspect API tokens (automation hygiene)

cr0x@server:~$ pveum user token list alice@pam
┌───────────────┬────────┬──────────────┬──────────┐
│ tokenid       │ enable │ expire       │ privsep  │
╞═══════════════╪════════╪══════════════╪══════════╡
│ backup-bot    │ 1      │ 2026-03-01   │ 1        │
└───────────────┴────────┴──────────────┴──────────┘

Ce que ça signifie : Des tokens existent et privsep est activé (bien). L’expiration est définie (mieux).

Décision : Pivotez les tokens selon un calendrier ; désactivez les tokens qui ne sont pas liés à un workflow propriétaire.

Task 8: Confirm Proxmox firewall is enabled (datacenter and node)

cr0x@server:~$ pvesh get /cluster/firewall/options
{ "enable": 1, "policy_in": "DROP", "policy_out": "ACCEPT", "log_level_in": "info" }

cr0x@server:~$ pvesh get /nodes/pve1/firewall/options
{ "enable": 1, "policy_in": "DROP", "policy_out": "ACCEPT", "log_level_in": "info" }

Ce que ça signifie : Le pare-feu est activé et la politique entrante par défaut est DROP. S’il est désactivé à l’un ou l’autre niveau, les règles peuvent ne pas s’appliquer là où vous le pensez.

Décision : Si inbound est ACCEPT sur les interfaces de gestion, changez-le et autorisez explicitement les sous-réseaux admin requis.

Task 9: Verify effective listening services and bind addresses

cr0x@server:~$ ss -lntp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:8006       0.0.0.0:*     users:(("pveproxy",pid=1520,fd=6))
LISTEN 0      4096   0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=1042,fd=3))
LISTEN 0      4096   127.0.0.1:85       0.0.0.0:*     users:(("pvedaemon",pid=1400,fd=12))

Ce que ça signifie : L’UI et SSH écoutent sur toutes les interfaces (0.0.0.0). Ce n’est pas automatiquement mauvais, mais ça augmente les enjeux : le pare-feu et l’isolation réseau doivent être corrects.

Décision : Si possible, lier la gestion à une interface admin ; sinon appliquez des allowlists entrantes strictes.

Task 10: Check actual firewall rules on the host (truth serum)

cr0x@server:~$ nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    ip saddr 10.50.0.0/24 tcp dport { 22, 8006 } accept
    ip saddr 10.50.0.0/24 icmp type echo-request accept
    counter log prefix "PVE-DROP " drop
  }
}

Ce que ça signifie : Default drop, allow explicite depuis le sous-réseau admin vers SSH/UI. C’est ce que vous voulez : lisible, minimal, applicable.

Décision : Si la politique est accept ou si les règles manquent, corrigez la config du pare-feu et revérifiez ici — pas seulement dans l’UI.

Task 11: Verify SSH config isn’t quietly permissive

cr0x@server:~$ sshd -T | egrep '^(passwordauthentication|permitrootlogin|pubkeyauthentication|allowusers|allowgroups)'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Ce que ça signifie : L’auth par mot de passe est désactivée ; le login root est désactivé ; l’auth par clé est activée. Si passwordauthentication yes, vous invitez la force brute si exposé.

Décision : Désactivez l’authentification par mot de passe et restreignez les sources ; puis testez l’accès avec une seconde session ouverte.

Task 12: Check for pending reboots after kernel/security updates

cr0x@server:~$ [ -f /var/run/reboot-required ] && echo "reboot required" || echo "no reboot required"
reboot required

Ce que ça signifie : Vous fonctionnez avec un risque de mismatch kernel/userspace et des correctifs de sécurité non appliqués nécessitant un redémarrage.

Décision : Planifiez migration et redémarrage durant la prochaine fenêtre. Ne laissez pas cela traîner pendant des mois.

Task 13: See what updates are pending (before you surprise yourself)

cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,40p'
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-manager pve-kernel-6.8 proxmox-widget-toolkit
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Ce que ça signifie : La simulation d’upgrade montre ce qui va changer. Si vous voyez corosync ou libc, planifiez des redémarrages et un séquençage prudent.

Décision : Approuvez le changement dans votre plan de maintenance ; mettez à jour un nœud test d’abord.

Task 14: Validate management UI TLS certificate state (avoid self-inflicted distrust)

cr0x@server:~$ openssl s_client -connect 127.0.0.1:8006 -servername pve1 -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = pve1
issuer=CN = pve1
notBefore=Sep  1 00:00:00 2025 GMT
notAfter=Sep  1 00:00:00 2035 GMT

Ce que ça signifie : Vous utilisez un certificat auto-signé (issuer égal subject). C’est acceptable en interne si vous le distribuez ; c’est négligent si vous exposez l’UI à l’extérieur.

Décision : Gardez l’UI interne. Si vous devez l’exposer, terminez TLS correctement avec un certificat géré et une authentification forte en frontal.

Task 15: Check auth failures in logs (attack surface reality check)

cr0x@server:~$ journalctl -u pveproxy --since "24 hours ago" | egrep -i 'authentication|login|failed' | tail -n 10
Dec 28 08:41:12 pve1 pveproxy[1520]: authentication failure; rhost=198.51.100.23 user=root@pam
Dec 28 08:41:14 pve1 pveproxy[1520]: authentication failure; rhost=198.51.100.23 user=admin@pve

Ce que ça signifie : Quelqu’un frappe à la porte. Si cette IP n’est pas votre VPN/bastion, votre plan de gestion est accessible depuis des réseaux non fiables.

Décision : Corrigez routage/pare-feu maintenant. Ensuite, envisagez d’interdire au bord ; les bannissements hôtes sont un pansement, pas une armure.

Task 16: Confirm only expected subnets can reach the UI from a remote vantage point

cr0x@server:~$ nc -vz -w2 10.10.10.11 8006
nc: connect to 10.10.10.11 port 8006 (tcp) failed: Connection refused

Ce que ça signifie : Depuis ce point, l’UI n’est pas atteignable. « Connection refused » ou « timed out » est ce que vous voulez depuis des réseaux non-admin.

Décision : Si le port est ouvert depuis des réseaux généraux, corrigez les ACL et validez à nouveau depuis plusieurs réseaux.

Playbook de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

Quand « la sécurité » casse, ça a tendance à casser l’accès. Quand l’accès casse, les gens paniquent et commencent à désactiver les contrôles.
Ce playbook est conçu pour vous empêcher de « réparer » la sécurité en la désactivant.

Scénario A : L’admin ne peut pas se connecter à l’UI

1. Vérifier la synchro horaire (échec TOTP/WebAuthn souvent dû à la dérive horloge). Lancer timedatectl. Si non synchronisé, corrigez NTP et retentez.
2. Vérifier la reachabilité depuis le bon réseau. Êtes-vous sur le VPN/VLAN admin ? Validez avec nc -vz pve1 8006.
3. Vérifier les logs pveproxy pour des erreurs d’auth vs TLS vs blocages réseau (journalctl -u pveproxy).

Scénario B : Les opérations du cluster sont lentes ou échouent après des changements de pare-feu

1. Vérifier le quorum (pvecm status). Si le quorum est instable, arrêtez de faire des changements.
2. Vérifier la connectivité inter-nœuds sur le réseau de cluster (ping insuffisant ; vérifiez les ports pertinents si vous les connaissez, et surveillez les drops).
3. Inspecter les compteurs/logs nftables (nft list ruleset, puis cherchez les compteurs de drop). Si vous voyez des drops entre IPs de nœuds, corrigez les règles allow.

Scénario C : Vous suspectez que l’UI est exposée publiquement

1. Vérifier les logs pour des IP étrangères touchant les endpoints d’auth (journalctl -u pveproxy).
2. Confirmer bind/listen (ss -lntp). Écouter sur 0.0.0.0:8006 n’est pas une preuve d’exposition, mais augmente le risque.
3. Vérifier les contrôles de bord : un point d’observation non-admin peut-il atteindre 8006 ? Si oui, verrouillez au bord et sur l’hôte.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: 2FA codes « ne fonctionnent jamais » pour plusieurs utilisateurs

Cause racine : Dérive horaire sur le nœud (ou clients), NTP désactivé, ou problèmes d’horloge de l’hôte de virtualisation.

Correction : Activer NTP, vérifier que timedatectl affiche synchronized, puis ré-enregistrer si nécessaire. Ne réduisez pas les exigences d’auth pour « réparer » ceci.

2) Symptom: Un opérateur peut supprimer du stockage ou changer le réseau « par accident »

Cause racine : Rôle RBAC assigné sur / ou utilisation de rôles intégrés trop larges par commodité.

Correction : Créer des groupes et ACLs scopiés sur des chemins/pools spécifiques ; réserver PVEAdmin pour un petit groupe admin cluster.

3) Symptom: Pare-feu activé, mais le port 8006 est toujours joignable partout

Cause racine : Pare-feu activé au datacenter mais désactivé au nœud, ou règles appliquées sur la mauvaise interface, ou un pare-feu/NAT en amont contournant les attentes.

Correction : Vérifier les options datacenter et nœud via pvesh. Confirmer les règles effectives via nft list ruleset. Corriger les ACLs en bordure.

4) Symptom: Le cluster devient instable après « resserrage des règles de pare-feu »

Cause racine : Blocage du trafic corosync/knet entre nœuds, ou mélange des réseaux mgmt et cluster avec des règles asymétriques.

Correction : Autoriser explicitement le trafic inter-nœuds sur l’interface de cluster. Valider la stabilité du quorum avant et après les changements.

5) Symptom: Après des mises à jour, les VMs migrent mais les performances chutent

Cause racine : Mismatch kernel/driver, paramètres d’offload NIC changés, ou chemin de stockage impacté ; possible qu’un nœud soit désormais « différent ».

Correction : Aligner les versions sur tous les nœuds. Vérifier dmesg, versions des pilotes NIC, et santé du stockage. Procéder progressivement la prochaine fois.

6) Symptom: Accès SSH perdu après durcissement

Cause racine : Désactivation de l’auth par mot de passe avant distribution des clés, ou IPs restreintes incorrectes, ou blocage par le pare-feu.

Correction : Garder une console root active (iLO/IPMI/KVM) avant les changements SSH. Appliquer les allowlists prudemment et tester avec une seconde session ouverte.

7) Symptom: Sauvegardes réussissent mais restaurations échouent pendant un incident

Cause racine : Les restaurations n’ont pas été testées ; permissions/chemins du stockage de sauvegarde changés ; clés de chiffrement indisponibles ; ou cibles de restauration bloquées par le RBAC.

Correction : Tester les restaurations trimestriellement (au minimum). Stocker les clés dans un système contrôlé. S’assurer que les opérateurs de sauvegarde peuvent restaurer vers un environnement de quarantaine.

Trois mini-récits d’entreprise venus du terrain

Histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un cluster Proxmox trois nœuds pour des services internes : runners CI, quelques bases de données, et un « jump box » temporaire
qui est devenu permanent parce que tout ce qui est temporaire devient permanent. Ils avaient un pare-feu nouvelle génération en périphérie et croyaient que l’UI de gestion
« n’était pas exposée ». Personne ne pouvait pointer une règle, mais tout le monde pointait une croyance.

Un audit a commencé après qu’un fournisseur ait demandé une allowlist IP. L’équipe sécurité a fait un scan depuis l’extérieur et a trouvé le port 8006 ouvert.
Pas « filtré ». Ouvert. Le pare-feu de bord avait une règle NAT pour la commodité pendant une migration à distance des mois plus tôt, et personne ne l’avait supprimée.
L’UI était accessible avec seulement une authentification par mot de passe pour quelques comptes legacy.

La timeline de l’événement n’a pas été dramatique. Un bot a frappé l’UI, essayé des noms d’utilisateurs courants, trouvé un compte utilisant un ancien pattern de mot de passe, et s’est connecté.
Une fois à l’intérieur, il n’a pas eu besoin d’exploits kernel. Il a utilisé l’UI comme un admin : téléchargé des sauvegardes de VM, monté des disques, et créé un nouvel utilisateur privilégié.
La « compromission de l’hyperviseur » était en fait une « compromission du plan de gestion ».

La récupération a été pénible parce que le modèle mental de l’équipe était faux. Ils ont continué d’investiguer des vulnérabilités VM tandis que l’attaquant opérait le plan de contrôle.
La correction a aussi été ennuyeuse : retirer l’exposition publique, appliquer le 2FA, pivoter les credentials, et ajouter une checklist de contrôle de changement pour les règles NAT.
Ils ont ensuite admis la vraie cause racine : avoir supposé que la configuration du pare-feu correspondait au schéma d’architecture.

Histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait « moins de friction » pour les opérateurs. Ils ont centralisé l’accès en plaçant l’UI Proxmox derrière un reverse proxy interne,
puis ont ouvert le proxy à un réseau d’entreprise plus large pour que l’on-call puisse y accéder depuis n’importe où sur le VPN d’entreprise. Ils ont aussi ajouté un flux type SSO
pour la commodité. Ça a marché. Jusqu’à ce que ça ne marche plus.

Le proxy est devenu un point unique de défaillance et un point unique de compromission. Lors d’une mise à jour routine du proxy, les paramètres TLS ont changé et certains clients
ont commencé à échouer. Les opérateurs, sous pression, ont commencé à contourner le proxy en exposant directement 8006 temporairement « juste pour ce soir ».
Cet état temporaire a vécu assez longtemps pour apparaître dans les logs comme un flux constant de tentatives d’auth depuis des réseaux qui n’étaient pas censés toucher la gestion.

Pendant ce temps, le proxy obscurcissait les IPs sources à moins d’une configuration soignée, ce qui compliquait l’audit des connexions suspectes. L’équipe avait en fait échangé
une frontière de sécurité claire contre une couche de commodité qui exigeait sa propre excellence opérationnelle. Ils n’avaient pas prévu les ressources pour cette excellence.

La correction finale a été de simplifier : accès UI uniquement via un segment VPN admin dédié ; pas d’accès large depuis le réseau d’entreprise. Ils ont gardé le proxy en interne pour quelques
workflows, mais l’ont retiré en tant que « fonctionnalité de sécurité ». La leçon était crue : les couches de commodité sont des systèmes, et les systèmes ont besoin de propriétaires.

Histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une petite équipe exécutant Proxmox pour un produit SaaS avait une habitude presque vieille école : une fenêtre de maintenance hebdomadaire avec un runbook écrit.
Chaque mercredi, ils patchaient un nœud, migraient les charges, redémarraient si nécessaire, puis passaient au nœud suivant. Ils notaient ce qui avait changé et ce qu’ils avaient observé.
Ce n’était pas glamour. C’était fiable.

Un jour, ils ont appliqué des mises à jour et ont remarqué que pvecm status affichait des avertissements de quorum intermittents pendant les migrations. Parce qu’ils vérifiaient
toujours la santé du cluster après chaque nœud, ils l’ont détecté tôt. La cause était un port de switch qui faisait du flapping sur le réseau de cluster — non lié au patch, mais révélé par la routine.

Ils ont mis la livraison en pause, corrigé le problème physique, et repris. Aucun impact client. L’ingénieur on-call a même dormi.
Le gain sécurité n’était pas juste « ils ont patché ». C’était que leur processus rendait les anomalies visibles avant qu’elles ne deviennent des incidents.

Les pratiques ennuyeuses n’ont pas le droit aux applaudissements budgétaires, mais elles évitent les réunions budgétaires avec des mines déconfites.

FAQ

1) Dois‑je exposer un jour le port Proxmox 8006 sur Internet si j’utilise le 2FA ?

Non. Le 2FA réduit le risque de compromission de compte ; il ne réduit pas le risque d’exposition du service. Gardez 8006 sur un réseau admin ou derrière un VPN/bastion.

2) Le RBAC Proxmox suffit‑il, ou ai‑je encore besoin de contrôles utilisateurs Linux ?

Vous avez besoin des deux. Le RBAC gouverne les actions API/UI Proxmox. Les utilisateurs Linux/SSH gouvernent l’accès hôte. Traitez l’accès shell de l’hôte comme un privilège supérieur à l’accès UI seul.

3) Quelle est la configuration minimale viable d’« accès distant sécurisé » ?

Un VPN vers un sous‑réseau admin, avec des règles de pare‑feu autorisant 22 et 8006 seulement depuis ce sous‑réseau, plus 2FA pour les logins UI et clés SSH pour le shell.

4) Comment gérer l’accès break‑glass quand le 2FA est obligatoire ?

Créez un compte break‑glass dédié avec des contrôles forts : identifiants stockés hors ligne, allowlist IP restreinte, usage surveillé, et procédure documentée.
Utilisez‑le seulement pour récupérer l’accès, puis pivotez‑le.

5) Les tokens API sont‑ils plus sûrs que les mots de passe ?

Généralement oui, car ils peuvent être scindés, pivotés et révoqués sans perturber un compte humain. Mais traitez les tokens comme des secrets : protégez‑les, journalisez leur usage,
et expirez‑les.

6) Ai‑je besoin de fail2ban sur Proxmox ?

Si votre plan de gestion est correctement isolé, fail2ban est optionnel. Si vous suspectez une exposition, fail2ban peut réduire le bruit, mais ce n’est pas un substitut à la correction de l’exposition.

7) Quelle politique de pare‑feu devrais‑je utiliser : DROP ou REJECT ?

Pour les interfaces de gestion, préférez DROP pour réduire le signal. Pour la commodité de dépannage interne, REJECT peut être utile. Choisissez en connaissance de cause et documentez‑le.

8) À quelle fréquence dois‑je patcher les nœuds Proxmox ?

Hebdomadaire ou bimensuel est une cadence saine pour la plupart des environnements, avec la possibilité d’accélérer pour des avis de sécurité urgents. La clé est la cohérence et l’étagement.

9) Si j’isole la gestion sur un VLAN, ai‑je encore besoin du pare‑feu Proxmox ?

Oui. Les VLAN réduisent l’exposition ; les pare‑feu réduisent le rayon d’impact quand les frontières VLAN échouent, sont mal configurées, ou quand un système interne est compromis.

10) Quel est le plus grand « risque silencieux » en sécurité Proxmox ?

Les permissions trop larges qui restent. La plupart des organisations ne se font pas pirater par un génie ; elles sont blessées par la commodité d’hier.

Étapes suivantes à exécuter cette semaine

1. Vérifier que la gestion n’est pas exposée : depuis un réseau non‑admin, confirmer que 8006 et 22 sont injoignables. Si joignables, corriger les règles en bord immédiatement.
2. Activer le 2FA pour chaque humain. Corriger NTP d’abord. Créer un flux break‑glass documenté.
3. Sprint de nettoyage RBAC : lister les ACLs, retirer PVEAdmin de / sauf pour un petit groupe admin, et scoper tout le reste.
4. Vérifier l’efficacité du pare‑feu : vérifier la configuration via pvesh et la réalité via nft list ruleset.
5. Patch avec staging : simuler les mises à jour, mettre à jour un nœud, vérifier le quorum et les workflows centraux, puis poursuivre.
6. Durcir SSH prudemment : clés seulement, pas de login root, sources restreintes ; garder l’accès console disponible lors des changements.
7. Écrire les deux runbooks nécessaires : « appareil 2FA perdu » et « compte admin compromis ». Les incidents n’attendent pas la documentation.

L’objectif n’est pas de construire une forteresse impénétrable. C’est de rendre l’accès de gestion Proxmox volontairement rare, les permissions volontairement étroites,
et les changements volontairement routiniers. Le reste, c’est juste du Linux.