Sécurité Proxmox : les 5 erreurs d’accès qui transforment votre labo en brèche

Quelques faits (et un peu d’histoire) qui expliquent pourquoi l’accès échoue

Les erreurs de sécurité autour du contrôle d’accès Proxmox ne sont pas aléatoires. Ce sont des habitudes répétables — beaucoup héritées d’anciennes ères d’infrastructure, de la mentalité « juste pour le labo », ou d’équipes qui ont appris l’administration Linux avant que la modélisation des menaces ne devienne une étape systématique avant l’appel d’incident.

• Fait 1 : L’interface web de Proxmox VE (pveproxy) était historiquement configurée par défaut pour être accessible sur TCP/8006 depuis n’importe où l’hôte est joignable. Pratique en labo, téméraire sur un réseau routé.
• Fait 2 : Le modèle de permissions PVE n’est pas un détail : c’est du RBAC avec rôles, utilisateurs, groupes et ACL. Beaucoup de brèches commencent en l’ignorant et en exécutant tout en tant que root@pam.
• Fait 3 : Le concept de « plan de gestion » est devenu courant parce que les attaquants adorent les plans de contrôle. Contrôler l’hyperviseur vaut mieux que compromettre un invité : un identifiant peut ouvrir beaucoup de VM.
• Fait 4 : L’authentification à deux facteurs est passée du grand public aux opérations quand la réutilisation de mots de passe et le phishing ont cessé d’être « rares ». Les portails d’administration sans 2FA sont maintenant une anomalie — pour les attaquants, une aubaine.
• Fait 5 : La prolifération des clés SSH est la version moderne de laisser une clé de secours sous le paillasson. Les clés survivent souvent aux employés, aux ordinateurs portables et aux VM pour lesquelles elles ont été créées.
• Fait 6 : Les VLANs ont été popularisés pour réduire les domaines de broadcast et segmenter les réseaux ; ils ne constituent pas, à eux seuls, une frontière de sécurité si vous routez librement entre eux avec un pare-feu permissif.
• Fait 7 : Les systèmes en cluster modifient le rayon d’impact. Un nœud compromis est souvent un tremplin vers une perturbation du cluster entier, surtout quand la confiance inter-nœuds n’est pas restreinte.
• Fait 8 : « Les sauvegardes sont de la sécurité » est à moitié vrai. Les sauvegardes sont aussi une voie d’accès à haute valeur : si un attaquant peut les supprimer ou les chiffrer, votre plan de reprise devient de l’art interprétatif.

Une citation pour garder vos priorités droites. C’est une idée paraphrasée de Gene Kim (auteur DevOps/opérations) : Améliorer la fiabilité consiste surtout à améliorer le système, pas les individus héroïques.
Appliquez cela au contrôle d’accès : cessez de compter sur des « admins prudents » et construisez des garde-fous.

Erreur n°1 : Exposer l’UI et l’API Proxmox comme un blog amateur

Si TCP/8006 est joignable depuis des réseaux que vous ne contrôlez pas entièrement, vous jouez à la roulette. Oui, Proxmox utilise TLS. Non, ce n’est pas la même chose que « sûr sur Internet ». L’UI est un plan de contrôle d’administration.
L’attaquant n’a pas besoin d’exploiter un bug hyperviseur exotique. Il lui suffit que vous vous authentifiiez une fois au mauvais endroit, que vous réutilisiez un mot de passe, ou qu’un compte reste activé.

La plus grande idée fausse : « C’est juste mon labo. » Les labos deviennent prod comme les tout-petits deviennent ados : vous détournez le regard cinq minutes et soudain il a des opinions et un budget.

Ce que « exposé » signifie vraiment

Exposé ce n’est pas seulement « IP publique ». C’est « joignable depuis tout endroit auquel vous ne donneriez pas en confiance un câble de console physique ».
Cela inclut : un Wi‑Fi d’entreprise non isolé, le sous-réseau VPN « temporaire » partagé avec des prestataires, votre VLAN jeux parce que vous étiez pressé, ou un reverse proxy qui termine le TLS et relaie /api2 parce que c’était sympa.

Que faire à la place

• Placez la gestion PVE sur un réseau de gestion dédié (interface séparée ou VLAN) avec des règles d’ingress strictes.
• Autorisez l’UI/l’API uniquement depuis un jump host admin ou un sous-réseau VPN en qui vous avez vraiment confiance.
• Si vous devez utiliser un reverse proxy, traitez-le comme un composant critique de sécurité (auth, MFA, durcissement, journalisation). Sinon, ne le faites pas.

Blague n°1 : Mettre l’UI Proxmox sur Internet ouvert, c’est comme laisser la clé de votre maison sous le paillasson. Ça marche très bien jusqu’à ce que quelqu’un d’autre lise le même blog sur la sécurité domestique.

