Securing Access to Webmin through an SSH Tunnel

Webmin is installed on the server that hosts this site and for the longest time I’ve been accessing it remotely through its default port at https://tech-otaku.com:10000. Despite connections being encrypted through SSL and having two-factor authentication enabled in Webmin this still presents a security risk.

Remote Access to Webmin

Figure 1 shows applications on a local computer – client – sending requests to a remote host – server – and the appropriate applications on the server handling those requests and sending data back to the client applications. The server’s firewall blocks all incoming requests except to those ports that have been explicitly opened.

On the server, ufw will show which ports are open:

sudo ufw status 

To                         Action      From
--                         ------      ----
10000/tcp                  ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
22/tcp                     LIMIT       Anywhere
10000/tcp (v6)             ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
22/tcp (v6)                LIMIT       Anywhere (v6)

The Webmin server – Miniserv – is listening for requests on port 10000. As port 10000 is open in the server’s firewall, any client requests on port 10000 will reach and be handled by the Webmin server rendering the Webmin login page accessible to anyone with Internet access.

Blocking Access to Webmin

The first step in securing access to Webmin is to close the port in the server firewall that the Webmin server listens on for client requests. We do this with ufw by deleting the rule that explicitly opens port 10000:

sudo ufw delete allow 10000/tcp

Rule deleted
Rule deleted (v6)

Figure 2 shows the client browser still sending requests on port 10000 to the Webmin server and the Webmin server still listening for requests on that same port. However, as port 10000 is no longer open in the server firewall, the Webmin server will never receive the client requests.

Webmin is – for now – inaccessible to everyone.

Accessing Webmin Through an SSH Tunnel

I’m going to provide access to Webmin by routing browser requests for it through an encrypted SSH connection between the client and the server and have these requests forwarded to Webmin. Figure 3 demonstrates this process:

1. The client establishes an encrypted SSH connection to the server on port 22…

2. …simultaneously opening local port 10005 on the client.

3. The browser no longer sends requests directly to Webmin on the server, but to local port 10005 instead.

4. All requests received on local port 10005 are then forwarded or tunnelled through the encrypted SSH connection to the server.

5. The server forwards the requests onward to the Webmin server on port 10000.

The advantage of this approach is the ability to limit Webmin access to only those users who can connect to the server via SSH. In addition, SSH provides an encrypted connection. Any plain text data being tunneled through it will benefit from that secure connection. This means that Webmin can be accessed over HTTP as the plain text data being sent to and from the Webmin server doesn’t need the encryption of TLS/SSL that HTTPS provides.

In general, on a macOS or Ubuntu Desktop client the command to establish local port forwarding through an SSH tunnel is:

ssh -p 22 user@host -L <local-port>:<remote-host>:<remote-port> -N &

More specifically, for the example in figure 3 the command is:

ssh -p 22 penny@203.0.113.5 -L 10005:127.0.0.1:10000 -N &

[1] 5907

Please note the following:

• -p 22 does not need to be included in the command if the SSH server is listening on the default port 22. However, if it’s listening on say port 5522, -p 5522 would have to be part of the command.

• Thinking that 127.0.0.1 refers to a localhost on a client, it took me a while to understand why it is being used for the <remote-host> until I realised it’s viewed from the perspective of the server not the client.

• & puts SSH into the background which is useful if you want to continue using the same Terminal window. I prefer this to the -f option which is part of ssh as I find it easier to terminate the SSH tunnel having used the former option. On a Ubuntu Desktop client you may need to press enter to drop back to the command prompt after using &.

Having established the SSH tunnel and forwarded the local client port 10005 to the remote server port 10000, Webmin can be accessed from a browser using:

http://localhost:10005

You may receive an error that Webmin should be accessed using https:// instead of http://. This is more than likely because SSL is enabled in the Webmin server configuration. You can continue by using https://localhost:10005, but your browser will warn you that the connection is not private.

To disable SSL on the Webmin server we need to change ssl=1 to ssl=0 in the file /etc/webmin/miniserv.conf on the server. To do this, on the server type:

sudo sed -i.$(date +"%Y%m%d-%H%M%S") 's/^ssl=1$/ssl=0/' /etc/webmin/miniserv.conf

Then restart the Webmin server:

sudo systemctl restart webmin

Terminating the SSH Tunnel

When you’ve finished your Webmin session, it’s good practice to terminate the SSH tunnel. If you used the & option when creating the SSH tunnel, from the same Terminal window type:

jobs

[1]+  Running                 ssh -p 22 penny@203.0.113.5 -L 10005:127.0.0.1:10000 -N &

This will display any process running in the background each of which will start with a number in square brackets. Bring the relevant process to the foreground by typing:

fg 1

ssh -p 22 penny@203.0.113.5 -L 10005:127.0.0.1:10000 -N

To end the process type Ctrl+C and the SSH tunnel is no more.