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

[esi_y]

After more recent discussions (firewall related), I decided to file this one:
https://bugzilla.proxmox.com/show_bug.cgi?id=5816

Not sure if it will be taken up, but I consider it a huge omission not even have this recorded as a valid request.

 

[justinclift]

Cool. Yeah, I also still reckon documenting the right way of securing (and keeping secure) an internet facing Proxmox install would be extremely useful.

From my point of view, the most critical aspect is to adjust the configuration so listening services only listen on an internal interface (eg cluster interface), with the exception of ssh which needs it's own special attention (eg firewalling or whatever).

That's the main approach I'm using with my internet facing Proxmox cluster. Accessing the webUI is just a matter of defining appropriate mappings in my local (client side) ssh config so it knows to ProxyJump the ssh connection to the correct internal interface of the remote server.

That's working decently well in practice over a few months.

 

[esi_y]

with the exception of ssh which needs it's own special attention (eg firewalling or whatever).

That's the main approach I'm using with my internet facing Proxmox cluster. Accessing the webUI is just a matter of defining appropriate mappings in my local (client side) ssh config so it knows to ProxyJump the ssh connection to the correct internal interface of the remote server.

I am not sure if I understood this correctly, but I would advise against exposing anything to the public, even firewalled, even IP based (see e.g. the heated discussion in the firewall bug, even Proxmox do not expect you to open services to the public - before I get accused of anything, the discussion was about 8006 pveproxy, but I believe this must be for any service, including SSH). If you have a bastion host for that SSH, that's fine, but I personally would prefer no machine with SSH exposed, at all (this is not only for PVE, any machine).

 

[justinclift]

In my setup, ssh is firewalled to only allow incoming connections from admin ip addresses (ie static ips).

How is that expected to go wrong?

 

[esi_y]

In my setup, ssh is firewalled to only allow incoming connections from admin ip addresses (ie static ips).

How is that expected to go wrong?

Are the static IPs public?

 

[justinclift]

What do you mean by "public"?

 

[esi_y]

What do you mean by "public"?

Well if those are routable IPs, then you are filtering what is coming to you from the Internet, based on the headers of the packets that arrive from "out there" and they claim to be coming from those addresses. But you do not control the Autonomous System you are in, do you?

 

[justinclift]

Well, I think anyone who's wanting to muck with BGP or similar routing protocols to spoof one of the admin's IP addresses... probably has more important targets.

That being said, without the SSH keys it doesn't really matter what they try as they're not getting in. Well, not without a 0-day ssh bug that works pre-authentication. And if someone has one of those handy, then the world has bigger problems.

 

[esi_y]

Well, I think anyone who's wanting to muck with BGP or similar routing protocols to spoof one of the admin's IP addresses... probably has more important targets.

It could also be just someone within that AS.

That being said, without the SSH keys it doesn't really matter what they try as they're not getting in.

You contradict yourself as if this was your belief, then you would not be also doing IP source address filtering on top.

Well, not without a 0-day ssh bug that works pre-authentication. And if someone has one of those handy, then the world has bigger problems.

Here you are, linked within:
https://forum.proxmox.com/threads/how-to-limitate-8006-port-on-the-web.154960/#post-706416

 

[justinclift]

You contradict yourself as if this was your belief, then you would not be also doing IP source address filtering on top.

That's not how good security works.

 

[esi_y]

That's not how good security works.

I always thought IP filtering for SSH is to stop having all the bots spamming the log only.

 

[Johannes S]

Just some thoughts on the original question:
This is actually not so easy since it depends on the threat model.
Just one example: NFS assumes that every Client can be trusted and ISCSI usually is not encrypted. While both might be acceptable in a strictly isolated corporate network, I wouldn't take this risk on a cluster of dedicated servers of some hosting provider or other zero trust environments.
So I doubt that there can be a "one size fits it all"-Tutorial.
In the end it's in the responsibility of the admin to create a thread and security model and configure everything accordingly.

 

[esi_y]

In the end it's in the responsibility of the admin to create a thread and security model and configure everything accordingly.

I agree since the beginning, but the BZ I filed is phrased differently - to make it explicitly clear what you just stated in the official docs.