Proxmox on remote server: security best practices?

[mdbraber]

Hi,

I'm considering switching my current 'cloud' VPS setup to a dedicated server (e.g. Hetzner) with Proxmox running 2-3 VMs. Currently I'm only running Proxmox in my homelab, which works great but obviously has other security requirements than a remote setup.

Are there any pointers to best practices for setting up a remote Proxmox instance? I'm thinking that it would be most logical only to point the web interface to a local IP and then either use SSH + port-forwarding or VPN to administer the instance. Also I'm considering using pfSense as firewall (as I've used this before), but possibly it would be enough to just run the Proxmox firewall, rather than a virtualized pfSense (which gives possible problems if it would go down and trying to reach the host).

Ideas / suggestions for best (security) practices on setting up a remote Proxmox instance?

 

[LnxBil]

Ideas / suggestions for best (security) practices on setting up a remote Proxmox instance?

Besides block everything and only allow in connection from a known source, no. If you don't have a static source IP, you can setup knockd or VPN (but VPN has to be exposed again, so technically less secure).

 

[Vladimir Bulgaru]

Hey!

It highly depends on the threats you're trying to address and the level of security you're trying to achieve. I'm spitballing here, so bare with me:

1. Data security - if you're interested in protecting your data, including the hosting provider, you may need to encrypt the drive. You may need to look into LUKS;
2. Data redundancy and integrity - you need to keep your data on ZFS (data integrity) and have off-site backups (if Hetzner does not do this);
3. Access restriction - you need to close your IPMI and Proxmox IPs and ports from external traffic. A good approach is creating a Linux VM with OpenVPN server and allow traffic to Proxmox and IPMI from local network only;
4. Traffic filtering - you need to filter out the incoming traffic. A good approach is exposing the bare minimum amount of ports (e.g. for a webserver ports 22, 80, 443 and VPN port)

 

[mdbraber]

@Vladimir Bulgaru thanks, those are excellent remarks. I've got 1 and 2 covered as I'm using ZFS native encryption (and also LUKS where needed. Also 4 is current practice.

I'm curious about what's the best practice for 3:? Would there be an added benefit to using a Linux VM (or pfSense / FreeBSD) rather than using the host's pve-firewall? I'm currently using pfSense in my home setup which works fine. The only drawback I could see would be that any error in the 'router' VM (pfSense or other) would also make access to the hypervisor / Proxmox more difficult? Or am I mistaken?

 

[Vladimir Bulgaru]

@mdbraber,

The gist of 3) is using a VPN to connect to your server. The main difference i see is traffic limitation and encryption, rather than just limitation. You can attempt achieving a similar effect with SSL, but SSL does not encrypt non-http traffic. So, for instance, if you were to access a Windows VM over RDP, it would be exposed over web, while having a VPN connection, protects that traffic as well. Moreover, VPN helps you integrate your remote server into a personal network and you can create a hybrid cloud (e.g. connecting your homelab and Hetzner server).

Again - everything depends on how strict and secure you want to get and how sensitive is the data stored on the server. I'd say in 95% simple firewall policies would do. I was just trying to give ideas on which scenarios you may want to explore while securing the server.

 

[LnxBil]

Would there be an added benefit to using a Linux VM (or pfSense / FreeBSD) rather than using the host's pve-firewall?

If you are more familiar with pfSense than the intergraded PVE firewall and don't mind the additional complexity of having pve itself be routed through a self-hosted VM, then go for it. The PVE firewall is not that easy and has a learning curve. It's fine if you understand that there are multiple switches involved in getting the firewall to work properly, it's quite easy and does its job as it should be.

Traffic filtering - you need to filter out the incoming traffic. A good approach is exposing the bare minimum amount of ports (e.g. for a webserver ports 22, 80, 443 and VPN port)

I would never expose 22 to the world, because you'll get a lot of script-kiddie-noise in your log files. Move the port to somewhere else and notice a huge drop in login attempts.

So, for instance, if you were to access a Windows VM over RDP, it would be exposed over web, while having a VPN connection, protects that traffic as well.

I'm sure it's just terminology, but if you expose RDP via WEB (that's http), you would most certainly do it SSL encrypted. If you mean expose over the internet, then sure... don't do it unencrypted. As a general rule of thumb is to encrypt just everything.

I for myself route even the PVE management-port through another http proxy with additional security e.g. ssl client certificates and such. That also increases the security even further, but you have to a problem that can be solved in this way.

 

[guletz]

I would never expose 22 to the world, because you'll get a lot of script-kiddie-noise in your log files. Move the port to somewhere else and notice a huge drop in login attempts.

Better, open a higher port > 1024 and do port forwarding to 22. Even better protect your ssh port with port knocking.

The only drawback I could see would be that any error in the 'router' VM (pfSense or other) would also make access to the hypervisor / Proxmox more difficult?

Yes this could be a very big problem. In a such event, ... it could be very bad. A ideea would be to use at least a minimal firewall on PMX host, sou in case of VM ruter problem, you will not have a open host to the Internet.

And not least, remember that ANY security layers will be in place, you also need not monitor all this layers so you can react if something is wrong.
A good tool for automatically tests (test if all my firewall rules are in place) is monit, and also can react (if my own rules are not used, then reload them - and if after X conservative trying is not ok, then shut down my broken server and send me a mail). This is only one simple exemple.

Good luck!