Security Hardening

[deepcloud]

We have seen recent Ransomware attacks on vSphere ESXi Hypervisors and are very concerned about Proxmox being targeted too.

We are planning on doing the hardening of Proxmox hosts and implementing a security audit using lynis.

During the course of this audit I am sure to hit many roadblocks and will seek help and guidance here in this thread.

Any recommendations on protection of the Proxmox hosts, any Antivirus recommended, like Eset, Kaspersky Hybrid Cloud Security or anything else better ?

Any other suggestions like App amour with a list of only ceph and proxmox services being whitelisted and locked down

Thanks in Advance

 

[leesteken]

This section of the PBS documentation might interest you: Ransomware Protection & Recovery.

 

[Dunuin]

I also remember a case where the BMC was publicly available and vulnerable so the PVE host got hit by ransomware that way. So don't forget the BMC as a backdoor and not only focus on PVE itself.

 

[LnxBil]

Any recommendations on protection of the Proxmox hosts, any Antivirus recommended, like Eset, Kaspersky Hybrid Cloud Security or anything else better ?

Oh boy .... this is a money-maker ... those tools are either total useless or will slow down everything so much that you won't work with your infrastructure. And "security" - for a security-minded-person is to NOT USE ANY CLOUD AT ALL, so why would I build a reverse tunnel to any shady company that's claiming they securing my infrastructure with some hybrid cloud security stuff? Get proper software for your ingress and egress points that does e.g. deep packet inspection, proxy, mailfilter and stuff like that and properly secure your hypervisor (that's why we're here).

For PVE this means (some points have been said before):

• Have a good PVE firewall at datacenter level. If your PVE boxes and BMC cannot be reached, they cannot be attacked and any audit will yield nothing. We use it all the time to shield legacy from auditors ... and everyone is happy.
• PVE has also this very nice feature of security groups, that can be applied to each VM turning them into single-host-DMZs, which is one of the big security selling points of PVE.
• have a proper management lan with a lot of loops to jump through for admins, they're attacked first. Consider e.g. using hardened VPN inside of your company for the management LAN.
• scheduled updates (OS, firmware)
• proper backup strategy including backup hardware for a self-sufficient restore outside of your current infrastructure, maybe regular restore tests
• good backend storage with regular out-of-band snapshots to easly restore on ransomware attacks (e.g. ZFS over NFS or iSCSI), can also combined with replication
• SSO on PVE with a short retention / lifetime
• sounds maybe a kind of weird, but use management machines that have exotic operating system to reduce the attack surface, e.g. *BSD, Plan 9, etc.
• This pains me to say, but disable SSH for administrators and use a machine that only has GUI access, e.g. via PVE VNC console and do everything administrative from there (maybe also using 4-eye-principle). It's harder to get this hacked and is the IT-form of galvanic separation.

 

[deepcloud]

Oh boy .... this is a money-maker ... those tools are either total useless or will slow down everything so much that you won't work with your infrastructure. And "security" - for a security-minded-person is to NOT USE ANY CLOUD AT ALL, so why would I build a reverse tunnel to any shady company that's claiming they securing my infrastructure with some hybrid cloud security stuff? Get proper software for your ingress and egress points that does e.g. deep packet inspection, proxy, mailfilter and stuff like that and properly secure your hypervisor (that's why we're here).

For PVE this means (some points have been said before):

• Have a good PVE firewall at datacenter level. If your PVE boxes and BMC cannot be reached, they cannot be attacked and any audit will yield nothing. We use it all the time to shield legacy from auditors ... and everyone is happy.
• PVE has also this very nice feature of security groups, that can be applied to each VM turning them into single-host-DMZs, which is one of the big security selling points of PVE.
• have a proper management lan with a lot of loops to jump through for admins, they're attacked first. Consider e.g. using hardened VPN inside of your company for the management LAN.
• scheduled updates (OS, firmware)
• proper backup strategy including backup hardware for a self-sufficient restore outside of your current infrastructure, maybe regular restore tests
• good backend storage with regular out-of-band snapshots to easly restore on ransomware attacks (e.g. ZFS over NFS or iSCSI), can also combined with replication
• SSO on PVE with a short retention / lifetime
• sounds maybe a kind of weird, but use management machines that have exotic operating system to reduce the attack surface, e.g. *BSD, Plan 9, etc.
• This pains me to say, but disable SSH for administrators and use a machine that only has GUI access, e.g. via PVE VNC console and do everything administrative from there (maybe also using 4-eye-principle). It's harder to get this hacked and is the IT-form of galvanic separation.

thanks @LnxBil

 

[deepcloud]

Should we not look at securing services on Proxmox

systemd-analyze security - gives out most as unsafe... any ideas

 

[LnxBil]

Should we not look at securing services on Proxmox

systemd-analyze security - gives out most as unsafe... any ideas

It's all running as root without a sandbox, what would you expect? As long as you're not exposing any service on the network, it does not matter that much. There are normally no ordinary users running stuff on your PVE host, so this is generally not so bad.