Sécuriser Proxmox VE : utilisateurs, droits, 2FA et pare-feu

Sécuriser un hyperviseur, c'est contrôler qui peut agir sur les machines virtuelles et comment on y accède : des comptes nominatifs avec la double authentification, des droits limités au strict nécessaire, une interface d'administration joignable seulement depuis le réseau d'administration, et un pare-feu. Ce chapitre explique le modèle de droits de Proxmox VE (domaines, utilisateurs, groupes, rôles, chemins), le relie à l'Active Directory de Sorbier, met en place la double authentification et le pare-feu intégré, et termine par une liste de durcissement.

Pourquoi l'hyperviseur est la cible n° 1

Celui qui contrôle l'hyperviseur contrôle toutes les machines virtuelles : il peut les éteindre, copier leurs disques (et donc la base de l'annuaire et ses empreintes de mots de passe), supprimer leurs snapshots et leurs sauvegardes, puis chiffrer les disques d'un coup. Plusieurs familles de rançongiciels visent précisément les hyperviseurs pour cette raison : une seule compromission suffit à arrêter toute l'entreprise. Les symptômes typiques d'une telle attaque, à surveiller, sont des connexions d'administration à des heures inhabituelles, la suppression en série de snapshots ou de tâches de sauvegarde, et l'arrêt simultané de nombreuses VM. Les contre-mesures sont celles de ce chapitre : accès réservé au réseau d'administration, comptes nominatifs avec double authentification, moindre privilège, journaux envoyés hors de l'hyperviseur, sauvegardes hors de sa portée.

Le modèle de droits de Proxmox VE

Un droit, dans Proxmox VE, se lit comme une phrase : tel utilisateur (ou groupe, ou jeton) a tel rôle sur tel chemin.

