I primarily use SSH for maintaining my servers. If a web GUI is unavoidable, I connect to it via an SSH tunnel whenever possible (e.g., for the GUI of various PROXMOX services or for other web configurations).
This works with numerous web GUIs, but unfortunately, it doesn’t work with Nethserver 8. I can get to the login window (i.e., the tunnel is basically up) and can log in there, but after that, it always says “Websocket disconnected.”
Do you see any way to get further with this?
It’s extremely impractical to always have to use a separate VPN for maintenance and configuration on Nethserver 8, especially if you have to disconnect your standard VPN for this. Setting up different VPN types specifically for parallel connections wouldn’t be very practical either. And exposing the Nethserver 8 web GUI to the internet is out of the question.
Since the SSH tunnels don’t work for SOGo, LAM, or Guacamole, I assume this has something to do with Nethserver 8’s traffic flow? Unfortunately, I don’t know anything about that. I use NGINX for my manually configured web proxies, and SSH tunnels work for those, or rather, all, web services configured outside of Nethserver 8.
As Markus noted, applications that use server name-based HTTP routes may not be reachable from a SSH-tunneled port. It is not a NS8 limitation but an application configuration choice over path-based routes with their pros and cons.
Application developers have to decide what kind of HTTP route to use. If the application is for system management a path-based route like /cluster-admin is a good choice.
You can disable public access with the Allow access from option of Traefik Proxy — NS8 documentation.
I can understand you’d like to reduce the “attack surface” exposing as few applications as possible to the public. This makes sense for apps that are for system management, like cluster-admin or LAM. Admins can connect through a SSH tunnel or management VPN to reach them.
IMO this is less interesting for apps like SOGo, that are designed for widespread access.
This primarily concerns the NetServer 8 configuration. Anything that is supposed to be accessible externally, like SOGo, obviously doesn’t require an SSH tunnel.
For the cluster admin, it would, in my opinion, make more sense to simply make it accessible via other ports (even self-selected?). This gives them even more options for enforcing access rules via an (external) firewall. Blocking 443 externally would be counterproductive. Enforcing access rules (also) via a proxy (Treafik) is a nice additional option, but in my world, that’s more the job of a port-based firewall – which, of course, can also evaluate source and destination.
But a discussion about this has probably already taken place and been decided long ago.
Configuring via VPN isn’t a problem, but having multiple VPN connections open at the same time IS a problem (it only works to a limited extent or not at all, especially DNS resolution…).
Keep in mind: Some people have a VPN active by default to their home or company server, e.g., for open work files (SMB) or a KeePass password database. Opening one VPN for the network server configuration means closing another one – and thus losing access to the aforementioned files, for example.
Therefore, it is sometimes incredibly useful to do various things via SSH sessions or tunnels – including browser sessions to configuration interfaces.
If I include this directly in my tunnel, I avoid the “/cluster-admin” path – and of course, I lose TLS (because that probably comes from traefik?), which makes the session on my side vulnerable.
But even if I try that anyway, I get the message “Websocket disconnected” after logging in.
Which somehow indicates that the problem probably has nothing to do with the traefik (because that doesn’t play a role with a direct connection?).
By the way, it’s not the browser (or its caches) either; I installed a completely new one, and it doesn’t change anything.
Both variants are encrypted through the tunnel, but variant 1 could of course be sniffed—albeit only locally. TLS variant 2 (Traefik input), on the other hand, would be protected from the browser to the Traefik input—as it should be.
One could argue that if an attacker can sniff packets locally, they could also intercept other browser inputs or even keyboard inputs in general – but there is still a difference: for variant 1, I have to allow the browser to use unencrypted connections, or I can’t generally prohibit them.
Perhaps someone can take another look at this from this perspective?
You’re right, I tried to listen on loopback again and can see a password in clear text. I corrected my previous post.
But I don’t think it’s a security issue as an attacker would need to listen on the local loopback device which needs root permissions.
Loopback can also be read. If you think that’s irrelevant because an attacker would then have to be on the local machine anyway, fine.
But then I have to configure my browser to allow non-TLS connections again. I CAN do that, but then it could affect EVERY external connection. This removes an additional layer of security (or attention) - without it being necessary.
And I like to keep the browsers I use to configure servers as restrictive as possible. Don’t you?