Erreur n°2 : Utiliser root comme conducteur quotidien

Root n’est pas une identité. Root est une capacité. Quand vous vous connectez à l’UI en tant que root@pam pour des opérations courantes, vous fusionnez « administration » et « superutilisateur partout » en un seul domaine de défaillance.
C’est ainsi que de petites erreurs deviennent de grandes, et comment le phishing devient le contrôle de l’infrastructure.

Les modes de défaillance

• Phishing/réutilisation d’identifiants : un compte = tout.
• Ambiguïté d’audit : « root l’a fait » n’est pas une piste d’audit ; c’est une hausse d’épaules en forme de log.
• Erreur opérationnelle : vous vouliez redémarrer une VM ; vous avez supprimé une configuration de stockage. Root a rendu ça rapide.

Faites ceci : comptes admin + frontières de privilèges

Créez des comptes admin nommés, utilisez des rôles RBAC, et réservez root pour le break-glass. Si vous avez besoin d’actions de niveau root, accordez-les délibérément — de préférence à un rôle, pas à un compte humain durable.

Si vous pensez « mais c’est juste moi », vous préparez quand même l’avenir. Le vous futur compte comme une personne différente. Le vous passé certainement aussi.

Erreur n°3 : Utiliser « un compte admin » au lieu du RBAC et de la séparation

Les permissions Proxmox sont puissantes et légèrement sous-utilisées. Le anti-pattern commun est de gérer une petite organisation (ou un labo) comme un poste de travail mono‑utilisateur : un utilisateur admin, des identifiants partagés, et des accès qui débordent sur les nœuds, pools et stockages.

Ce qu’il faut séparer (séparation minimale viable)

• Admins humains vs automatisation (tokens API pour les machines, MFA pour les humains).
• Gestion du cluster vs gestion des VM (tout le monde ne devrait pas ajouter du stockage ou modifier le réseau).
• Opérateurs de sauvegarde vs opérateurs VM (les droits de restauration sont puissants ; les droits de suppression sont dangereux).
• Workloads locataires même en homelab — surtout si vous hébergez des services « amis et famille ».

Ce que le RBAC vous apporte

Le principe du moindre privilège n’est pas de la paranoïa. Il s’agit de minimiser le rayon d’impact d’une défaillance normale :
un laptop compromis, un token poussé dans un repo, un compte prestataire laissé activé, ou un stagiaire qui découvre ce que « Datacenter » signifie dans l’UI.

Erreur n°4 : Tokens, clés et secrets sans cycle de vie

Les labos aiment les secrets statiques. Les environnements d’entreprise aussi, mais font semblant de ne pas le faire. Le schéma de brèche est constant : un token est créé pour un script, le script marche, le token est oublié, et plus tard il devient la porte d’entrée la plus propre.

Délinquants typiques

• Tokens API avec permissions larges et sans processus d’expiration.
• Clés SSH copiées sur plusieurs portables d’admins, toutes autorisées partout.
• Identifiants de sauvegarde capables aussi de supprimer les sauvegardes.
• Basic auth de reverse proxy stockée en clair dans la gestion de configuration sans rotation.

Mieux : penser en cycle de vie

Chaque identifiant devrait avoir un propriétaire, une portée, une méthode de stockage et une histoire de rotation. Si vous ne pouvez pas répondre à ces quatre questions, ce n’est pas un identifiant. C’est un incident futur.

Blague n°2 : Les tokens expirés sont comme le lait périmé : désagréable, mais au moins on le remarque. Les tokens sans expiration sont comme du lait qui a l’air correct jusqu’au moment où ça ne l’est plus.

Erreur n°5 : Confondre « a un pare‑feu » et « est segmenté »

Un hôte Proxmox peut avoir des règles de pare‑feu et rester largement ouvert en pratique. Pourquoi ? Parce que la segmentation est une décision d’architecture, pas une case cochée.
Si votre interface de gestion, le trafic VM, le trafic de stockage et le trafic de cluster partagent tous le même espace L2/L3, vous avez construit un environnement où la compromission se propage naturellement.

À quoi devrait ressembler la segmentation

• Réseau de gestion : UI/API/SSH. Seuls les appareils admin ou les jump hosts peuvent y accéder.
• Réseau de cluster : trafic corosync. Adhésion stricte. Préférez un VLAN isolé ou des NICs dédiés.
• Réseau de stockage : NFS/iSCSI/Ceph. Seulement les endpoints de stockage et les hôtes, pas des VM au hasard.
• Réseaux VM : plusieurs VLANs/bridges basés sur des zones de confiance.

Pourquoi c’est important pour le contrôle d’accès

