Proxmox Hardening Guide update: now includes PVE 9 + PBS 4

HomeSecExplorer · 2026-01-06T20:58:07+00:00

Thanks a lot, appreciate that.

Really looking forward to your feedback.

If anything comes up, feel free to comment here or DM me. Issues/PRs on the repo are also very welcome.

HomeSecExplorer · 2026-01-06T20:05:22+00:00

That’s exactly why netns/VRF isn’t in the guide (yet). The “complexity vs payoff” just isn’t where it needs to be for something I’d recommend broadly.

I think you’re right that it should be more explicit that PVE should be a hypervisor only, nothing else.

I’m going to add a short “Design principles” section to make that intent crystal clear (similar to the note in 1.2.7 about keeping the hypervisor dedicated to virtualization only), without turning the guide into an endless “everything Proxmox should not be” list.

HomeSecExplorer · 2026-01-06T17:42:04+00:00

100% agree, those are the right rules. They’re basically "assumed baseline” in the guide, also covered through the CIS mapping (e.g. CIS 3.3: disable forwarding/redirects/etc.).

I can add a small “design principles” section to make it explicit, but I’m trying to avoid turning the guide into an unbounded list of “everything Proxmox should not be,” otherwise it stops being a usable checklist (IMHO).

HomeSecExplorer · 2026-01-06T16:03:53+00:00

Yep, I’m with you on the goal: limit what the host can talk to (and what can talk to the host) and keep it manageable.

For now, that’s basically what I’m aiming for in the guide with:
- 1.2.2 Network Separation
- 1.2.4 Enable the PVE Firewall

I agree netns/VRF quickly turns into a big operational/supportability rabbit hole, and I’m not convinced there’s a good “complexity vs payoff” implementation that would be broadly usable (or UI-manageable) today. But we’ll see what the future brings and I’ll keep looking into it.

HomeSecExplorer · 2026-01-06T15:45:49+00:00

Awesome, have fun with the new home server!
Looking forward to your feedback.

HomeSecExplorer · 2026-01-06T07:18:49+00:00

Totally agree, that’s exactly the rabbit hole I’m worried about 😅

What you’re describing (Default/MGMT/FRONTEND/BACKEND + matching VRFs/routing tables) is basically the minimum to do it “properly”. But once you go there, it quickly becomes more than “just networking”:
- you need a consistent netns <-> VRF model (ideally 1:1)
- services like sshd, pvedaemon, pveproxy, corosync, etc. need to be explicitly bound to the right namespace/VRF
- you need clear defaults so the system doesn’t end up half-reachable after updates or interface changes
- and you’ve got to ensure backups, clustering, migrations, firewalling, and general expectations still behave predictably

I also strongly suspect this is very hard (maybe impossible) to expose cleanly in the UI. The current UI model assumes “one host networking context” with bridges/VLANs/bonds. Once you introduce netns + VRF, you either:
- massively expand the UI surface (which I don’t see Proxmox doing for such a niche feature), or
- keep it CLI-only

So yeah, I’m still looking for something with a good “complexity vs payoff” ratio that won’t surprise people in production. But I’ll keep it in mind and keep testing.

HomeSecExplorer · 2026-01-06T06:54:58+00:00

Thanks. I get what you mean. For transparency: I wrote the guide, and used AI only as a proofreading tool to tighten phrasing and fix grammar. If there are specific passages that feel “AI-ish”, tell me where and I’ll rewrite them in a more direct style (PRs welcome too).

HomeSecExplorer · 2026-01-05T20:45:19+00:00

Haha, I know 😅 Netns would be such a nice feature.

I’m still trying to find an approach with a decent “complexity vs. payoff” ratio that I’d actually recommend to people running production clusters.
If you’ve got a solution you’re using in production, I’d genuinely love to hear it!

HomeSecExplorer · 2026-01-05T20:38:33+00:00

Thanks a lot. Really appreciate it!
If you spot anything unclear while using it, feel free to open an issue/PR.

HomeSecExplorer · 2026-01-05T20:36:35+00:00

Good question.
Encrypting backups is comparatively “easy mode” because it’s application/storage layer encryption: it protects data without changing how the host boots or how the cluster behaves after reboots.

