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

[Dunuin]

Interesting. Thus far, I've been avoiding VLANs in an attempt to keep things simple.

In my head (so far) VLANs are a management thing (separation of concerns style), as they don't seem to offer any additional security.

As far as I'm aware, putting something in a vlan doesn't make its traffic magically "invisible" to sniffing over the wire. aka it's not IPsec

The traffic is still as unencrypted as it was before, unless the traffic is independently encrypted in some form (https/ssh/ssl/etc).

Is that the wrong way to look at it?

It adds security by isolation. It's not about encrypting traffic but isolating management from hosted services and splitting things in smaller DMZs.
You could also do that without VLANs, but then you need lots of additional NICs and switches if you want to isolate stuff physically.

 

[justinclift]

additional NICs and switches if you want to isolate stuff physically.

Ahhh yeah. That's more the approach I've been going with so far.

Sounds like once I have the initial set of tasks completed, I should circle back and have a proper go at learning VLAN usage.

 

[LnxBil]

I would just add: take care not to have any sort of VLAN tagging to be possible done by the VMs themselves.

Yes! Do everything on the switch, so that it is forced and only allow tagged packages to be received for non-management-related stuff. You will seldomly need vlan tagging on the VMs itself, at least not in my 3-layer example.

 

[LnxBil]

I think the OP's concern is relevant in the sense that there really is no FAQ section how to run PVE "professionally" whatsover. At least I do not know of any assumptions page at the least. Then people make lots of assumptions of their own, every time new forum post...

Is this available for any OS or hypervisor? I'm never seen this before. It's just an "it depends" topic IMHO.

 

[esi_y]

Yes! Do everything on the switch, so that it is forced and only allow tagged packages to be received for non-management-related stuff. You will seldomly need vlan tagging on the VMs itself, at least not in my 3-layer example.

I think if the OP had no 802.1q experience, this specific wording would come out confusing as hell. But I believe you meant to say that only the host should be on the native VLAN and everything received as tagged should be hitting the VMs transparently untagged.

Ad Seldomly ... well, suppose he wants to have some management only access to the container itself. But these are all network topics and stacked VLANS would only make it worse in the thread.

 

[esi_y]

Is this available for any OS or hypervisor? I'm never seen this before. It's just an "it depends" topic IMHO.

This might be a philosophy issue, but PVE is the only hypervisor that got traction as some kind of homelabbers dream. I would dare to say that Proxmox was not at all unhappy to nurture it.

In return, there's lots of free testing they get from the community. Now the question is, should they bother at least to publish something for the inexperienced users after they have seen all the posts about exposing their management interface on WAN, etc.? I would wonder how much a port 22 scan that allows password'ed root login attempts (of the whole public IPv4 space) would be PVE installs.

Remember times when some packages installed with default security all off or admin/admin credentials? How many do it nowadays?

NB Broadcom made it very clear where it sees its customer base after the acquisition, so they can afford (pun intended) to say that that's for the in-house infosec personnel to deal with, out of their scope.

 

[Dunuin]

Other thing would be disabling KSM, which is enabled by default, to not leak data: https://forum.proxmox.com/threads/ksm-sharing-security-implications.104261/

 

[LnxBil]

I think if the OP had no 802.1q experience, this specific wording would come out confusing as hell.

Oh yes, you're right. VLAN can be a steep learning curve.

In return, there's lots of free testing they get from the community.

Yet if there is no reporting back, it might just not be that useful after all. DIY / homelabbers are not the main target audience and Proxmox does not need the same noise again and again about how to configure disks, where the ram went and temperature display.

Now the question is, should they bother at least to publish something for the inexperienced users after they have seen all the posts about exposing their management interface on WAN, etc.?

Good question, I would not if I would be in their shoes.

 

[esi_y]

Yet if there is no reporting back, it might just not be that useful after all.