Les attaquants préfèrent le mouvement latéral plus que l’accès initial. Si une VM compromise peut parler au plan de gestion de l’hôte, ce n’est pas « une compromission de VM ». C’est l’étape un.
Réduisez le rayon d’impact assez pour que votre réponse à incident ait une chance d’être ennuyeuse.

Playbook diagnostic rapide : que vérifier d’abord, ensuite, puis

Quand quelque chose semble « anormal » dans la sécurité d’accès — invites de connexion inattendues, comportement étrange de l’UI, nœuds qui fluctuent, sauvegardes qui échouent — ne paniquez pas. Exécutez une triage rapide avec un ordre stable d’opérations.
Ce playbook est optimisé pour attraper rapidement les défaillances courantes et à fort impact.

Premier : confirmer l’exposition et les points d’entrée

• TCP/8006 est-il joignable depuis des endroits où il ne devrait pas l’être ?
• SSH est‑il joignable sur l’interface de gestion depuis des sous‑réseaux non fiables ?
• Y a‑t‑il des reverse proxies ou des redirections de ports sur le chemin ?

Second : valider les contrôles d’identité

• Les admins utilisent‑ils des comptes nommés ou root ?
• La 2FA est‑elle appliquée aux admins humains ?
• Des tokens existent‑ils pour l’automatisation, et sont‑ils correctement scindés ?

Troisième : inspecter les logs pour des preuves, pas des impressions

• Tentatives de connexion récentes et échecs (UI et SSH).
• Modifications de permissions, nouveaux utilisateurs, nouveaux tokens.
• Modifications de pare‑feu, changements d’interfaces réseau.

Quatrième : vérifier la segmentation et les frontières de confiance

• Les VM peuvent‑elles atteindre les IPs de gestion ?
• Des VLANs non admin peuvent‑ils atteindre corosync ou les réseaux de stockage ?
• Les endpoints de sauvegarde sont‑ils joignables depuis les réseaux locataires ?

Si vous trouvez un problème sérieux (UI exposée, SSH root ouvert, pas de 2FA), arrêtez et corrigez-le avant de continuer. « Je vais finir de tout vérifier » est la façon dont les brèches gagnent un chapitre supplémentaire.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : Pic de tentatives de connexion dans les logs, UI lente

Cause racine : Web UI exposée à un large réseau ; credential stuffing automatisé ou scans.

Correction : Restreindre TCP/8006 avec pare‑feu hôte et ACL en amont. Déplacer la gestion vers un sous‑réseau dédié. Ajouter la 2FA et la limitation de débit via un chemin d’accès admin approprié (VPN/jump host).

2) Symptom : « root@pam » utilisé pour tout, aucune traçabilité

Cause racine : culture de commodité, pas de conception RBAC, pas de politique de break‑glass.

Correction : Créer des utilisateurs admin nommés, imposer la 2FA, désactiver l’authentification par mot de passe pour SSH root, et réserver root à la console/break‑glass uniquement.

3) Symptom : Les scripts d’automatisation fonctionnent… jusqu’à la fuite d’un token

Cause racine : Tokens API longue durée stockés en clair, permissions trop larges.

Correction : Créer des tokens API scellés par workload, les stocker dans un gestionnaire de secrets (ou au moins en fichiers lisibles par root), les faire tourner régulièrement, et retirer des privilèges comme Sys.Modify sauf si nécessaire.

4) Symptom : Une compromission VM se transforme en compromission hôte

Cause racine : Réseau plat ; les VM peuvent atteindre le plan de gestion ou les endpoints de stockage ; politiques de pare‑feu permissives.

Correction : Séparer les réseaux, bloquer par défaut VM→gestion, et autoriser explicitement uniquement les flux est‑ouest requis.

5) Symptom : Les sauvegardes disparaissent ou deviennent inutilisables après un incident

Cause racine : Les identifiants de sauvegarde permettent la suppression, le stockage de sauvegarde est joignable depuis partout, pas d’immuabilité/retention forcée.

Correction : Séparer le rôle d’opérateur de sauvegarde, restreindre la joignabilité réseau, appliquer des règles de rétention et empêcher la suppression des sauvegardes par défaut.

6) Symptom : Instabilité du cluster après des changements de « durcissement »

Cause racine : Règles de pare‑feu appliquées sans comprendre corosync/trafic de cluster ; ports requis ou chemins multicast/unicast bloqués.

Correction : Appliquer les changements de façon incrémentale, valider d’abord les communications du cluster, garder un accès hors bande, et tester sur un nœud avant un déploiement global.

Tâches pratiques : commandes, sortie attendue et décisions

