Security and Hardening Guide for Proxmox: Firewall, API Protection, SSH and Audit Checks

Proxmox Hardening begins with a precise operational picture: which management accesses exist, which networks are critical, which storage path dependencies are present? This chapter provides an extended, practice-oriented guide for administrators, system engineers, operators and IT service providers with concrete checks, implementation steps, typical pitfalls and tested fallback strategies.

Proxmox Hardening: refine the threat model: who, how and what to protect

A realistic threat model is the basis of any hardening. Ask at minimum: who needs GUI/API access? Which automation accounts use API tokens? Are management hosts reachable via VPN or directly? Also document attack vectors such as stolen API tokens, compromised jump hosts or lateral movement from a VM network.

Terms briefly explained: API (Application Programming Interface) is the programmatic interface; Corosync is Proxmox’s cluster communication protocol; Ceph is a distributed storage backend. If you understand these concepts, you will see why a locked-down GUI is of little use if cluster ports remain open.

Segmentation, Break‑Glass and Change Management

Clearly separate management, storage and VM networks

Separate management (GUI/API/SSH), storage (NFS/iSCSI/Ceph) and VM traffic into dedicated VLANs/subnets. This prevents compromised VMs from reaching the cluster or storage directly. Common pitfalls are shared bridges or missing VLAN tags on hypervisor bridges, which expose management IPs.

Break‑Glass and tested fallback paths

Define at least two fallback paths: local console/IPMI and a tested jump host with an Always‑Allow‑IP in the firewall. Before you enable Default‑DROP, document the steps to temporarily open access: pve‑firewall disable, adjust a firewall rule, redirect the SSH port. Practice these steps live once.

pve‑firewall: architecture, rules and secure activation

The pve‑firewall is a central building block for Proxmox Hardening. It operates on multiple levels – Datacenter, Node and VM/CT – and ultimately generates nftables/iptables rules on the hosts. Plan the rules in functional blocks: Cluster/Corosync, Storage, Management, Monitoring.

Corosync & Cluster communication

Corosync uses UDP ports for quorum and heartbeat traffic in standard installations (e.g. 5404/5405). If these connections are blocked by the firewall, nodes will fall out of quorum and services become unstable. Create rules that allow Corosync between cluster subnets, and test latency/packet loss with ping/iperf.

# Prüfen, ob Corosync läuft und UDP-Ports offen sind
systemctl status corosync
ss -uanp | grep -E '5404|5405'
# Testweise UDP-Pakete senden (nur in Lab/mit Absprache)
echo test | nc -u -w1 node2.example.org 5405

Allow storage accesses explicitly

Storage protocols use typical ports: NFS (2049), iSCSI (3260) and Ceph (Mon 6789, OSD 6800–7300). Open only the ports that your storage design actually uses. Ceph clusters often require bidirectional reachability between OSDs and monitors; an incomplete firewall configuration causes rebalance errors and high latency.

Practical sequence for activation

1. Inventory: ports, interfaces, DNS names.
2. Add rules: Cluster & Storage allow.
3. Restrict management stepwise: GUI/API/SSH only for admin sources.
4. Enable logging and rate limiting.
5. Set the default policy to DROP; monitor.

Firewall diagnosis and typical failure scenarios

Common symptoms after incorrect firewall configuration: cluster split, unclear quorum messages, aborted migrations or storage timeouts. Troubleshooting begins with service and network checks.

# Service- und Netzwerkstatus prüfen
systemctl is-active pveproxy pvedaemon pvestatd corosync
journalctl -u pve-firewall -n 200 --no-pager
ss -tulpen | sed -n '1,200p'
# Temporäre Deaktivierung für Test (Node-lokal)
systemctl stop pve-firewall || true

Always change rules in a controlled manner: use audit logs, record timestamps and the author. This makes it possible to trace the cause more quickly.

API and Web GUI hardening: TLS, tokens, MFA

The Proxmox API (pveproxy) enables automation and is functionally equivalent to the GUI — therefore it requires the same protective measures: encrypted transport, strong authentication, and network RESTriction.

TLS checks and monitoring

Check certificates regularly: expiration, SAN/DNS names, CA trust on admin clients. Avoid workarounds like „insecure_skip_verify“ in monitoring checks; if monitoring cannot validate, better certificate management is the solution.

