Traçabilité des accès et journal d’audit Proxmox VE

Les quatre portes d’entrée

Avant de chercher des traces, listez par où l’on peut agir sur un cluster Proxmox VE :

L’interface web et l’API, sur le port 8006, avec un compte d’un royaume (PAM, Proxmox VE, LDAP, Active Directory, OpenID Connect) et éventuellement un second facteur ;
les tokens API, envoyés dans l’en-tête Authorization: PVEAPIToken=USER@REALM!TOKENID=UUID par les outils d’automatisation, de supervision ou de sauvegarde ;
SSH sur les nœuds, utilisé par les administrateurs et, entre nœuds, par le cluster lui-même ;
les consoles des machines (noVNC, SPICE, terminal), ouvertes depuis l’interface.

Chacune laisse des traces différentes, à des endroits différents, et parfois aucune.

Connexions à l’interface et à l’API

Les échecs d’authentification sont écrits par le service pvedaemon dans le journal systemd, avec l’adresse d’origine et le compte tenté. C’est d’ailleurs la ligne que la page fail2ban du wiki Proxmox utilise pour bloquer les attaques par force brute :

journalctl _SYSTEMD_UNIT=pvedaemon.service | grep "authentication failure"

Les connexions réussies apparaissent aussi dans les journaux des services Proxmox VE. Le journal d’accès de pveproxy, /var/log/pveproxy/access.log, enregistre en plus chaque requête HTTP reçue par l’interface et l’API, avec son adresse source : c’est là qu’on retrouve l’activité d’un outil qui utilise un token, puisqu’il ne passe pas par l’écran de connexion.

Le journal systemd est actif par défaut depuis Proxmox VE 4.0 et conservé après redémarrage depuis la 7.0 ; sa durée de conservation dépend de l’espace qui lui est alloué sur chaque nœud.

Connexions SSH

Les connexions SSH sont journalisées par le démon sshd dans le même journal système :

journalctl _COMM=sshd --since "2026-10-01"

Distinguez les connexions des administrateurs de celles que les nœuds établissent entre eux pour le fonctionnement du cluster : les secondes sont normales et nombreuses, et noient les premières si l’on ne filtre pas sur l’adresse d’origine. Un compte nominatif par administrateur, plutôt que root partagé, est la condition pour qu’une connexion SSH désigne une personne.

Consoles et tâches

L’ouverture d’une console sur une machine et les opérations lancées depuis l’interface (démarrage, migration, sauvegarde, modification) sont des tâches, enregistrées sur le nœud concerné avec le compte qui les a lancées :

pvenode task list --userfilter jean@pve
pvenode task list --vmid 104 --typefilter vncproxy

L’historique des tâches répond à « qui a fait quoi sur cette machine », pas à « qui s’est connecté ». Pour le détail d’une modification de configuration, voir qui a modifié cette VM ?

Royaumes externes : LDAP, Active Directory, OpenID Connect

Quand les comptes viennent d’un annuaire, l’identité est gérée hors de Proxmox VE, mais les droits restent attribués dans Proxmox VE. Les groupes synchronisés par pveum realm sync <royaume> sont écrits dans /etc/pve/user.cfg. Deux conséquences pour la traçabilité : un départ doit être traité dans l’annuaire et vérifié dans Proxmox VE, où un compte local ou un token peut survivre au compte d’annuaire ; et les connexions doivent pouvoir être rapprochées des journaux de l’annuaire, ce qui suppose des horloges communes.

Second facteur et verrouillages

Le second facteur change aussi ce qu’on lit dans les traces. Après huit échecs TOTP, les facteurs TOTP du compte sont désactivés ; pour WebAuthn et les clés de récupération, cent essais bloquent tous les seconds facteurs pendant une heure. Un compte verrouillé signale soit un appareil perdu, soit une tentative sur un mot de passe déjà connu de l’attaquant : dans les deux cas, cela mérite une vérification avant le déblocage.

pveum user tfa list
pveum user tfa unlock jean@pve

Pas de journal d’audit des comptes et des droits

En février 2026, sur le forum Proxmox, une équipe qui voulait envoyer les journaux de Proxmox VE 8.4 et 9.1 vers un SIEM a fait le constat suivant : les connexions SSH, PAM et à l’interface (réussies ou non) sont visibles, mais pas la création ou la suppression d’un utilisateur, ni un changement de rôle, de permission ou d’ACL, que ce soit dans les tâches, le journal système ou le journal du cluster. Un autre participant résumait : il n’y a pas pour l’instant de système d’audit dans Proxmox VE.

