Proxmox server hardening document for compliance

[bsinha]

We are running couple of VMs in production server on a 3-node cluster using Proxmox and ceph.

Now few auditors are requesting for a guideline for hardening the proxmox installations, since we are running the vms in production.

We used the iso files of the Proxmox ve and Proxmox backup server to install them on bare metal nodes.

The default installation seems to be pretty hardened already. Additionally, we restricted the management connection to be opened on different port other than 8006 and 8007. And we did not allow the ssh from the internet.


Now my question is, what hardening guideline should we produce to the auditors? And what additional measures could we take to harden the system further?

 

[weehooey]

A big part of hardening on any platform is to change default configurations to something more secure. You are right, they both start fairly secure.

• Install sudo
• Create and user non-root users
• Enforce TOTP (TFA) in the GUI on all accounts
• Ensure TLS certificates for the GUI
• Harden ssh (guides available online)
• Enable and use PVE firewall
• Ensure hosts are on separate networks from the guests
• Isolate internal networks that do not need external connectivity. I.e corosync, Ceph backend, migration.

This plus these additional items for PBS:

• Separate network from PVE. Only allow PVE over 8007.
• Create a PVE backup user and token with minimal permissions. This token is what is used on PVE to connect to PBS.

 

[itNGO]

We are running couple of VMs in production server on a 3-node cluster using Proxmox and ceph.

Now few auditors are requesting for a guideline for hardening the proxmox installations, since we are running the vms in production.

We used the iso files of the Proxmox ve and Proxmox backup server to install them on bare metal nodes.

The default installation seems to be pretty hardened already. Additionally, we restricted the management connection to be opened on different port other than 8006 and 8007. And we did not allow the ssh from the internet.


Now my question is, what hardening guideline should we produce to the auditors? And what additional measures could we take to harden the system further?

We are currently testing hardening-script from ovh-cloud. https://github.com/ovh/debian-cis
Using Level 3 on a PVE-Server and for now it looks like it is still running normal but far more "secured".

Would be really nice to have some more guides or a "more" secured default Proxmox-Install.

Currently it scored very bad when checked with "Center for Internet Security Debian Family Linux Benchmark v1.0.0" from Wazuh.

And with NIS2 coming, this might be a real problem for many companies using PVE....

 

[LnxBil]

We're also running an additional proxy between PVE and users using it, so that the actual pve hosts are not accessible at all.
This can be done with a reverse proxy with sticky cookies.

In addition (and just to mention):

• run management ports in its own, separated network - same for ethernet/san switches, UPSs etc.
• segment as much as possible with additional VLANs or SDNs
• consider using Keycloak or similar to secure it even further
• have seperate users/roles for actua admin work and day-to-day usage (e.g. admin with multiple roles)
• never work as root (also for PVE, not just guests)
• PVE firewall has a very nice feature: security groups. I cannot stress enough how good this is. Apply to each VM and you're golden.
• have a monitoring check inside of your VM that checks if the default firewall security group is applies so that you don't miss any (we have this with a special json endpoint that should not be reachable if we have enabled our default virtual dmz security group to the VM)