Ce sont des tâches pratiques que vous pouvez exécuter sur un nœud Proxmox (ou sur votre jump host) pour répondre à une question : « Est‑ce sûr ? » et « Que faire ensuite ? »
Les commandes supposent un hôte Proxmox VE basé sur Debian. Adaptez les noms d’interface et les sous‑réseaux à votre environnement.

Task 1: Confirm what is listening on the host (and where)

cr0x@server:~$ sudo ss -lntp
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=1234,fd=6))
LISTEN 0      128    0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=987,fd=3))
LISTEN 0      4096   127.0.0.1:85       0.0.0.0:*     users:(("pvedaemon",pid=1100,fd=10))

Ce que la sortie signifie : pveproxy est lié à 0.0.0.0:8006, donc il est joignable sur toutes les interfaces qui routent vers l’hôte.

Décision : Si l’hôte a une interface non destinée à la gestion, restreignez l’accès via des règles de pare‑feu ou liez les services de gestion à une IP de gestion via la conception réseau (préféré : joignabilité uniquement depuis la gestion).

Task 2: Validate host firewall status in Proxmox

cr0x@server:~$ sudo pve-firewall status
Status: enabled/running

Ce que la sortie signifie : Le cadre de pare‑feu PVE est actif.

Décision : « Activé » n’est pas synonyme de « configuré ». Continuez : vérifiez les politiques et règles. Si c’est désactivé, activez‑le et assurez‑vous d’avoir un accès hors‑bande avant de durcir les règles.

Task 3: Inspect the effective firewall rules (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 ip saddr 10.10.10.0/24 accept
    tcp dport 8006 ip saddr 10.10.10.0/24 accept
    counter drop
  }
}

Ce que la sortie signifie : Drop par défaut avec autorisations explicites pour SSH et 8006 seulement depuis 10.10.10.0/24. C’est la forme souhaitée.

Décision : Si vous voyez policy accept ou des autorisations larges (comme ip saddr 0.0.0.0/0), resserrez. Si des règles manquent, implémentez‑les sur l’hôte et le pare‑feu en amont.

Task 4: Test reachability from a non-admin network (external validation)

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

Ce que la sortie signifie : Depuis le point de test, le service n’est pas joignable (refusé ou timeout sont acceptables selon la politique).

Décision : Si ça se connecte, vous avez un problème d’exposition. Corrigez les ACL réseau/pare‑feu avant d’« ajouter juste la 2FA ». Défense en profondeur, pas en sensation.

Task 5: Verify which users exist in Proxmox and their realms

cr0x@server:~$ sudo pveum user list
Userid             Enable Expire Firstname Lastname Email Comment
root@pam           1             -        -        -     -
alice@pve          1             Alice    Admin    -     human admin
ci-bot@pve         1             -        -        -     automation

Ce que la sortie signifie : Des utilisateurs existent sur plusieurs realms (PAM, PVE). Cela vous indique si vous vivez encore la vie root@pam uniquement.

Décision : Si root est la seule identité admin activée, créez des admins nommés et verrouillez l’usage de root. Si l’automatisation utilise un compte humain, migrez‑la vers un token.

Task 6: List API tokens (find the forgotten doors)

cr0x@server:~$ sudo pveum user token list ci-bot@pve
Tokenid     Privsep  Expire Comment
deploy      1        0      used by pipeline
oldscript   0        0      legacy

Ce que la sortie signifie : Des tokens existent ; Expire 0 signifie typiquement « pas d’expiration ». Privsep 1 est mieux que 0 car il sépare les permissions du token de celles de l’utilisateur.

Décision : Supprimez les tokens « legacy ». Faites tourner les actifs. Assurez‑vous que la séparation des privilèges est activée et que les ACLs sont scoped par token.

Task 7: Audit ACLs (who can do what, where)

cr0x@server:~$ sudo pveum acl list
Path            Userid         Roleid
/               alice@pve      Administrator
/vms/100        ci-bot@pve     PVEVMAdmin

Ce que la sortie signifie : alice@pve a l’administration au niveau datacenter (gros). ci-bot@pve est scellé sur un chemin VM (bon pattern).

Décision : Retirez les rôles larges de l’automatisation. Rendez la portée explicite (par VM, pool ou chemin de ressource). Envisagez de scinder l’admin datacenter en rôles séparés pour stockage/réseau/cluster.

Task 8: Check SSH root login settings

cr0x@server:~$ sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication'
permitrootlogin prohibit-password
passwordauthentication no
pubkeyauthentication yes

Ce que la sortie signifie : Root peut se connecter via clés seulement ; les mots de passe sont désactivés (bonne base). Idéalement, le login root serait no sauf si vous avez besoin d’un break‑glass via console.

Décision : Si passwordauthentication yes ou permitrootlogin yes, corrigez maintenant. Si vous gardez la connexion root par clé, limitez et gérez ces clés.

