ProxTrace
GitHubPublic repository coming soon Open console

Proxmox VE security audit: a step-by-step method

A Proxmox VE security audit checks, node by node, who can log in and with which rights, what is exposed on the network, whether the hosts are up to date and whether backups are protected, keeping dated evidence for every point. All of it can be done with Proxmox VE’s native commands; the hard part is repeating it regularly and knowing what changed between two audits.

By Pepiva Technology · Published · Updated

1. Define the scope

A standalone host and a cluster do not call for the same checks. Start by listing the nodes and checking quorum, then write down the features you actually use: Ceph, high availability, replication, SDN, Proxmox Backup Server.

pvecm status
pvecm nodes

This inventory is what lets you classify each check. A Ceph check is out of scope when the cluster does not run Ceph. It is not assessable when Ceph is there but you could not read its state. Mixing the two up turns missing evidence into a passing result.

2. Accounts, roles and permissions

Proxmox VE stores users, groups and permissions in /etc/pve/user.cfg and authentication realms (PAM, Proxmox VE, LDAP, Active Directory, OpenID Connect) in /etc/pve/domains.cfg. Both files are replicated to every node of the cluster.

pveum user list --full
pveum acl list
pveum user permissions john@pve --path /

What to look for:

  • accounts holding the Administrator role on /, and those for which PVEAuditor (read-only) would be enough;
  • accounts with no expiry date or no recent use, especially those of people who have left;
  • use of root@pam: it is an unconfined administrator, cannot be deleted and can always log in through the PAM realm. Keep it for the operations that require it and use named accounts for everything else;
  • user permissions that override group permissions: effective rights are read with pveum user permissions, not from the ACL list alone. The NoAccess role cancels every other role on a path.

3. Multi-factor authentication

Each user can register TOTP and WebAuthn factors and single-use recovery keys. A realm can also enforce a second factor (TOTP or YubiKey OTP) for all of its accounts.

pveum user tfa list

Check that every account with administrative rights has at least one second factor, that no shared accounts exist, and that the unlock procedure is known: after eight failed TOTP attempts, the account’s TOTP factors are disabled until a recovery key is used or an administrator unlocks them.

4. API tokens

Integrations (monitoring, backup, automation) connect with API tokens. A token can carry an expiry date, can be revoked without disabling its user and is privilege-separated by default: its effective rights are the intersection of the user’s rights and the token’s own.

pveum user token list automation@pve
pveum user token permissions automation@pve backup

Flag tokens with no expiry, tokens that are not privilege-separated, tokens attached to root@pam and tokens nobody can explain anymore. Each integration should have its own technical account and a token limited to the paths it needs.

5. Network exposure and firewall

The Proxmox VE firewall is completely disabled by default. It is enabled at datacenter level in /etc/pve/firewall/cluster.fw, then tuned per host in /etc/pve/nodes/<node>/host.fw and per guest in /etc/pve/firewall/<VMID>.fw.

pve-firewall status
pve-firewall localnet

Once the input policy is set to DROP or REJECT, Proxmox VE still lets the management IPSet reach the web interface (TCP 8006), SSH (22), VNC consoles (5900 to 5999), SPICE (3128) and migrations (60000 to 60050), and allows corosync (UDP 5405 to 5412) on the cluster network. Review that IPSet: it decides who can reach administration.

Access to the web interface can also be restricted at service level with ALLOW_FROM, DENY_FROM and POLICY in /etc/default/pveproxy. On the guest side, MAC address filtering is on by default; IP filtering, enabled per guest with the ipfilter option, drops outgoing traffic whose source address is not in the interface’s ipfilter-net set: it is mainly there to prevent address spoofing.

6. SSH and the cluster network

A Proxmox VE cluster needs an SSH tunnel on port 22 between its nodes. The keys allowed for these exchanges live in /etc/pve/priv/authorized_keys: when a node is removed, its key stays there and its fingerprint stays in the other nodes’ known_hosts files. An audit should find them and have them removed.

On the network side, the documentation recommends a dedicated NIC for corosync traffic, not sharing that network with storage, and at least a second corosync link on a different physical network. A cluster without a redundant link is not a security fault in the strict sense, but an outage on that network can cost the cluster its quorum.

7. Updates and repositories

On Proxmox VE 9, repositories are described in deb822 format in /etc/apt/sources.list.d/: pve-enterprise.sources for the enterprise repository (subscription required) and proxmox.sources for pve-no-subscription or pve-test. An active pve-test repository on a production host is a finding, as is an enterprise repository configured without a subscription, which blocks updates.

apt update
apt full-upgrade

apt upgrade is not enough: it cannot remove packages to resolve dependencies and leaves the host partially upgraded. Compare versions across nodes too: a cluster whose nodes run different versions is either mid-upgrade or forgotten.

8. Certificates

pvenode cert info

The web interface uses /etc/pve/local/pveproxy-ssl.pem when it exists, otherwise the node’s default certificate (pve-ssl.pem), signed by the cluster’s own certificate authority and therefore not automatically trusted by browsers or operating systems. Record expiry dates and issuers: an untrusted certificate trains users to click through browser warnings.

9. Backups

Scheduled backup jobs are stored in /etc/pve/jobs.cfg. Check that every important guest is covered, that retention (prune-backups, for example keep-last, keep-daily) matches your policy, and that backups to Proxmox Backup Server use client-side encryption when the target is shared or remote. A backup marked as protected cannot be removed by retention.

An audit does not stop at the existence of a job: the useful evidence is a successful, dated restore.

10. Traceability of actions

Each node keeps a history of its tasks (starts, migrations, backups and some configuration changes).

pvenode task list --errors
pvenode task list --userfilter john@pve --vmid 104
pvenode task log <UPID>

These lists answer “who started which task, and when”. They do not say which configuration value changed, nor what it was before. A “PVE Auditing System” proposal was discussed on the Proxmox developer list in January 2026: it would log who did what to which object and, as a configurable option, the object before and after the change. It was only a design discussion at that point, with no development under way according to its author; as far as we know, nothing has shipped. See also the guide on Proxmox VE change history.

The limits of a manual audit

  • A snapshot in time. The audit describes today’s state; an account added or a rule disabled the next day goes unnoticed until the next audit.
  • Node by node. Part of the checks must be repeated on every host, and differences between nodes are easy to miss.
  • No before and after. Without a previous record, you know a setting is wrong, not since when or who changed it.
  • Scattered evidence. Command output, screenshots and notes have to be gathered and dated for the auditor.

To move from findings to settings, the Proxmox VE hardening checklist covers the same topics with the command to apply and the precaution to take before each change.

What ProxTrace adds

ProxTrace takes this approach and makes it continuous. Its 115 Proxmox VE best-practice checks cover eight areas: inventory and visibility, cluster, platform, access, network, storage, backups, and VM and LXC workloads. Each check is split into sub-points; each one shows its observation, the exact values per node, the suggested action, its sources and the limits of its evidence.

  • Four statuses: Pass, Fail, Not assessable, Out of scope. Missing data is never counted as a success.
  • Automatic re-evaluation every five minutes; sealed reports, so a date’s state can be reviewed exactly as it was assessed; export from the console.
  • Change history with before and after values, which answers the question the task logs leave open.
  • A read-only agent installed on the nodes, with a restricted read account: ProxTrace fixes nothing on its own, the administrator decides. The exact rights are listed on the collector security page.

You can browse these checks on sample data in the demo.

What an audit does not replace

A technical audit documents gaps and the evidence behind them. It does not replace a risk assessment, an independent audit or a certification: ProxTrace, like the commands above, feeds that work without concluding it.

Sources