secure webinterface - change port 8006 proxmox 4.4

svenner

New Member
Mar 20, 2017
3
0
1
Germany
hi,

is it possible to change the default port 8006 of the webinterface in version 4.4 ?
or maybe a redirect from 443 ?

is there a chance to configure the pveproxy?

thanks...
 
This is still NOT possible? Users still have to get around this by using proxy/preroute? Can't believe it...
 
That's really "smart" solution! Any reason why PVE-devs are so stubbornly refusing to unlock this configuration option?
 
That's really "smart" solution! Any reason why PVE-devs are so stubbornly refusing to unlock this configuration option?

it's a lot of work and complexity for little gain, and the workaround is easy enough.
 
A lot of work to pull one number out of perl-script into config-file? I did not check the code yet but I doubt it can be so difficult. But ok, you are dev...

As for the rest: I completely and utterly disagree. Moving service from standard port is signifficant gain contributing to security (through obscurity though, but at the end everything counts). Try running public-facing sshd on default port 22, and then move it elsewhere for comparison. You will see the difference in log-files...

Workaround? You might call it easy enough, but I call it unnecessarily uneffective, when it comes to resources and security. Either proxy-server, or prerouting kernel-module must be active just because of this! This alone increases surface of possible attack-vector, but also denies the well-known "kiss" rule (which is even more important for hypervisor). Last but not least, every iptables-rule needs some cpu-power, which becomes obvious as soon as number of iptables-rules starts rising...

Hard-coding service to any particular port is imho very bad idea. I can not see any advantage in it...
 
A lot of work to pull one number out of perl-script into config-file? I did not check the code yet but I doubt it can be so difficult. But ok, you are dev...

As for the rest: I completely and utterly disagree. Moving service from standard port is signifficant gain contributing to security (through obscurity though, but at the end everything counts). Try running public-facing sshd on default port 22, and then move it elsewhere for comparison. You will see the difference in log-files...

Workaround? You might call it easy enough, but I call it unnecessarily uneffective, when it comes to resources and security. Either proxy-server, or prerouting kernel-module must be active just because of this! This alone increases surface of possible attack-vector, but also denies the well-known "kiss" rule (which is even more important for hypervisor). Last but not least, every iptables-rule needs some cpu-power, which becomes obvious as soon as number of iptables-rules starts rising...

Hard-coding service to any particular port is imho very bad idea. I can not see any advantage in it...

you are not talking about a simple single service like a web server instance, but a service which is part of an intra-connected cluster (e.g., PVE transparently proxies requests made to the "wrong" node, among other things). it's not as simple as "pulling one number out of a perl script" - even a simple search and replace of 8006/443 would touch 4 different git repositories and their respective packages, not even accounting for the question of how to know which node listens on which port in a clustered setup.

leaving this practical reason aside, if you think the solution to getting to many potentially malicious requests from the public internet on your hypervisor's management console (or SSH server) is moving its listening port to a non-standard one, I hope you don't run production setups with any valuable data. in 99% of the cases, neither your management console nor your hypervisor's SSH server should be reachable from the public internet - no matter which ports those daemons listen on. this is security 101, and not PVE specific at all. the correct solution is not having public access to those services (e.g., by setting up a jump host or VPN).
 
you are not talking about a simple single service like a web server instance...
Quite bad example, as web-server can consist of many interconnected services as well.
it's not as simple as "pulling one number out of a perl script" - even a simple search and replace of 8006/443 would touch 4 different git repositories and their respective packages
Still I do not think replacing four hard-coded values with values from config-file is somehow complicated.
...not even accounting for the question of how to know which node listens on which port in a clustered setup.
Maybe the same way as you know which node listens on which ip/fqdn?
...if you think the solution to getting to many potentially malicious requests from the public internet on your hypervisor's management console (or SSH server) is moving its listening port to a non-standard one...
I do not remember saying anything like that (contribution != solution) so your *if* condition is invalid.
...in 99% of the cases, neither your management console nor your hypervisor's SSH server should be reachable from the public internet...
I agree with that 1% you left for special cases.
...the correct solution is not having public access to those services (e.g., by setting up a jump host or VPN).
Just in this year, OpenVPN had 3 security-related bugs. That's why I never rely solely on vpn. Ultimately, it is not bullet-proof, as no other software is...
 
My solution here was to use iptables REDIRECT.
Code:
iptables -t nat -I PREROUTING -i eno1 --dst <ipv4-address>  -p tcp --dport 443 -j REDIRECT --to-ports 8006
ip6tables -t nat -I PREROUTING -i eno1 --dst <ipv6-address>  -p tcp --dport 443 -j REDIRECT --to-ports 8006

After you add the rules, you can view them to verify they are correct and test.
Code:
ip6tables -t nat --line-numbers -L
iptables -t nat --line-numbers -L

Debian has a nice package to make the rules persistent. If you have your rules already in place when you install the package, it will prompt if you want to save the existing.
Code:
apt-get install iptables-persistent

Use the following command to save future changes
Code:
# netfilter-persistent
Usage: /usr/sbin/netfilter-persistent (start|stop|restart|reload|flush|save)
 
My solution here was to use iptables REDIRECT.
Code:
iptables -t nat -I PREROUTING -i eno1 --dst <ipv4-address>  -p tcp --dport 443 -j REDIRECT --to-ports 8006
ip6tables -t nat -I PREROUTING -i eno1 --dst <ipv6-address>  -p tcp --dport 443 -j REDIRECT --to-ports 8006

After you add the rules, you can view them to verify they are correct and test.
Code:
ip6tables -t nat --line-numbers -L
iptables -t nat --line-numbers -L

Debian has a nice package to make the rules persistent. If you have your rules already in place when you install the package, it will prompt if you want to save the existing.
Code:
apt-get install iptables-persistent

Use the following command to save future changes
Code:
# netfilter-persistent
Usage: /usr/sbin/netfilter-persistent (start|stop|restart|reload|flush|save)
8006 port is still working its not denied 8006 ...
 
I made it but it did not work :( maybe i made it mistake if you know could you share please ?

Thank you from now.
 
I made it but it did not work :( maybe i made it mistake if you know could you share please ?

Debug/Inspect your iptables rules, there are also predefined rules to allow access to 8006 and if that is first hit, you can block whatever you want afterwards.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!