Proxmox Backup Server Security Hardening

Your backups contain everything attackers want. Customer records, database dumps, private keys, licensing data. Ransomware operators figured this out years ago — they target backup servers first, before triggering encryption on production systems. A default Proxmox Backup Server install is functional, but it is not hardened. This guide covers every layer you need to address before putting PBS in front of production or client data.

The Attack Surface

Backup servers are high-value targets. They hold point-in-time copies of everything on your network. Modern ransomware families specifically look for and destroy backup storage before triggering encryption on production systems. A PBS instance that hasn't been hardened is an attractive target.

The default Proxmox Backup Server install exposes:

• Web UI and API on port 8007 (HTTPS), listening on all interfaces
• A self-signed TLS certificate
• Local PAM authentication with no rate limiting
• Full admin access for root@pam

None of those defaults are wrong for a first-time setup. All of them need attention before PBS handles production workloads.

Network Security

Firewall Configuration

PBS uses a single port: 8007 (HTTPS). Both the web UI and the backup API run on it. Lock it down at the network level before anything else.

Example ufw rules for a single-site setup:

# Allow backup clients and management
ufw allow from 192.168.10.0/24 to any port 8007 proto tcp
ufw allow from 10.0.5.0/24 to any port 8007 proto tcp
ufw allow from 192.168.1.50 to any port 8007 proto tcp

# Deny everything else on 8007
ufw deny 8007
ufw enable

Network Segmentation

Backup traffic should move on a dedicated VLAN, separate from production client traffic and general management networks.

For MSP environments, see the multi-tenant PBS guide for how namespace-level isolation fits into your VLAN topology.

TLS and Certificate Management

PBS ships with a self-signed certificate. That works for internal-only setups where you trust the network, but it creates a practical problem: Proxmox VE stores the PBS fingerprint when you add it as storage. If you later replace the cert, every PVE node loses trust and backups fail until you update each fingerprint.

For production deployments, use a CA-signed certificate. If PBS is reachable from the internet, Let's Encrypt works:

# Install certbot
apt install certbot

# Obtain cert (requires port 80 accessible for HTTP-01 challenge)
certbot certonly --standalone -d pbs.yourdomain.com

# Copy to PBS certificate paths
cp /etc/letsencrypt/live/pbs.yourdomain.com/fullchain.pem /etc/proxmox-backup/proxy.pem
cp /etc/letsencrypt/live/pbs.yourdomain.com/privkey.pem /etc/proxmox-backup/proxy.key

# Restart the API proxy
systemctl restart proxmox-backup-proxy

For PBS instances that stay internal, a private CA (pfSense, Smallstep, or a standalone Easy-RSA setup) avoids fingerprint churn entirely. Issue a cert signed by your internal CA and trust that CA on all PVE nodes once.

Authentication Hardening

User Account Security

PBS starts with root@pam. That account has full access, uses system PAM authentication, and cannot be deleted. It also cannot be disabled outright, but you can make it much harder to abuse:

• Create named admin accounts (admin@pbs or yourname@pam) for day-to-day use
• Disable password auth for root@pam at the OS SSH level
• Enable TOTP on all accounts that have web UI access

TOTP setup via CLI:

# Add TOTP for root@pam
proxmox-backup-manager user tfa add root@pam --type totp --totp-secret <base32-secret>

# List configured TFA methods
proxmox-backup-manager user tfa list root@pam

TOTP can also be configured through the web UI under Administration → Users → Edit → Two-Factor Auth.

PBS does not enforce a password complexity policy. For PAM realm users, set your policy at the OS level with PAM modules. For PBS realm users, there is no built-in enforcement — set complexity expectations through process, not technology.

API Token Best Practices

API tokens are the correct tool for any automation, monitoring agent, or service account. They authenticate against the backup API only and cannot log into the web UI. They can be scoped to a specific datastore and permission level, and they can expire.

Token format: user@realm!tokenname