Task 9: Find which keys are authorized for root (key sprawl check)

cr0x@server:~$ sudo wc -l /root/.ssh/authorized_keys
12 /root/.ssh/authorized_keys

Ce que la sortie signifie : Douze clés. Ce n’est pas automatiquement faux, mais rarement correct dans un petit environnement.

Décision : Supprimez les clés obsolètes, imposez des comptes nommés, et éloignez‑vous du modèle « root a les clés de tout le monde ». Envisagez un jump host avec accès à courte durée.

Task 10: Inspect recent authentication events (SSH and PAM)

cr0x@server:~$ sudo journalctl -u ssh -S "24 hours ago" | tail -n 20
Feb 04 08:11:32 pve1 sshd[22101]: Failed publickey for root from 203.0.113.50 port 51234 ssh2: RSA SHA256:...
Feb 04 08:11:37 pve1 sshd[22104]: Failed password for invalid user admin from 203.0.113.50 port 51261 ssh2
Feb 04 08:14:02 pve1 sshd[22210]: Accepted publickey for alice from 10.10.10.25 port 49152 ssh2: ED25519 SHA256:...

Ce que la sortie signifie : Vous observez des tentatives de scan depuis une IP publique et une connexion réussie depuis le sous‑réseau de gestion.

Décision : Si vous voyez des scans publics répétés, vérifiez les chemins d’exposition. Si des connexions réussies viennent de sous‑réseaux inattendus, traitez‑les comme un incident potentiel et resserrez l’ingress immédiatement.

Task 11: Inspect Proxmox task logs for admin actions

cr0x@server:~$ sudo tail -n 25 /var/log/pve/tasks/index
UPID:pve1:0002A1B3:0F3A2B1C:65C0F5E2:vzstart:100:alice@pve:
UPID:pve1:0002A1D8:0F3A2C90:65C0F61A:aclmod:/:root@pam:
UPID:pve1:0002A1F2:0F3A2D10:65C0F640:useradd::root@pam:

Ce que la sortie signifie : Des changements administratifs ont été effectués par root@pam. C’est un signal rouge pour la traçabilité et souvent pour un comportement de session console partagée.

Décision : Migrez les opérations admin courantes vers des comptes nommés. Imposer une règle stricte : les changements root nécessitent un ticket/notes, même en labo.

Task 12: Validate corosync network configuration and membership

cr0x@server:~$ sudo pvecm status
Cluster information
-------------------
Name:             labcluster
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Feb 04 09:02:11 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Ce que la sortie signifie : Le cluster est sain et utilise une authentification sécurisée. C’est votre base avant de toucher au pare‑feu autour du trafic de cluster.

Décision : Si le quorum est instable ou des nœuds manquent, ne procédez pas à des changements de pare‑feu agressifs. Réparez le réseau du cluster d’abord, sinon vous « sécuriserez » le cluster jusqu’à l’indisponibilité.

Task 13: Check what interfaces carry management and VM traffic

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.10/24
vmbr0            UP             192.168.50.10/24
vmbr1            UP             172.16.20.10/24

Ce que la sortie signifie : Vous avez des réseaux distincts. Si eno1 (gestion) est séparé des bridges VM, vous êtes sur la bonne voie.

Décision : Si la gestion et les VM partagent le même bridge, refondez le design. Si vous ne pouvez pas redessiner aujourd’hui, bloquez les sous‑réseaux VM d’atteindre 8006/22 en mesure d’urgence.

Task 14: Verify that VMs can’t reach the host management plane (quick test from host)

cr0x@server:~$ sudo tcpdump -ni eno1 tcp port 8006 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured

Ce que la sortie signifie : Aucune capture de trafic vers 8006 sur la NIC de gestion pendant la fenêtre. Ce n’est pas une preuve définitive, mais un signal utile.

Décision : Si vous voyez des IPs du sous‑réseau VM frapper 8006, vous avez un échec de segmentation. Implémentez un blocage au pare‑feu hôte et à la frontière L3.

Task 15: Identify whether backups are reachable from untrusted networks

cr0x@server:~$ sudo ss -lntp | egrep '(:8007|:9022|:22|:2049)'
LISTEN 0      4096   0.0.0.0:8007   0.0.0.0:* users:(("proxmox-backup-proxy",pid=1444,fd=10))
LISTEN 0      128    0.0.0.0:9022   0.0.0.0:* users:(("proxmox-backup-api",pid=1401,fd=9))

Ce que la sortie signifie : Les services Proxmox Backup Server écoutent sur toutes les interfaces.

Décision : Restreignez ces ports aux sous‑réseaux clients/admins de sauvegarde seulement. Les sauvegardes font partie de votre périmètre de sécurité, pas d’une quête annexe.

