Should an official Proxmox "Hardening" wiki page be created?

[esi_y]

Security as applicable to a pve environment isnt really any different than any other virtualization platform, which means any hardening policies that would be best practices generically or even specifically to another platform (eg, vmware) would be just as applicable here.

I would say this is overly broad statement. On the opposite extreme side of the spectrum, I could state that if one truly wants mitigations, layers of separation, etc. ... just forget the whole KVM (let alone LXC) and go with Xen. So platforms-wise this part differs. Of course it impacts e.g. performance.

For the rest regarding networking, that would be true, but then again if it was a serious take, the firewall needs to be on a separate hardware box. Then you could continue adding up IDS, etc. if those VMs are really exposed to the outside.

BTW What did you mean specifically about the issues with passwordless root?

 

[alexskysilk]

just forget the whole KVM (let alone LXC) and go with Xen.

Source benchmarks would be good here. I dont think they will bear out that statement.

BTW What did you mean specifically about the issues with passwordless root?

there are a number of api calls that only work when called by root. the api mechanism requires a password.

 

[esi_y]

Source benchmarks would be good here. I dont think they will bear out that statement.

About monolithic vs micro-kernel architectures' differences?

there are a number of api calls that only work when called by root. the api mechanism requires a password.

Will have to try what crashes, this is new to me!

 

[justinclift]

The one thing that pve really doesnt like is passwordless root

I don't think I've ever seen a production installation allowing "passwordless root", unless I'm misunderstanding the meaning?

To me, a "standard" ssh installation doesn't allow root logins remotely using a password. Instead it mandates ssh keys.

Proxmox seems completely fine with that approach, so I've not really though about it more.

Is "passwordless root" different to that?

 

[justinclift]

Some AI reading new threads

Ahhh. You're saying "AI" but it seems like you're meaning "some automated job".

There have been tools available for doing this kind of thing (reasonably well) for years, though they're not present on this forum.

I have no real exposure to the install/maintenance requirements for such a tool, so it's totally possible they're more trouble then they're worth in their pre-AI form(s).

 

[justinclift]

I remember a discussion on this topic where staff told it's fine to disable SSH root logins via password. You just have to temporarily enable it again once you need to do specific actions like a cluster join

That's a good point. I might be mis-remembering things from being used to the cluster being set up for several weeks now. Not super sure about the default out-of-the-box behaviour.

 

[esi_y]

I don't think I've ever seen a production installation allowing "passwordless root", unless I'm misunderstanding the meaning?

I believe this was meant passwd -l root, nothing to do with SSH.

To me, a "standard" ssh installation doesn't allow root logins remotely using a password. Instead it mandates ssh keys.

I think prohibit-password for root in the sshd_config works just fine. I don't know why PVE does not ship like that, it would be another "historical reason" ...

EDIT: I just realised I was making a play on the "historical reasons", but that was a different thread. There's simply lots of these "unexplained" mysteries in how PVE ships by default or what it depends on:
https://forum.proxmox.com/threads/w...-resolvable-via-etc-hosts.148760/#post-673043

 

[esi_y]

That's a good point. I might be mis-remembering things from being used to the cluster being set up for several weeks now. Not super sure about the default out-of-the-box behaviour.

Or just manually add your pub to authorized_keys in the other machine. Or use SSH certificates for all your machines everywhere as everyone should, but PVE staff has had an opinion on that before ...

 

[LnxBil]

I think prohibit-password for root in the sshd_config works just fine. I don't know why PVE does not ship like that, it would be another "historical reason" ...

That may be easier than you may whink: how would you add a SSH key easily without being able to login?

 

[esi_y]

That may be easier than you may whink: how would you add a SSH key easily without being able to login?

I might have misunderstood this remark, but (sadly) the only official way to install PVE is with the ISO, there's no PXE or fancy remote unattended way, so for most, this practically means OOB install. So quite simply, the thing may as well ship without any means of logging in via ssh upon fresh install. At least it would force one to add their key on first boot. Of course a real enterprise solution would have a normal ssh certificates setup, etc.

 