Create tokens with expiration dates. Quarterly rotation is reasonable for most environments:

# Create a token for a backup client
proxmox-backup-manager user generate-token backup-client@pbs client-token

# Create a token with an expiration date (Unix timestamp)
proxmox-backup-manager user generate-token backup-client@pbs client-token --expire 1767225600

# List tokens for a user
proxmox-backup-manager user list-tokens backup-client@pbs

# Revoke a token
proxmox-backup-manager user delete-token backup-client@pbs client-token

Access Control

PBS ACLs default-deny everything. A user or token has no access until you explicitly grant it. The available roles:

Grant each account the minimum role it actually needs:

• Backup clients get DatastoreBackup on their specific datastore (or namespace)
• Monitoring tokens get Audit at the root level
• Restore automation gets DatastoreReader scoped to the relevant datastore
• Human admins get Admin on their own named account; root@pam is break-glass only

View current ACLs:

proxmox-backup-manager acl list

If you're running a multi-tenant environment, namespace-level ACLs let one PBS instance serve multiple clients without any client seeing another's data. The namespace isolation guide covers the full setup including per-namespace token scoping.

Audit ACLs quarterly. For each entry, ask: does this correspond to an active service or person? Revoke anything that doesn't.

Client-Side Encryption

Client-side encryption survives a full PBS compromise. Backups are encrypted on the Proxmox VE host with AES-256-GCM before any chunk leaves the network. Proxmox Backup Server stores ciphertext. Even with root access to the PBS host and the underlying storage, an attacker gets nothing readable.

The encryption key lives at /etc/pve/priv/storage/<STORAGE-ID>.enc on your PVE node. PBS never sees it. Lose the key and you permanently lose access to those backups. There is no recovery path.

See PBS client-side encryption for full setup and key backup procedures. The critical step after enabling encryption: export a paper key immediately with proxmox-backup-client key export-paperkey and store it offline.

For sync jobs, add --encrypted-only to prevent plaintext snapshots from replicating to your offsite PBS if something was accidentally backed up without encryption.

Audit Logging and Monitoring

PBS logs authentication events, task completions, and configuration changes to the system journal. Forward those logs to a SIEM or centralized syslog collector before you need them — logs stored on a compromised server are useless for incident response.

Forward to a central syslog server:

# Forward all PBS journal entries to SIEM
*.* @your-siem-server:514

apt install rsyslog
systemctl restart rsyslog

Proxmox Backup Server exposes Prometheus metrics at https://<pbs-host>:8007/metrics. The monitoring and alerting guide covers the full Prometheus and Grafana setup. For security monitoring specifically, alert on verify job failures and unexpected gaps in backup recency.

Physical and Host Security

PBS runs on a Linux host. Host-level security affects everything above it:

• Unattended upgrades: Vulnerabilities in the kernel, OpenSSL, or system libraries affect PBS directly. Patch automatically.
• SSH hardening: Disable password auth, use SSH keys only, restrict access to known management IPs.
• LUKS for datastore disks: PBS does not handle disk-level encryption itself. Encrypt your datastore volumes at the OS layer so physical theft doesn't yield readable data.
• Physical access control: For offsite PBS instances, the datacenter's physical security is part of your security posture.

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Security Hardening Checklist

Use this as your pre-production checklist and quarterly review reference.

Wrapping Up

A hardened Proxmox Backup Server setup isn't complicated, but it requires attention across multiple layers. Network isolation keeps attackers out. Scoped API tokens limit blast radius when a credential is compromised. Client-side encryption protects data even if everything else fails. Audit logs give you visibility when something goes wrong.

For MSPs, these controls translate directly into compliance documentation. Most of what SOC 2 Type II and ISO 27001 require for backup infrastructure security maps directly to items on the checklist above.

Start with the network controls. Then lock down authentication. Then encryption. The checklist gives you a clear sequence and something to hand to an auditor.