# Zertifikat schnell prüfen
openssl s_client -connect pve.example.org:8006 -servername pve.example.org </dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

API tokens and least privilege

Use API tokens with limited rights for automation instead of personal passwords. Separate interactive admin accounts from service accounts. Tokens should be rotated and documented in change management.

# Beispiel: pvesh nutzt die API ohne separate Tokens zur schnellen Abfrage
echo 'Nodes:'
pvesh get /nodes

MFA and WebAuthn

Use two-factor authentication (e.g., TOTP or WebAuthn/U2F) where possible. MFA protects interactive sessions against stolen passwords; however, it does not replace network RESTrictions or token management.

SSH hardening and secure rollouts

SSH is a key access point. Hardening reduces brute-force attacks, improves auditability, and minimizes the risk from a compromised root account.

Stepwise implementation

1. Inventory: Which accounts use SSH? Where are authorized_keys located?
2. Mandatory: at least one functioning key account per node and an open console during testing.
3. Change configuration: PasswordAuthentication no, PermitRootLogin no, LogLevel VERBOSE.
4. Staged rollout: node-by-node, monitoring after each change.

# /etc/ssh/sshd_config (empfohlen, Auszug)
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
LogLevel VERBOSE
AllowGroups proxmox-admins

Always have a fallback: local console/IPMI can revert changes, otherwise administrative lockout may occur.

Fail2ban, IP RESTrictions and NAT scenarios

Fail2ban helps against repeated login attempts, but should be used with caution in environments with NAT or proxies where multiple admin users share the same IP. Create whitelist IP sets for jump hosts and automated monitoring endpoints.

# Fail2ban-Status prüfen
systemctl status fail2ban
fail2ban-client status sshd
# Beispiel: Whitelist in /etc/fail2ban/jail.d/proxmox.conf
# ignoreip = 10.0.0.5 192.168.100.0/24

Audit checks, drift detection and automated control

Hardening is not a one-time action. Automated audits detect configuration drift early and reduce the operational burden.

Essential checks (monthly)

• Patch level: pveversion -v and kernel revision.
• Open ports & listeners: ss -tulpen.
• Firewall status & default policy: pve-firewall status and nft list ruleset.
• SSH policy: sshd -T.
• Time consistency: timedatectl and NTP/SNTP logs.
• Backup-RESTore tests: full recovery in an isolated test.

# Basis-Checks als Skript (Auszug)
pveversion -v; uname -a
ss -tulpen
pve-firewall status
sshd -T | egrep 'passwordauthentication|permitrootlogin' || true
timedatectl status

Drift‑Erkennung und Change‑Protokoll

Use replication of /etc/pve (pmxcfs‑Filesystem) and log changes. A simple diff before/after maintenance prevents surprises. Forward journald‑logs to SIEM/central Syslog so audit events are not lost.

VMware‑specific notes (migration and operation)

Many Proxmox environments are in the context of VMware migrations. Hardening raises specific issues: disk conversion, network mapping and storage timeouts. Consider these points when closing management networks.

Typical VMware pitfalls

• Disk format: After qm importdisk or qemu‑img conversion, verify that VM‑disk UUIDs and SCSI adapters are mapped correctly.
• Network: translate vSwitch/DVSwitch concepts into bridges/VLANs — incorrect bridge assignment can expose management routes.
• Storage: iSCSI/NFS timeouts are common during migrations; open the necessary storage ports and, if required, temporarily increase timeouts during the migration.

Troubleshooting‑Tip: If networks are missing after migration, check ‚qm config ‚ and compare the bridge entries with the host‑bridge inventory (ip -br a).

Runbook: Phased hardening with test plan

A secure rollout includes tests, observation points and clear rollback steps:

1. Document current state (ports, services, storage topology).
2. Lab test: simulate rules in a test cluster.
3. Stage: apply rules node‑by‑node, enable monitoring.
4. Production: enable default‑DROP after 48–72h of successful operation.
5. Review: audit report and lessons learned.

Monitoring, logging and alerting

Collect system logs centrally, set alerts for Corosync losses, storage timeouts, pve‑firewall stops and repeated SSH failures. Alerts must be clear: e.g. Corosync Quorum Lost — initiate runbook.

Conclusion