[justinclift]

how would you add a SSH key easily without being able to login?

By having an extra field in the cluster joining GUI for pasting in a public key.

 

[guletz]

Hi,

Hardening, for any OS is not a trivial task. A wiki will be useful for most of the users. But it will be a dificult task, because are n situastion and use case like(only few...):
- home user single PMX server
- test lab(including cluster setup)
- single PMX setup with remote access
- cluster setup with remote acces
- setups with shared storage(nfs, smb, iscsi, ceph)
- setups with ruter/fw VM in PMX(like pfsense, ipfire, and so on)
- some recomandation about network devices in contex of PMX(like, you do not have a vlan-aware switches, but you can use vxlan via SDN)
- some short description about usefull tools in the PMX context like: remote logs, log analisers, monitor tools, ids/ips, fail2ban and many others

Another important topic is about PMX installer:
- IMHO I think it it easy to present some supplimentary options, like many partitions(/var/log, /tmp, /var/tmp, and others) with options(noexec, nosuid, nodev, etc)

And not last, how to make a simple risk analises (few principle, with some examples).

And as I see many other forum colegues, have write about others good ideas ....

Hardening, without context(like admin skills) of the IT lanscape is very hard to do it!

Good luck/Bafta !

 

[LnxBil]

By having an extra field in the cluster joining GUI for pasting in a public key.

for example, yes ... yet it's not there at the moment.

 

[esi_y]

I once created a series of bug reports relating to SSH, long story short, in most cases the answer was that long-term, there would be tendency to completely abandon SSH dependency for PVE (this was repeated many times in the threads, most reasonably in [1]. This of course does not do anything for security, but it reveals how PVE approaches it [2]. Nothing is being done either way, most comfortable answers rely on set of assumptions (includes gaslighting [3] and putting the burden on the user [4]).

At some point I thought, ok, the team is so tiny (most answers from 2-3 people) that they need to focus on only the most essential stuff, yet when they supposedly fixed the mind-boggling 10-year+ resident bug in SSH join, they broke other things in return and pushed it to the beta repo [5].

After about these 20-odd filed bugreports, I remember I stopped it all after I realised there's still 2 people calling the shots on everything despite being completely clueless [6], so much for community development effort.

I stopped everything, this and the topics like no real SLA support for actual enterprise use just made me run away to other solutions where security actually matters. It's a great homelab thing, it will sustain itself through limited growth subscriptions of who knows what demographic. That said, I wish every single open-source project success. I know I can fork it. There's a reason no one does that (for a living).

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=5174
[2] https://bugzilla.proxmox.com/show_bug.cgi?id=5061
[3] https://bugzilla.proxmox.com/show_bug.cgi?id=5215
[4] https://bugzilla.proxmox.com/show_bug.cgi?id=5060
[5] https://forum.proxmox.com/threads/o...h-known_hosts-bug-s.137809/page-4#post-674046
[6] https://lists.proxmox.com/pipermail/pve-devel/2024-February/061751.html

 

[LnxBil]

I know I can fork it. There's a reason no one does that (for a living)

PVE has been ... ehm ... "forked" or copied already.

 

[esi_y]

PVE has been ... ehm ... "forked" or copied already.

 

[esi_y]

... looking at it including the screenshot, isn't this just a "white-label" use? I mean, forking would be having own development branch.

I mean, isn't it hilarious, there's every single logo on that website EXCEPT for Proxmox...

 

[justinclift]

Wow, that's weird. They even picked a name with "ovirt" in it, which is a different (OSS) virtualisation solution.

 

[esi_y]

Wow, that's weird. They even picked a name with the "ovirt" in it, which is a different (OSS) virtualisation solution.

They offer 24/7 SLA and 4 tiers at that, for open source solutions. I mean, sure, the reasons are stated on their very site:
under //import-substitution/

 

[esi_y]

Last but not least- monitor cve's and be diligent with upgrades.

Here it is from the horse's mouth:

https://bugzilla.proxmox.com/show_bug.cgi?id=4579#c3