ProxTrace
GitHubPublic repository coming soon Open console

Proxmox VE hardening checklist, with commands

Hardening Proxmox VE means narrowing who can administer it, from where and with which rights: named accounts with a second factor, scoped API tokens, filtered web interface and SSH, an active firewall, unprivileged containers, encrypted backups and working alerts. Each item below comes with its command and the precaution to take before applying it, because hardening done in the wrong order locks the administrator out first.

By Pepiva Technology · Published

Before you start

Start from an inventory: the Proxmox VE security audit guide gives the commands to record accounts, permissions, tokens, firewall state and repositories. This checklist starts from that record and says what to change.

  • Keep an SSH session open on one node for the whole operation; the firewall documentation explicitly asks for it before enabling the firewall.
  • Work one node and one topic at a time, and check that the web interface, migration and replication still work before moving on.
  • Write down every change with its date and previous value: an auditor will ask for it, and Proxmox VE does not keep it for you.

1. Accounts and roles

One account per person, rights limited to their scope, an end date for temporary access.

pveum acl modify /vms/104 --roles PVEVMUser --users john@pve
pveum user modify contractor@pve --expire 1798761599
pveum user modify former@pve --enable 0
  • Keep the Administrator role on / for a few named accounts; give PVEAuditor (read-only) to people who only need to look.
  • Use root@pam only for operations that require it: it cannot be deleted and has no restrictions.
  • Expiry is given in seconds since the Unix epoch (here 31 December 2026, 23:59:59 UTC); 0 means “never”. --enable 0 cuts an account’s access without deleting it.

2. Second factor

Every administrative account should have at least one second factor (TOTP or WebAuthn) and recovery keys stored outside the cluster. For a whole realm, a second factor can be enforced with pveum realm modify <realm> --tfa type=…; the documentation provides TOTP or YubiKey OTP for this mode.

Precaution: enforcing a second factor on a realm applies to all of its accounts at their next login. Check first with pveum user tfa list who already has one, and warn the others.

3. API tokens

One integration, one technical account, one scoped and dated token.

pveum user token add monitoring@pve grafana --privsep 1 --expire 1830297599
pveum acl modify / --roles PVEAuditor --tokens 'monitoring@pve!grafana'
pveum user token remove automation@pve old
  • The example creates a read-only monitoring token (PVEAuditor) valid until the end of 2027. Privilege separation (--privsep 1) is the default: the token only has the rights granted to it, within those of its user. Avoid --privsep 0, which gives it all of the user’s rights.
  • Without --expire, the token inherits its user’s expiry; 0 means “never”.
  • The secret value is shown only once, at creation: store it in the vault of the tool that uses it.

4. Web interface access

The interface (port 8006) should only be reachable from the management network. At service level, /etc/default/pveproxy accepts address lists:

ALLOW_FROM="10.0.10.0/24"
DENY_FROM="all"
POLICY="allow"
systemctl restart pveproxy.service spiceproxy.service

Precaution: the restart can interrupt long-running operations. The documentation also advises against restricting the listening address (LISTEN_IP) on a cluster, whose nodes must reach each other’s service. Finally, replace the default certificate with a trusted one (ACME or your own certificate authority).

5. Host firewall

The Proxmox VE firewall is disabled by default. Order matters:

  1. Open an SSH session on a host.
  2. Declare the management network in the management IPSet of /etc/pve/firewall/cluster.fw: its members keep access to the web interface, SSH, consoles and migrations.
  3. Enable the firewall at datacenter level, then check.
[IPSET management]
10.0.10.0/24
pve-firewall status
pve-firewall localnet

pve-firewall localnet shows the detected local network, the one the firewall allows for corosync, the API and SSH between nodes: check that it matches the cluster network. The nftables mode (proxmox-firewall) exists but is still a technology preview; keep the default implementation in production unless you have a specific reason.

6. Guest firewall