Conséquence pratique : pour savoir qui a reçu des droits d’administration et quand, il faut comparer des relevés successifs des comptes et des ACL (pveum user list --full, pveum acl list), datés et conservés hors du cluster. Le contenu des fichiers concernés, comme /etc/pve/user.cfg, décrit l’état présent, pas son évolution. ProxTrace comble ce manque, comme décrit plus bas.

Conserver et centraliser

Des traces restées sur un nœud ne servent pas longtemps : elles tournent avec l’espace disque, disparaissent avec le nœud, et un intrus qui a obtenu les droits d’administration peut les effacer. Les participants du fil cité transfèrent les journaux avec rsyslog vers un serveur central ou un SIEM, une solution jugée imparfaite mais utilisable.

Envoyez vers un serveur hors du cluster le journal système de chaque nœud (au minimum pvedaemon, pveproxy et sshd) et le journal d’accès de pveproxy.
Gardez les horloges des nœuds synchronisées : sans heure commune, on ne peut pas croiser un échec de connexion avec une tâche.
Exportez à intervalle régulier la liste des comptes, des tokens et des ACL, pour pouvoir dater un changement de droits.
Définissez la durée de conservation selon vos obligations, et vérifiez qu’elle couvre la période qu’un audit vous demandera.

Ce qu’il faut surveiller en priorité

les échecs d’authentification répétés depuis une même adresse, et ceux qui visent root@pam ;
une connexion réussie depuis une adresse hors du réseau d’administration ;
les connexions de comptes dormants ou censés avoir quitté l’organisation ;
l’usage d’un token depuis une adresse inhabituelle, ou après sa date prévue de retrait ;
un nouveau compte administrateur, ou un compte existant qui reçoit soudain Administrator sur /.

Les réglages qui réduisent ces risques (second facteur, IPSet de gestion, accès SSH filtré, tokens datés) sont détaillés dans la checklist de durcissement Proxmox VE ; le guide de l’audit de sécurité montre comment vérifier qu’ils sont en place.

Enquêter sur une connexion suspecte, pas à pas

Les échecs : dans le journal de pvedaemon, les tentatives depuis l’adresse en cause, les comptes visés et la période.
Une réussite ? Une connexion réussie depuis la même adresse, ou juste après une série d’échecs sur le même compte.
Ce qui a suivi : dans le journal d’accès de pveproxy, les requêtes de cette adresse après la connexion.
Les actions : pvenode task list --userfilter sur chaque nœud pour le compte concerné, sur la même fenêtre.
Les droits : comparer les relevés de comptes, de tokens et d’ACL avant et après, pour repérer un compte ou un token ajouté.
Contenir : désactiver le compte (pveum user modify <compte> --enable 0), supprimer ses tokens, changer les secrets exposés, puis consigner la chronologie et ce qui reste une déduction.

Ce que ProxTrace ajoute

ProxTrace rassemble ces sources dans une même chronologie :

tâches, appels d’API, connexions et journaux deviennent des événements reliés au nœud et à la machine concernés, avec des filtres par compte ou token, adresse source, opération et période ;
les utilisateurs, groupes, rôles et permissions (ACL) de Proxmox VE sont comparés d’une collecte à l’autre : chaque changement devient un événement qui garde l’état avant et après, et la notification nomme les entrées ajoutées ou retirées. C’est le journal d’audit des comptes et des droits que Proxmox VE ne tient pas ; les pare-feu du cluster et des nœuds sont suivis de la même façon ;
une connexion n’est rapprochée d’un compte que si la correspondance est unique, et elle est alors marquée « Corrélée » : l’outil ne devine pas qui était derrière une adresse ;
les points qui demandent une action, dont la catégorie « accès Proxmox », arrivent dans la file À traiter, avec leur preuve ;
les contrôles couvrent notamment les échecs d’authentification, les comptes dormants et les tokens API ;
l’historique est conservé par ProxTrace, hors des nœuds, et son agent ne lit qu’en lecture seule.

Le détail des données collectées et des droits de l’agent est sur la page sécurité du collecteur.

Traçabilité des accès et journal d’audit Proxmox VE : qui s’est connecté, d’où et comment