Un droit posé sur un chemin s'applique aussi à tout ce qui est en dessous, si l'option Propagate est cochée (c'est le cas par défaut) : un rôle sur /vms vaut pour toutes les VM. Un droit posé plus bas remplace celui hérité d'en haut.

Les rôles prédéfinis à connaître :

On peut créer ses propres rôles, avec exactement les privilèges voulus : pveum role add VM_Power-only --privs "VM.PowerMgmt VM.Console" crée un rôle qui ne permet que d'allumer, d'éteindre et d'ouvrir la console.

Les comptes : PAM, PVE ou l'annuaire

root@pam est le super-administrateur de Proxmox VE : il a tous les droits, ne peut pas être supprimé, et sert pour les opérations de l'hôte lui-même. On ne l'utilise pas au quotidien et on ne le partage pas : chaque administrateur a son compte nominatif, ce qui permet de savoir qui a fait quoi dans les journaux.

Chez Sorbier, les comptes viennent de l'Active Directory : un technicien qui quitte l'entreprise est désactivé une fois dans l'annuaire, et perd aussi l'accès à l'hyperviseur. Dans Datacenter > Permissions > Realms > Add > Active Directory Server :

Ou en ligne de commande, puis la synchronisation des utilisateurs et des groupes :

pveum realm add sorbier --type ad --domain ad.sorbier.example \
  --server1 192.168.10.177 --server2 192.168.10.181 --mode ldaps
pveum realm sync sorbier --scope both

Les groupes importés gardent leur nom suivi du domaine (GG_Proxmox_Techniciens-sorbier). Il ne reste plus qu'à leur donner des droits.

Donner des droits : la matrice de Sorbier

Le service informatique de Sorbier a défini qui fait quoi sur le cluster :

En ligne de commande :

# Droits des groupes de l'annuaire
pveum acl modify / --groups GG_Proxmox_Admins-sorbier --roles Administrator
pveum acl modify /vms --groups GG_Proxmox_Techniciens-sorbier --roles PVEVMAdmin
pveum acl modify /storage --groups GG_Proxmox_Techniciens-sorbier --roles PVEDatastoreUser

# Un pool pour le laboratoire, et un compte local pour le stagiaire
pveum pool add lab --comment "VM de TP et de tests"
pveum group add stagiaires
pveum user add stagiaire1@pve --groups stagiaires --password
pveum acl modify /pool/lab --groups stagiaires --roles PVEVMUser

# Un utilisateur et un jeton en lecture seule pour la supervision
pveum user add zabbix@pve --comment "Supervision Zabbix"
pveum user token add zabbix@pve supervision --privsep 1
pveum acl modify / --tokens 'zabbix@pve!supervision' --roles PVEAuditor

# Vérifier ce qu'un compte peut réellement faire
pveum user permissions clambert@sorbier

pveum user token add affiche le secret du jeton une seule fois : copie-le immédiatement dans la configuration de l'outil qui l'utilise. Avec --privsep 1 (séparation des privilèges), le jeton n'a que les droits qu'on lui donne explicitement, et non tous ceux de son utilisateur. Le modèle Proxmox VE by HTTP de Zabbix utilise exactement ce type de jeton en lecture seule (cours Supervision).

La double authentification

Un mot de passe volé ne doit pas suffire pour entrer dans l'hyperviseur. Proxmox VE gère plusieurs seconds facteurs :

Chaque utilisateur active son second facteur dans Datacenter > Permissions > Two Factor > Add (TOTP, WebAuthn ou Recovery Keys), en scannant le QR code et en saisissant un premier code pour valider. Après huit codes TOTP faux, le TOTP du compte est bloqué ; un administrateur le débloque avec pveum user tfa unlock <utilisateur>.

Pour un domaine Active Directory ou LDAP, l'administrateur peut imposer un second facteur à tous ses comptes, dans les options du domaine (Require TFA : TOTP ou Yubico OTP) : un utilisateur qui n'en a pas configuré ne peut plus se connecter.

Le pare-feu de Proxmox

Proxmox VE a un pare-feu intégré, à trois niveaux, qui filtre le trafic de l'hôte et celui de chaque VM, au plus près de la machine :

Le pare-feu est désactivé par défaut au niveau du centre de données. Une fois activé, la politique d'entrée est de tout refuser, à l'exception de l'interface web (TCP 8006) et de SSH (TCP 22) depuis le réseau local du cluster et depuis l'ensemble d'adresses spécial management. Crée donc cet IPSet avec le réseau d'administration avant d'activer le pare-feu, pour ne pas te couper l'accès :

1. Datacenter > Firewall > IPSet > Create : nom management, puis Add 192.168.10.208/28 ;
2. Datacenter > Firewall > Options : Firewall sur Yes.

Les règles d'une VM utilisent des macros (des services prédéfinis : HTTPS, SSH, DNS…). Pour srv-web, dans la DMZ, qui ne doit accepter que HTTPS de partout et SSH depuis le réseau d'administration :

# /etc/pve/firewall/225.fw
[OPTIONS]
enable: 1
policy_in: DROP
log_level_in: info

[RULES]
IN HTTPS(ACCEPT) -log nolog
IN SSH(ACCEPT) -source 192.168.10.208/28

Ce pare-feu ne remplace pas le pare-feu de périmètre (pfSense chez Sorbier) : il ajoute une micro-segmentation, un filtrage entre machines d'une même zone, que le pare-feu central ne voit pas. L'architecture complète des zones et des flux est dans le cours Cybersécurité des infrastructures.

Durcir l'hôte

Exercices

# Un rôle limité à l'alimentation et à la console
pveum role add VM_Power-only --privs "VM.PowerMgmt VM.Console"
pveum acl modify /vms/180 --users ibenali@sorbier --roles VM_Power-only

# L'auditeur : un compte local, en lecture seule sur tout, qui expire dans une semaine
pveum user add audit-externe@pve --expire 1794268800 --password
pveum acl modify / --users audit-externe@pve --roles PVEAuditor

[OPTIONS]
enable: 1
policy_in: DROP
log_level_in: info

[RULES]
IN HTTPS(ACCEPT) -source 192.168.10.64/26
IN ACCEPT -source 192.168.10.225 -p tcp -dport 8443
IN SSH(ACCEPT) -source 192.168.10.208/28