For a VM or container to be filtered, two settings are needed: the guest’s general firewall option, and the firewall flag on each of its network interfaces. A forgotten interface is not filtered. A guest’s rules live in /etc/pve/firewall/<VMID>.fw. Also enable IP filtering (ipfilter) on guests that should not change address, to stop them from spoofing another one.

7. SSH

Read the configuration actually in effect rather than the file, which other files may extend:

sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers|allowgroups'
  • PermitRootLogin prohibit-password stops root from logging in with a password while keeping key logins.
  • PasswordAuthentication no once the administrators’ keys are in place.
  • AllowUsers or AllowGroups to limit which accounts may log in.

Precaution: the nodes of a cluster talk to each other through an SSH tunnel on port 22, using the keys in /etc/pve/priv/authorized_keys. Forbidding root entirely (PermitRootLogin no) or setting AllowUsers without root can break these exchanges. After each change, test a migration and a replication, and remove from that file the keys of nodes that have left the cluster.

8. Updates and repositories

A production host follows the enterprise repository (subscription) or pve-no-subscription, never pve-test. Repositories are described in /etc/apt/sources.list.d/*.sources; an entry is disabled with an Enabled: no line.

apt update
apt full-upgrade

Use apt full-upgrade, not apt upgrade, which leaves the host partially upgraded. On a cluster, upgrade the nodes one after the other and keep them on the same version.

9. LXC containers

  • Create unprivileged containers, which is the default at creation; the documentation reserves privileged containers for trusted environments.
  • Never bind mount the host’s /, /var or /etc into a container; use dedicated directories, for example under /mnt/bindmounts. These bind mounts are not backed up by vzdump: back them up separately.
  • Only enable advanced features (nesting, keyctl, fuse, mount) when the container needs them, and do not disable AppArmor (lxc.apparmor.profile = unconfined) in production.

10. Protecting critical guests

qm set 104 --protection 1
pct set 201 --protection 1

On a VM, protection blocks removing the VM and its disks; on a container, it also blocks updating its disks. It does not replace permissions, but it prevents the handling mistake on the machines whose loss would cost the most.

11. Encrypted backups

When backing up to Proxmox Backup Server, enable client-side encryption (AES-256-GCM): data is encrypted before it leaves the host.

proxmox-backup-client key create
proxmox-backup-client key create-master-key
proxmox-backup-client key paperkey

Precaution: without the key, backups are inaccessible, and a key kept only on the host disappears with it. Keep a copy outside the cluster (password manager, a USB drive stored safely, a paper copy) and the master key, which lets you recover each backup’s key. Mark as protected the backups that retention must not remove.

12. Notifications

A failure has to reach someone. Notifications are configured in /etc/pve/notifications.cfg, with Sendmail, SMTP, Gotify or webhook targets. Proxmox VE notifies, among other events, available updates, node fencing, failed replication and backup results. Check that the recipient accounts have an email address: without one, no message is sent.

The limits of a checklist

A checklist describes the state to reach, not the actual state a week later. A token recreated without expiry, a rule disabled during troubleshooting or a container switched to privileged only shows up at the next audit, with no record of who changed it or when. Hardening holds over time only if it is re-checked and every deviation leaves a trace.

What ProxTrace adds

ProxTrace hardens nothing: it does not change the infrastructure, and its agent installed on the nodes only reads. It continuously checks that the settings on this list still hold, and keeps a record of what moves:

  • its 115 Proxmox VE best-practice checks cover, among other things, accounts and roles, second factor, API tokens, SSH, firewall, repositories, LXC containers and backups, with four statuses (Pass, Fail, Not assessable, Out of scope) and re-evaluation every five minutes;
  • every configuration change is kept with its before and after value, which answers “who disabled this rule, and when”;
  • sealed reports keep a date’s state exactly as it was assessed, to show an auditor.

The agent’s exact rights are listed on the collector security page.

Sources