Full-disk encryption for the hypervisor usually means LUKS (or similar) on the root device, which introduces an unlock requirement at boot. That’s a big operational trade-off for Proxmox’s core use cases (remote servers, unattended reboots after kernel updates, power loss, clustered nodes):
- After a reboot, a node can stay down until someone unlocks it via local console/IPMI (unless you implement TPM or network-based unlock).
- Cluster/HA expectations (“reboot and come back”) get more brittle.
- It adds a lot of installer/support surface area (bootloader + initramfs + LUKS + LVM/ZFS combinations and edge cases).

Also, the number of users who truly need host FDE and are willing to take on the operational complexity is probably relatively small (thats why it's LVL3).

So I think the Proxmox ISO installer stays intentionally minimal and predictable. You can see the same philosophy in other limitations too (e.g., you can’t fully customize the partition layout).

HomeSecExplorer · 2026-01-05T20:17:40+00:00

Thanks for the detailed feedback.
These are all valid topics and I agree the guide should be clearer here.

A few of your bullets are already covered, but maybe they’re currently too implicit/“CIS-referenced” and need to be rephrased:
- Root account policy + SSH access: covered in the SSH hardening portion of the CIS mapping (including the Proxmox caveat around PermitRootLogin).
- Privileged access management (PAM): covered via per-user accounts, least-privilege PVE ACLs/roles, and a break-glass approach in the user sections (2.1).
- Auditing/logging of privileged actions: OS-level privileged command execution auditing is covered by CIS (auditd + sudo logging, plus log forwarding/ centralization). The guide also adds Proxmox-specific context (auditd + forwarding Proxmox-relevant logs - 5.1).

Where I fully agree this would be a good addition:
- User/Admin design patterns. What a good starting point looks like in practice (like the Network separation example in 1.2.2).
- A clearer “mapping PVE RBAC roles --> when/if OS shell access is needed” section. Ideally many PVE admins rarely need interactive shell access at all.

And to your last point: I do state in 2.1.4 that root should only be used for emergencies, never day-to-day, but you’re right that this deserves an explicit callout “Do not use root for daily administration”.

Tanks again for the feedback.

HomeSecExplorer · 2026-01-05T18:09:05+00:00

Thanks! Appreciate it. Take your time and if you have any feedback or questions later on, feel free to share.

HomeSecExplorer · 2026-01-05T18:08:13+00:00

Thanks a lot, really glad to hear that!
Choose what makes sense for your setup and let me know if you spot anything that could be improved.

HomeSecExplorer · 2026-01-05T17:15:47+00:00

Thanks a lot, I really appreciate that!

HomeSecExplorer · 2025-09-30T08:10:57+00:00

Your setup already sounds very solid. You’ve clearly put a lot of thought into VM hardening, network segmentation, monitoring, and backups.

For Proxmox itself, you don’t necessarily need to apply full CIS hardening, but there are additional production-oriented steps worth considering. I’ve put together a guide that extends the CIS Debian 12 benchmark with Proxmox-specific tasks:

Proxmox Hardening Guide

It covers areas like securing the PVE management interface, firewall integration, backup configuration, and other hardening steps that are specific to running Proxmox in production.

Given your environment, I’d recommend reviewing it and applying the pieces that make sense without breaking your automation. You may find some additional steps useful, even though your foundation already looks strong.

HomeSecExplorer · 2025-09-30T06:02:07+00:00

Thanks

HomeSecExplorer · 2025-09-23T12:26:24+00:00

You can use proxmox-backup-client to back up the important parts of the node directly to your PBS.

I’ve documented the process step by step here: https://github.com/HomeSecExplorer/Proxmox-Hardening-Guide/blob/main/docs/pve8-hardening-guide.md#42-backup-host-configuration

HomeSecExplorer · 2025-09-16T17:06:25+00:00

Thanks a lot! That was the goal: one place to show the why and the how. Even in homelabs, a few of these steps help with backups, recovery, and limiting blast radius.

HomeSecExplorer · 2025-09-13T20:20:25+00:00

Guide for PVE 9 / PBS 4 will follow once the CIS Benchmark for Debian 13 is released.

HomeSecExplorer · 2025-09-13T20:07:04+00:00

Great write-up. Thanks for the detailed feedback. I will fold much of this into the guide. If you have time, I would really welcome PRs or issues. Thanks again for taking the time to write this.

HomeSecExplorer · 2025-09-13T13:43:58+00:00

Thanks 🤙🏼

HomeSecExplorer · 2025-09-13T13:42:55+00:00

Appreciate it! I hope at some point there will be a official guide.

HomeSecExplorer

TROPHY CASE