pveproxy - is disabling tls or moving its port possible?

[VA1DER]

I'm working with a new PVE install over top of Debian. I want to disable tls and connect to pveproxy over vanilla http to avoid exposing PVE's UI to the internet.

I found this instruction which speaks toward changing pveproxy's listening port, but the configuration file it references doesn't exist and the instruction doesn't actually show the options.

Can pveproxy be made to use vanilla http?
Can pveproxy be moved to a different port?

I've reverse proxy if I have to, but I figured there must be a way to configure it more finely.

 

[fba]

I want to disable tls and connect to pveproxy over vanilla http to avoid exposing PVE's UI to the internet.

Sorry, but why will disabling a security layer prevent exposure of an interface? Have a check on routing, firewall rules and so on instead.

There is no way to change the port in Proxmox VE. You can try rewriting it with a firewall as described in this thread.

 

[VA1DER]

why will disabling a security layer prevent exposure of an interface?

Because the only included security layer is TLS, which isn't an optimal transport for something you don't intend to expose to the Internet. TLS only properly works over a LAN/VPN with custom certificate infrastructure and manual browser trust, or manual security overrides.

As it stands, TLS in pveproxy selects for internet exposure to make it work properly. And, in fact, the default configuration exposes the interface to the whole world.

Allowing TLS to be disabled better accommodates more appropriate security layers. Vanilla http over ssh tunnels or wireguard.

Is it impossible to use otherwise? No. Does the current manifestation discourage the use of appropriate transports? Yes.

I ended up using caddy as a reverse proxy. It works, but when you think about it it's pretty clumsy.

 

[fba]

Allowing TLS to be disabled better accommodates more appropriate security layers. Vanilla http over ssh tunnels or wireguard.

That's an interesting opinion that wireguard has problems with https, but not with http. I can not even imagine why that should be the case.
But well, you used a reverse proxy to solve your problem, on a separate host most likely?

 

[VA1DER]

That's an interesting opinion that wireguard has problems with https

Wireguard has no problems with https. Browsers have problems with https over non-routable IPs. Browsers have problems with https over ssh tunnels and (without exotic configurations) wireguard connections.

Apparently I'm not making my overall point well enough. My point is that https and TLS (slash public certificate infrastructure) is not the best transport for a non-public administrative-only interface. Your home cable/fibre modem's UI is probably a web interface too, but I suspect you'd be aghast if the vendor exposed that interface to the internet. You are probably also using vanilla http to talk to it and if you access it remotely you probably also tunnel that connection over ssh or Wireguard (or OpenVPN, etc etc).

you used a reverse proxy to solve your problem, on a separate host most likely?

Same host. I reverse proxy http -> https (with certificate checking disabled) using caddy and listen on 127.0.0.1:8005. This lets me either use ssh to tunnel to it, or (what I normally do) forward a port from my wireguard interface to it.

It still uses TLS internally to talk from caddy to pveproxy, but at least it's not exposed and browsers like it.

Caddy is quick and easy to make a config for this for:

:8005 {
    bind 127.0.0.1
    reverse_proxy https://localhost:8006 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

 

[fba]

https and TLS (slash public certificate infrastructure) is not the best transport for a non-public administrative-only interface.

If the interface is not required to be accessed from a public network, why make it accessible from there first place? It should be accessible from trusted networks only. What additional measures you take (and the devices provide) is up to you and the it security requirements needed to be fulfilled.
Why not get a Let's Encrypt certificate ready for your PVE or one from the local CA used in the environment (if available)? Then you would improve security just by providing means for protecting authenticity in communication.

 

[VA1DER]

If the interface is not required to be accessed from a public network, why make it accessible from there first place?

EXACTLY!

PVE exposes its full interface to the public internet by default, with no good way of turning that off.

Why not get a Let's Encrypt certificate ready for your PVE

Who (else besides PVE) makes root-access password console logins available on the internet? Exactly nobody. I don't want a certificate for PVE because I'm trying to stem the bleeding.

Do you install phpmyamin and then expose that interface to the internet? Does your ssh allow root password logins?

It doesn't matter how secure your passwords are, it is an open invitation for bots and script kiddies that no amount of fail2an rules will ever stem. This isn't a webmail interface, here. It's the keys to the kingdom.

Yes, I can (and do) put it behind wireguard, but all it takes to be able to do this without requiring stupid security exceptions (for me and all my users) is to allow plain http. Requiring your users to put in an https security exception is unprofessional.

 

[chrcoluk]

Use Nginx in front of it, I do that as standard already on proxmox, to make it more secure and support modern features.

 

[fba]

EXACTLY!

PVE exposes its full interface to the public internet by default, with no good way of turning that off.

It is up to you to take care of who can access your server and from where. Proxmox is provided with a basic configuration after installation, customising it to meet your needs and setup, is up to you. If you put it in direct connection to the internet without additional protection, you will need to reconfigure it, to gain a resonable level of security.
If you want some common practice ideas, look here: https://forum.proxmox.com/threads/p...ng-document-for-compliance.146961/post-664107