Proxmox Hardening is an ongoing process with clear prioritization: segmentation, securing cluster and storage communication, gradual RESTriction of API/GUI/SSH and established audit controls. Plan each step with testing, monitoring and a documented rollback plan. Especially with VMware migrations and distributed storage it becomes apparent: incomplete firewall rules and unvetted SSH changes lead to outages faster than expected. Following the sequence and checks described here reduces risk without sacrificing operational reliability.

FAQ

Should the Proxmox‑GUI (Port 8006) be reachable from the Internet?

No. The Web‑GUI/API provide extensive management capabilities. It is better to make them reachable only from an isolated management network, via VPN or a jump host. If external access is unavoidable, it must be mediated by upstream protective layers (VPN, strong authentication, RESTrictive source networks, monitoring).

What happens when activating the pve‑firewall without preparation?

Cluster or storage traffic often fails because necessary rules are missing. Consequences are quorum warnings, stuck migrations, or storage timeouts. Therefore: first explicitly allow cluster and storage, then RESTrict management, and only set the default DROP at the end.

Is Fail2ban sufficient protection for Proxmox access?

Fail2ban is a useful additional layer against repeated failed attempts, but it does not replace network segmentation, firewall rules, or strong authentication. In NAT/proxy environments Fail2ban can even be problematic when many users are behind a single IP.

How do I harden SSH without locking myself out?

Before disabling password logins, ensure that at least one administrator account has key authentication. Use sshd -t to validate before RESTarting and keep a second session open. Test changes first on one node and roll them out in stages.

Which audit checks are most important in day-to-day operations?

Regular checks of patch level, open ports, firewall status, and SSH policy (no password login, no root login) are central. Additionally: NTP consistency, backup-RESTore tests, and auditable change logs (diffs in /etc/pve).

Operations, integrations and risks: extended perspectives

Beyond firewall, API, and SSH hardening, it’s worth looking at operational processes and integrations, because overlooked risks often hide here. Three areas are particularly critical: secrets management, certificate/firmware lifecycle and automated changes from CI/CD pipelines.

Secrets & Token‑Management

API tokens and service keys are powerful tools — but also attractive attack targets. Avoid long-lived tokens in plaintext configurations. Integrate your Proxmox automation into a central secrets vault (e.g. HashiCorp Vault or an internal PKI) and enforce token rotation as well as separation of roles.

# Example: list of API tokens (run locally only as admin)
pvesh get /access/tokens
# Use the result as a reconciliation list against your vault entries

Why: tokens can be exposed via backups, CI logs, or misconfigured playbooks. Risk: a compromised token allows automated VM actions without an interactive login.

PKI, certificates and rolling renewal

Centralized certificate management reduces outage risk from expiring TLS certificates. Plan rolling renewals so that not all nodes load new certificates at the same time — otherwise cluster communication loss may occur. Automate checks and alerts for expiry dates, not just manual spot checks.

# Certificate check across multiple hosts (excerpt)
for host in pve1 pve2 pve3; do
  echo "Checking $host"
  openssl s_client -connect ${host}:8006 -servername ${host} /dev/null | openssl x509 -noout -enddate
done

Firmware, Out‑of‑Band and IPMI/Redfish hardening

Management‑controllers (IPMI/Redfish) are independent attack surfaces. Segment OOB networks, enforce StrongAuth and maintain firmware updates via automation. Document Break‑Glass credentials separately from the standard inventory and test OOB recovery at least semi‑annually.

Automation, CI/CD and Change‑Control

When Playbooks execute Proxmox changes directly, tests and canary rollouts must be part of the process. Run synthetic checks (e.g., VM start/stop, storage mount) in staging and instrument rollbacks: Playbooks should be able to revert changes idempotently.

SLOs, Monitoring and Escalation

Define measurable SLOs for cluster health (quorum availability), storage latency and API response times. Alerts without clear runbook steps create noise; combine alerts with automated diagnostics (collect logs, pveproxy health, corosync status) and a clear escalation path.

These operationalizations close the gap between technical hardening and reliable operations: those who manage secrets, automate certificates and control changes reduce the residual risk significantly.

For this topic, Proxmox Firewall and securing the Proxmox API are also important. The article places these aspects in context and shows what matters in day‑to‑day operations.