Task 16: Check time sync status (access security’s quiet dependency)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-04 09:10:22 UTC
           Universal time: Tue 2026-02-04 09:10:22 UTC
                 RTC time: Tue 2026-02-04 09:10:22
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que la sortie signifie : L’horloge est synchronisée. Cela compte pour la corrélation des logs, la validité des tokens et les timelines d’incident.

Décision : Si l’heure est décalée ou que NTP est inactif, corrigez‑le avant d’essayer d’interpréter « quand cette connexion a eu lieu ? » entre les nœuds.

Trois mini-récits d’entreprises du département « ça s’est passé »

Mini-récit 1 (mauvaise hypothèse) : « L’UI n’est pas publique, elle est derrière du NAT »

Une société de taille moyenne exploitait un cluster Proxmox pour des services internes. L’équipe était compétente, occupée, et aimait la phrase « c’est derrière du NAT ». L’interface de gestion vivait sur un sous‑réseau serveur « interne uniquement ».

Puis l’entreprise s’est agrandie. Un nouveau VPN site‑à‑site a été mis en service, et un réseau partenaire a été ajouté pour simplifier un projet commun. Le routage est devenu plus simple. La sécurité est devenue plus floue.

Personne n’a mis à jour le modèle de menace parce que personne n’en avait un écrit. TCP/8006 de Proxmox est devenu joignable depuis un sous‑réseau partenaire. Pas intentionnellement. Juste un effet secondaire du « faisons fonctionner le réseau ».
Une semaine plus tard, leurs logs montraient un filet d’échecs de connexion depuis une IP du réseau partenaire. Ce n’était pas l’Internet, donc ça n’a pas déclenché d’alarme.

L’accès initial n’était pas magique. Un admin avait utilisé un mot de passe partagé (oui, encore) pour « commodité temporaire ». Ce mot de passe est apparu dans une fuite d’identifiants liée à un service complètement différent.
Une fois l’attaquant dans l’UI, il n’a pas eu besoin d’exploits kernel. Il a créé un nouvel utilisateur privilégié, monté un ISO, et utilisé une VM invitée comme point de mise en scène.

Le postmortem ne portait pas sur des bugs Proxmox. Il portait sur la mauvaise hypothèse que « routes internes = routes de confiance ». La correction a été ennuyeuse et décisive :
la gestion a été déplacée sur un sous‑réseau dédié, UI/API autorisés uniquement depuis le jump host, la 2FA est devenue obligatoire, et les identifiants partagés sont devenus une faute professionnelle pour les scripts et un enseignement pour les humains.

Mini-récit 2 (optimisation qui s’est retournée) : « Mettons l’UI derrière un reverse proxy »

Une autre organisation voulait « une seule interface ». Elle avait déjà une stack de reverse proxy pour les apps, avec certificats automatisés et beaux tableaux de bord.
Quelqu’un a proposé d’y mettre Proxmox aussi. URLs propres, TLS centralisé, modèles d’accès cohérents. Tout le monde aime la cohérence, jusqu’à ce que ce soit uniformément faux.

Le proxy était joignable depuis plus d’endroits que le réseau de gestion d’origine, parce qu’il servait des apps internes générales. Le contrôle d’accès se trouvait dans la couche proxy, maintenue par une équipe différente de la virtualisation.
L’équipe virtualization supposait que l’équipe proxy gérait l’auth. L’équipe proxy supposait que Proxmox gérait l’auth. Les deux avaient partiellement raison. Aucun n’était entièrement responsable.

Le vrai problème : un changement de configuration a introduit un contournement d’authentification pour un motif de chemin spécifique. Ce n’était pas malveillant ; c’était un réglage « allow health checks » recopié.
Soudain, l’API Proxmox avait une exposition partielle non authentifiée aux réseaux internes. Pas assez pour prendre instantanément le cluster, mais suffisant pour effectuer de l’énumération. L’énumération, c’est comment les attaques ciblées cessent d’être bruyantes.

Ils l’ont détecté parce qu’un ingénieur sécurité a lancé un scan de routine et a demandé, poliment et à plusieurs reprises, pourquoi l’API hyperviseur répondait différemment de l’attendu.
La correction a été de retirer Proxmox du proxy général, de garder l’accès de gestion sur un modèle VPN+jump host, et d’exiger que tout futur proxy des plans de gestion passe par une revue sécurité avec allowlists de chemin explicites.

L’optimisation n’est pas gratuite. La centralisation réduit la charge et augmente le rayon d’impact. Ne la faites que si vous pouvez garantir propriété, revue et journalisation au même niveau que le système que vous frontalisez.

Mini-récit 3 (pratique ennuyeuse mais correcte) : « La politique du jump host que personne n’aimait »

