Secure and harden Proxmox: checklist

Have Proxmox secured: Security audit and implementation review the agreed scope. Arrange an intro call.

This checklist walks through securing a Proxmox VE host or cluster in six areas: access with 2FA and SSH, firewall, roles and API tokens, updates, web interface and the Linux base. Each area names commands and configuration from the vendor documentation and a target state for acceptance. As of October 2026. Check changes in a suitable environment first and always secure them with a second access path (console, IPMI).

Contents

• 1. Access: web GUI, SSH and 2FA
• 2. Network and firewall
• 3. Roles and API tokens
• 4. Updates and vulnerabilities
• 5. Certificates and brute-force protection
• 6. Linux base and backup protection
• Acceptance checklist
• BSI and security audit checklist
• Acceptance and operations
• Sources

1. Access: web GUI, SSH and 2FA

Limit the web GUI and SSH to a VPN, bastion or approved source networks. According to the documentation, the user root@pam can always log in through Linux PAM and is an unrestricted administrator. Work with named accounts and roles day to day and secure root@pam with a strong password and 2FA.

Two-factor login: Proxmox VE supports TOTP, WebAuthn (hardware keys, TPM), recovery keys and YubiKey OTP. Set it up in the web interface under the user's "TFA" entry. You can enforce it per authentication realm. After 8 failed TOTP attempts the account is locked; for WebAuthn and recovery keys the lock applies after 100 attempts for one hour. Keep recovery keys separate and check alternative realms and emergency accounts too.

SSH: PVE 2FA does not apply to the SSH service. Set SSH to key login, in a file under /etc/ssh/sshd_config.d/:

PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no

sshd -t && systemctl reload ssh         # check syntax, then reload
sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication'

A full PermitRootLogin no is risky in clusters because nodes use key-based root connections among themselves; prohibit-password only forbids the password. Open a second session before switching off password login and test the key access. Also check Match blocks in the OpenSSH configuration.

2. Network and firewall

First document the permitted connections for management, Corosync, storage, migration and guests. The ports Proxmox VE uses:

The Proxmox firewall works on three levels: datacenter (cluster.fw), host and guest. With the datacenter firewall enabled, the documentation says it allows by default loopback traffic, established connections, management access from the local network (web GUI, SSH, VNC, SPICE), cluster communication and certain ICMP types. Add your own rules for a separate management network as an IP set and a rule, for example in /etc/pve/firewall/cluster.fw:

[OPTIONS]
enable: 1

[IPSET management]
203.0.113.0/24

[RULES]
IN ACCEPT -source +management -p tcp -dport 8006,22

To avoid locking yourself out: create the rules first, enable the firewall afterwards, check each level through a second access path and verify the state:

pve-firewall status        # service status and configuration check
pve-firewall compile       # view the generated rules
iptables-save | head -50   # active rules on the host

A blanket DROP rule can lock out the cluster or administration. According to current documentation the nftables implementation proxmox-firewall is still a tech preview; a backend switch is not a casual hardening step.

3. Roles and API tokens

Assign roles and paths by task. Predefined roles include PVEAuditor (read only), PVEVMUser (use guests, console, backup) and PVEVMAdmin (manage guests). Create custom roles with pveum role add:

pveum user add monitoring@pve --comment "read-only access"
pveum acl modify / --user monitoring@pve --role PVEAuditor
pveum user token add monitoring@pve readonly --privsep 1

API tokens get their own ACLs and stay on privilege separation, the default for new tokens. Their effective rights are then the intersection of user and token rights; a token without privilege separation inherits the user's full rights. The token value is shown only once. Test permissions with a test account and document rotation and revocation (user management).

4. Updates and vulnerabilities

Check the supported PVE version, repository and open advisories. Regular package updates run through the web interface or on the command line; back up, plan a maintenance window and check the cluster state beforehand:

pveversion -v                 # installed package versions
apt update && apt full-upgrade

Major upgrades need their own procedure, including Ceph and PBS dependencies (upgrade from 8 to 9). For production systems the enterprise repository or commercial operation without a subscription is a deliberate decision. Proxmox documentation.

5. Certificates and brute-force protection

Use a suitable certificate for administration access. PVE supports ACME including automatic renewal. Choose the HTTP or DNS challenge to match reachability; do not permanently open the management interface just for that. The command-line procedure (adjust domain and address):

pvenode acme account register default [email protected]
pvenode config set --acme domains=pve.example.com
pvenode acme cert order

Against repeated login attempts at the web interface, the Proxmox wiki describes a Fail2ban integration. The filter reads the pvedaemon messages from the journal; the jail bans after three failed attempts:

# /etc/fail2ban/filter.d/proxmox.conf
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
journalmatch = _SYSTEMD_UNIT=pvedaemon.service

# /etc/fail2ban/jail.local
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h

Then systemctl restart fail2ban; fail2ban-client unban <IP> releases banned addresses. Fail2ban complements restricting access to a management network or VPN but does not replace it.

6. Linux base and backup protection

Check which services listen on which addresses and disable those not needed:

ss -tlnp                      # listening TCP services with process
systemctl list-unit-files --state=enabled

Also check container privileges (preferably unprivileged containers) and AppArmor for the specific environment (container documentation). Do not adopt kernel parameters wholesale from other lists. Separate backup access and keys from daily administration. Check offsite copy, retention and recovery. A successful backup job does not prove a successful restore.

Acceptance checklist

BSI and security audit checklist

The BSI module SYS.1.5 Virtualization, 2023 edition covers securing virtualization infrastructure. The following mapping is a working aid, not BSI evidence and not a certification:

For each item record status, evidence, deviation, responsibility and follow-up. Missing evidence stays open; an installed protection feature alone is not a passed check.

Acceptance and operations

Check permitted and blocked access, MFA, token rights, alerting and a documented recovery. The restore test checks the agreed recovery path. For ongoing care there is Managed Proxmox.

Security audit: Agree the scope for Proxmox security and hardening with WZ-IT. Further reading: testing a PBS restore.

Sources

• Proxmox: user management (realms, 2FA, tokens)
• Proxmox: firewall
• Proxmox: host administration and updates
• Proxmox: certificate management
• Proxmox: containers
• Proxmox wiki: Fail2ban
• OpenSSH: sshd_config
• BSI: SYS.1.5 Virtualization