Core: Feature Request: Bind Web GUI / SSH to specific interfaces or IPs

[willjones]

It would be really nice to have an option to easily configure what interfaces the web GUI and SSH processes listen on.

By default they are active on all IPs on the firewall, this potentially exposes management access to networks that people would maybe not want to, whilst we can obviously solve this with a firewall rule it strikes me as maybe being better to allow folks to specify an interface or IP that these services bind to.

Potentially this saves a lot of firewall rules too in situations with a large number of internal networks where exposing access to the GUI or SSH would not be desirable at all.

[fichtner]

(definitely maybe)

[rptxcosmo]

+1
Same need.

[fichtner]

will be done on our way to 18.1, the code preparations have been done for 17.7.

[fraenki]

@fichtner Is this still on the roadmap for 18.1?

[fichtner]

It's not on the roadmap per se, but I still have this in my priority list for 18.1.

[fichtner]

Alright, so we're going to do this:

• Interface selection for SSH and web GUI separately
• Selected interfaces will be expanded in primary IP addresses and all alias / carp configurations automatically, so no manual IP stuff...
• The default will be none, which is nicely backwards-compatible and the least worse in terms of operational impact ;)
• Dynamic reload for DHCP-configured interfaces will be supported
• There will not be a lot of sanity checking. To stress this point, if all manually configured interfaces do not have a single IP listening address, the service will refuse to start as opposed to falling back to listen on all interfaces...
• Use at your own risk. It's hard to recover without other precautions like console access, auto-console login, etc.

Thoughts? :)

[fraenki]

@fichtner All I've ever wanted! :D I'm absolutely OK with having no sanity checking and defaulting to a backwards-compatible config.

[fichtner]

Thanks, full speed ahead then. :) For recovery, I'm planning this as people will run into issues for sure. https://github.com/opnsense/core/issues/1966

[fraenki]

Dynamic reload for DHCP-configured interfaces will be supported

After thinking about this a little longer I have to ask: A reload will _only_ be triggered for DHCP, right? It would be cumbersome if the reload would happen if a VPN tunnel (IPsec, OpenVPN) is reconfigured/reconnected. (A worst-case scenario would be flapping VPN tunnels that would cause constant reloads of the WebGUI and make configuration changes impossible.)

[fichtner]

During "newwanip" reload of a selected interface the service will be restarted. Since we use session CSRF and graceful SSH kill (active sessions are not touched) this should be low impact.

https://github.com/opnsense/core/blob/9e209562d9b985dbe405e11d5f20937191e4d530/src/etc/inc/plugins.inc.d/openssh.inc#L97-L99

[fichtner]

Hi all,

The general code is in place for the web GUI now after a bit of struggle with lighttpd with regard to link local IPv6 being outright rejected, ssl settings block inheritance and other idiosyncrasies.

For safe use, I have been pondering how to make this robust and prevent a "lockout" scenario as discussed with @AdSchellevis. A sensible way forward would be:

If the web GUI configuration is changed to include or exclude interfaces (minus the case of deleting all interfaces), a timeout of 60 seconds (feel free to say if this is enough or not or too much) will run that will reset the interface configuration if it was not confirmed in an "apply-like" fashion through the GUI.

There are a few challenges here, but the system would be safe from lockouts and we could extend this approach to other critical changes like port changes, HTTP(S) toggle, certificate and cipher changes.

Thoughts? :)

Cheers,
Franco

[fichtner]

Note to self:

• #1580 is a similar recovery scenario. We will store the old webgui config under webgui-backup and restore this if it is not applied in time or possibly if the box is rebooted (don't panic!).
• Lighttpd is allergic to link-local IPv6 and IPv6 Gif Tunnels, all the more reason for recovery/revert
• Move the joined SSH / GUI anti-lockout to firewall advanced settings (it belongs to the firewall subsystem as it is enforced there)

[fichtner]

grr github

[fraenki]

• Interface selection for SSH and web GUI separately
• Selected interfaces will be expanded in primary IP addresses and all alias / carp configurations automatically, so no manual IP stuff...

Tested this for SSH on 17.7.11, works perfectly! :+1:

WITH SSH interface selection:

root     sshd       55579 3  tcp4   LAN_CARPIP1:22          *:*
root     sshd       55579 4  tcp4   LAN_CARPIP2:22          *:*
root     sshd       55579 5  tcp4   LAN_CARPIP3:22          *:*
root     sshd       55579 6  tcp4   LAN_IP:22               *:*
root     sshd       55579 7  tcp4   WAN_CARPIP1:22          *:*
root     sshd       55579 8  tcp4   WAN_CARPIP2:22          *:*
root     sshd       55579 9  tcp4   WAN_IP:22               *:*

WITHOUT SSH interface selection:

root     sshd       65280 4  tcp4   *:22                  *:*

[fichtner]

@fraenki cool! web gui code is in place on -devel as well, only thing missing is the recovery-revert / confirm-after-save to avoid a lockout.

[fraenki]

If the web GUI configuration is changed to include or exclude interfaces (minus the case of deleting all interfaces), a timeout of 60 seconds (feel free to say if this is enough or not or too much) will run that will reset the interface configuration if it was not confirmed in an "apply-like" fashion through the GUI.

I think that a timeout of 60 seconds would be too low. I have several boxes where the GUI/PHP parts are a bit sluggish. I'm pretty sure I won't be able to confirm the configuration within 60 seconds :)

[fichtner]

Ok, 3 minutes or 5? The new system polls and redirects when it’s back, will also later alternate between old and new link to kick back in after the global revert timeout so we catch most cases.

[fraenki]

Ok, 3 minutes or 5?

I'd choose 5 minutes. Long enough to be able to issue a confirmation, short enough to not be considered a serious downtime in case of a misconfiguration.

[fichtner]

The recovery has not been implemented for the initial 18.1 as time for testing is nonexistent at this point (today is the code freeze). Instead, a warning has been put into place with 795dd8b following the suggestion of @AdSchellevis when people try to set this value.

[fichtner]

Seems to work.... deferring recovery.