Une grande entreprise exploitait plusieurs clusters Proxmox pour des workloads edge. La politique était péniblement stricte : pas d’accès UI direct sauf depuis un jump host durci ; MFA requis ; pas de SSH depuis les portables ; tokens scellés par service ; revue hebdomadaire des logs.
Les ingénieurs se plaignaient. Certains essayaient de contourner. La sécurité disait non. Franchement, ce n’était pas populaire.

Puis un poste de travail développeur a été compromis via une faille de navigateur. L’attaquant a accédé aux réseaux internes, récolté plein de clés SSH, et tenté de pivoter vers l’infra.
La plupart du temps, là commence l’histoire qui coûte cher.

Mais les clés ne fonctionnaient pas contre les hôtes Proxmox parce que SSH n’était joignable que depuis le sous‑réseau du jump host. L’UI n’était pas non plus joignable.
L’attaquant a ensuite tenté d’accéder au jump host, a buté sur la MFA, et s’est enlisé. Il est passé à des cibles plus faciles : services dev, environnements de test, systèmes de faible valeur.

L’incident a quand même fait des dégâts — les endpoints compromis font toujours mal — mais ce n’est pas devenu « hyperviseurs conquis ». Cette politique ennuyeuse a gardé les bijoux de la couronne derrière une porte que l’attaquant ne pouvait pas ouvrir discrètement.
La réunion post‑incident était du genre rare où l’équipe est sortie avec moins de travail, parce que les contrôles « agaçants » se sont avérés la forme d’assurance la moins chère.

Listes de vérification / plan pas à pas

Pas à pas : verrouiller l’accès sans se verrouiller soi‑même hors du système

1. Confirmez votre échappatoire : assurez‑vous d’avoir un accès console physique/IPMI/iDRAC, ou un chemin KVM-over-IP. Si vous n’en avez pas, ne procédez pas à des changements de pare‑feu agressifs.
2. Inventoriez les points d’entrée : listez les ports à l’écoute (ss -lntp) et mappez‑les aux interfaces (ip -br addr).
3. Définissez le sous‑réseau de gestion : choisissez un seul réseau admin (exemple : 10.10.10.0/24) et documentez‑le.
4. Restreignez UI/API : autorisez TCP/8006 seulement depuis le sous‑réseau admin/jump host. Bloquez tout le reste.
5. Restreignez SSH : autorisez TCP/22 seulement depuis le sous‑réseau admin. Désactivez l’authentification par mot de passe. Désactivez le login root si possible.
6. Cessez d’utiliser des identités partagées : créez des comptes admin nommés. Passez les humains à une connexion soutenue par MFA.
7. Implémentez le RBAC : créez des rôles pour VM ops, stockage ops et audit/revue des logs. Évitez l’admin datacenter par défaut sauf si nécessaire.
8. Corrigez l’automatisation : utilisez des tokens API par pipeline/service, scellés aux chemins minimaux. Stockez les tokens en sécurité et faites‑les tourner.
9. Segmentez les réseaux : gestion, VM, stockage, cluster. Si vous ne pouvez pas, utilisez des règles de pare‑feu pour forcer l’isolation logique.
10. Protégez les sauvegardes : restreignez les ports de sauvegarde, séparez les identifiants, empêchez la suppression par défaut, et testez les procédures de restauration.
11. Activez et révisez les logs : vérifiez les logs SSH, les logs de tâches Proxmox et les logs de pare‑feu. Faites en une habitude hebdomadaire.
12. Faites un passage de validation : testez la joignabilité depuis un réseau non‑admin et confirmez que 8006/22 échouent.

Checklist contrôle d’accès (imprimable dans votre tête)

• UI/API accessibles uniquement depuis un jump host ou un sous‑réseau VPN de confiance.
• Pas de SSH par mot de passe. Pas de SSH root direct (ou break‑glass strictement contrôlé).
• Comptes admin nommés avec MFA ; pas d’identifiants partagés.
• L’automatisation utilise des tokens API avec séparation des privilèges et ACLs scellées.
• Les réseaux VM ne peuvent pas atteindre les interfaces de gestion.
• Les sauvegardes ont un accès séparé, des identifiants séparés et suppression protégée.
• Logs revus régulièrement ; tentatives d’auth suspectes sont actionnables, pas décoratives.

FAQ

1) Est‑il jamais acceptable d’exposer Proxmox TCP/8006 sur Internet si j’utilise des mots de passe forts ?

Non. Les mots de passe forts réduisent un risque. Ils ne réduisent pas les scans, le phishing, le vol de tokens via le navigateur, les bugs UI ou la réutilisation d’identifiants dans le temps.
Placez l’UI derrière un VPN ou un jump host et restreignez l’ingress au niveau réseau.

2) Puis‑je simplement changer le port 8006 pour un autre ?