This is actually the weird part to me, many times there's the the same issues raised in the forum, but even if it's genuinely a bug, no one creates a proper report. But I was mostly getting at the situations that PVE can be released without much testing into the wild no-subscription (i.e. beta) repo and the really breaking issues come up back reported for free (at the cost of someone unsuspecting homelab user) immediately.

DIY / homelabbers are not the main target audience and Proxmox does not need the same noise again and again about how to configure disks, where the ram went and temperature display.

There's a fine line between having the unpaid tester feel like the product is exactly what they need for their homelab (what other incentive is there left, after all) and antagonising them by criticising their skillset in the absence of basic FAQs.

Arguably, the FAQs might decrease the support load (includes reading through the forum even), partially, nowadays it might even pop up as some AI suggested answer before one finished typing.

Good question, I would not if I would be in their shoes.

I would humbly submit that improving documentation (including what is out of scope and why) lowers the cost of support and improves PR, what's not to like. Otherwise there's absurd situations where someone is borderline criticised for using the product wrong because of their lack of experience (in the absence of official documentation), but you had lured that someone to be your free tester to begin with. It's a price to pay on both sides.

 

[justinclift]

no one creates a proper report

Maybe they don't have a support subscription?

 

[esi_y]

Maybe they don't have a support subscription?

That's the thing! This is actually FREE!

https://bugzilla.proxmox.com/

 

[LnxBil]

Arguably, the FAQs might decrease the support load (includes reading through the forum even), partially, nowadays it might even pop up as some AI suggested answer before one finished typing.

I'm hoping for that. So many problems would just be solved by a proper FAQ that is AI maintained, because there are a lot of FAQ as previously stated.

I would humbly submit that improving documentation (including what is out of scope and why) lowers the cost of support and improves PR, what's not to like.

Problem with this assumption is that we don't know what people ask the Proxmox support in their support tickets. It's a different system and we don't see it. Maybe someone from Proxmox can chime in here ...

This forum is nowadays full of first-time PVE users that ask the same question again and again (therefore AI would help). I also see this on reddit. Those people are normally not paying for PVE so doing something exclusively for them is not a good idea from a business point of view. Yes, there are the admins that want to peak in their free time and then buy licenses for their enterprise ... yet enterprises often just ask a consultant to spin things up and they get a shining new and working PVE cluster and start migrating. This is true for any hypervisor (or software) and any enterprise I worked for. If they have problems, they create Proxmox support tickets.

Yet, I feel your need for better documentation, but more for the volunteer people like us here, so that we can just reference stuff ... most of them not at all PVE related like:

• how memory is used in Linux and why my VM uses more ram than shown inside of the VM (at least once a week this is asked)
• best ZFS setup with or without L2ARC, additional metadata special devices and SLOG
• how to share files between VMs
• best backup strategy of files inside of my docker in my VM
• how to build "the best setup" with what I have ...

Otherwise there's absurd situations where someone is borderline criticised for using the product wrong because of their lack of experience (in the absence of official documentation), but you had lured that someone to be your free tester to begin with. It's a price to pay on both sides.

Isn't that the case for almost everything? Look for example on Windows Server with Hyper-V, on which you can also install other software and work with it and none of those cases is part of the Hyper-V documeentation. This is the same for PVE. There are Debian forums and tutorial available that cover this and sometimes also non-distribution specific Linux tutorials. This is especially true for the hardening part, which is mostly just a "simple linux hardening problem".

 

[justinclift]

That's the thing! This is actually FREE!

https://bugzilla.proxmox.com/

Ahhhh, I wasn't aware that bug reports filed from non-subscribers would be looked at.

Bugzilla (the software) though I've used before with other projects.

 

[justinclift]

by a proper FAQ that is AI maintained

How about one that's accurate instead?

 

[LnxBil]

How about one that's accurate instead?

There are also many human contributers on the forums that hallucinate sometimes ... yet I get your point.

 

[LnxBil]