Changer le port réduit le bruit, pas le risque. Les attaquants scannent des plages et fingerprintent les services. Si vous comptez sur l’obscurcissement de port, vous serez en sécurité jusqu’à ce que vous ne le soyez plus.
Faites une restriction d’accès appropriée à la place.

3) Dois‑je désactiver root entièrement ?

Sur Linux, root existe. La question est comment il est utilisé. Traitez root comme break‑glass : accès console, urgences, changements contrôlés.
Pour les opérations courantes, utilisez des comptes nommés et le RBAC.

4) Quelle est la configuration RBAC minimale réellement utile ?

Créez au minimum : un rôle admin pour les changements au niveau cluster, un rôle opérateur VM pour les actions quotidiennes sur les VM, et un rôle opérateur sauvegarde.
Ensuite, scopez les rôles aux chemins de ressources (par pool ou plage de VM) au lieu d’accorder des droits datacenter par défaut.

5) La segmentation VLAN suffit‑elle à empêcher une VM compromise d’atteindre la gestion ?

Seulement si le routage entre VLANs est strictement contrôlé. Dans beaucoup de labos, le routage inter‑VLAN est large ouvert « parce que c’est pratique ».
Utilisez des règles de pare‑feu aux frontières L3 et, si possible, gardez la gestion sur un réseau que les VM ne peuvent pas atteindre du tout.

6) Les tokens API sont‑ils plus sûrs que stocker un nom d’utilisateur et un mot de passe pour l’automatisation ?

Oui, lorsqu’ils sont utilisés correctement. Les tokens peuvent être scellés et tournés et séparés des privilèges utilisateur.
Mais un token avec des droits larges et sans cycle de vie n’est qu’un mot de passe mieux emballé.

7) Comment savoir si quelqu’un force brute mon Proxmox ou SSH ?

Cherchez des tentatives d’auth répétées dans journalctl -u ssh et dans les logs d’auth/tâches Proxmox.
Surveillez aussi une hausse d’utilisation CPU dans pveproxy et des plages d’IP source inhabituelles. Puis corrigez l’exposition ; ne bloquez pas seulement une IP.

8) Qu’en est‑il d’utiliser un reverse proxy avec SSO devant Proxmox ?

C’est possible, mais facile à faire dangereusement. Vous ajoutez une dépendance critique : si le proxy reroute mal ou bypass l’auth pour un chemin, votre plan de contrôle est exposé.
Gardez le plan de gestion sur un chemin d’accès dédié sauf si vous pouvez garantir le durcissement, la propriété et l’audit du stack proxy.

9) Si j’active la 2FA, puis‑je relâcher les restrictions réseau ?

Non. La 2FA est une couche, pas un remplacement des frontières réseau. Restreignez la joignabilité d’abord, puis ajoutez la 2FA pour les humains, et scopez les tokens pour l’automatisation.
Les couches sont la façon de survivre à la défaillance d’une couche.

10) Comment les sauvegardes s’insèrent‑elles dans le contrôle d’accès ?

Les sauvegardes sont un plan de contrôle pour la reprise. Si des attaquants peuvent y accéder ou les supprimer, ils peuvent négocier avec vous à l’aide de vos propres données.
Placez les services de sauvegarde sur des réseaux restreints, minimisez les droits de suppression, et testez les restaurations en supposant que les identifiants prod sont compromis.

Prochaines étapes réalisables cette semaine

Si votre environnement Proxmox est un labo aujourd’hui, traitez‑le comme s’il allait compter demain. Parce que ce sera le cas.
Voici un ordre pratique qui vous donne une réduction rapide du risque sans refonte d’un mois.

1. Tuez l’exposition : restreignez TCP/8006 et TCP/22 à votre sous‑réseau admin/jump host seulement.
2. Cessez d’utiliser root pour le travail courant : créez des comptes admin nommés et migrez les habitudes.
3. Activez la MFA pour les humains : ne débattez pas cela jusqu’au prochain trimestre.
4. Corrigez l’identité d’automatisation : remplacez les identifiants humains partagés par des tokens scellés.
5. Segmentez ou bloquez : assurez‑vous que les VM ne peuvent pas atteindre le plan de gestion ; faites‑le par réseau ou pare‑feu (préférez les deux).
6. Protégez les sauvegardes : restreignez les endpoints, séparez les permissions, et vérifiez que vous pouvez restaurer.
7. Planifiez la revue des logs : 15 minutes hebdomadaires attrapent plus que vous ne voulez l’admettre.

Le but n’est pas une sécurité parfaite. Le but est de rendre la compromission coûteuse, bruyante et contenable. Si votre labo survit à vos propres erreurs, il a une chance contre l’intention de quelqu’un d’autre.