Ahhhh, I wasn't aware that bug reports filed from non-subscribers would be looked at.

I got a couple of feature requests included in the last 10 years, so yeah ... they get looked at.
You can also send in patches, yet you need to sign a legal document in order to get them accepted.

 

[esi_y]

How about one that's accurate instead?

Just to be clear, I personally meant FAQs (human made) that the AI uses to e.g. notify the new user not to re-ask the same thing and avoid the "noise".

There are also many human contributers on the forums that hallucinate sometimes ... yet I get your point.

Yet there was this one time when I actually took the effort and made a well structured reply all with annotations and someone came back at me if I just spit out ChatGPT at them...

Problem with this assumption is that we don't know what people ask the Proxmox support in their support tickets.

I was actually just trying to address the part of having the "noise" on the public forum, if the public forum is becoming "spammed" with something of little use to the paid support then it becomes either irrelevant for the maintainers or turns into a community forum.

Those people are normally not paying for PVE so doing something exclusively for them is not a good idea from a business point of view.

But again, if the "background noise" can be suppressed with a good PR action, why not do it? The forum then becomes valuable source for the maintainers too.

There are Debian forums and tutorial available that cover this and sometimes also non-distribution specific Linux tutorials. This is especially true for the hardening part, which is mostly just a "simple linux hardening problem".

I have one issue with this given some of the situations I have seen on this forum. PVE is Debian, but then it's doing some of its things in a weird way (apt upgrade and dist-upgrade comes to mind). And then the networking part where one might easily e.g. filter corosync traffic while "hardening" their HA cluster.... I do not think it's wrong for people to come ask here first before they are told "so this one you can follow the Debian (or be more realistic, Ubuntu) tutorial, especially where there's no word on it in the "official docs". Then again, I was told here before things like "oh but you are referencing RHEL corosync man page, we are using PVE" from staff...

 

[justinclift]

Well, as an example of the kind of thing I'd expect in a hardening guide for Proxmox:

• Use LISTEN_IP in /etc/default/pveproxy to control which interface or IP address the Proxmox web interface and spice proxy listen on
  • Don't use the alternative approach of using ALLOW_FROM, DENY_FROM, and POLICY. The implementation of these has been buggy and non-functional before, and may happen again.
• While firewalling your VMs using the Proxmox firewall is a reasonable idea, also make sure to use an OS provided firewall for good measure.
  • Ye old "defensive in depth" approach, just in case something goes wrong with the Proxmox firewall

Those are just examples, but are the kinds of things I'd expect from a Proxmox oriented doc rather than Debian (etc).

ie Proxmox specific things to do. The first of the two up there wouldn't really make sense for a non-Proxmox target

 

[alexskysilk]

As a general thought, I'm wondering if an official Proxmox Hardening wiki page would be useful?

Its a good idea, BUT not really necessary.

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. To make it simple, the entire strategy of securing a resource is by limiting access to only those who need it (default: deny) at every layer of approach, actively monitor access, and regularly review/change the access control tokens.

VLANs are your first line of defense to limit access- its a layer2 technique so very low down the OSI model. only mac addresses that are explicitly allowed (either by port mapping or ACL) are allowed so credentials dont event come into play yet. VLANs allow you to split your networks without needing individual NICs, so you can keep your management api interface separate from your guest networks.

Layer3 firewall comes next; you can either use the PVE built in firewall for the purpose or an external one.

The one thing that pve really doesnt like is passwordless root, so you'll need to live with allowing that but as long as you follow access limits principles and token (password) recycling policies you should be fine. you can still use keys for ssh access anyway.

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

 

[Dunuin]

How about one that's accurate instead?

Some AI reading new threads before they are finally posted and showing a list of existing threads about the same topic the OP is writing about might be useful. If the AI points him to existing answers contributed by humans, this would save the time of the OP because he doesn't need to finish writing his thread if he already found the answer and the forum will be spammed less with the same question over and over.