If you are doing admin things via LuCI web interface, there is a risk that a user of your OpenWrt network is sniffing your traffic. You are at risk of giving away your LuCI web credentials to attacker. There are some ways to mitigate this risk.
This is the standardized practice to secure HTTPS protocol.
|1. Simple access||1. Bloated for devices with low storage|
|2. Standardized protocol||2. Non-properly signed certificate triggers browser warning|
The main advantage of HTTPS is a standardized protocol for securing http
connection. To access an HTTPS page is just typing https://openwrt.lan
http://openwrt.lan. It's simple. Just make sure that
luci-ssl and its dependencies are installed.
There are some disadvantages, though. Here are some of them.
1. External libraries makes a bloated installation.
On systems with just 4 MB of flash, it's not possible to enable HTTPS for LuCI web interface. Why? Because with TLS libraries integrated, the resulting image doesn't fit 4 MB of flash. Unless you have done some workaround such as expanding overlayfs size, it's unpractical.
2. Browser warning on non-properly signed certificate.
Well, this is a good browser feature. Unless the self signed root CA has been imported to the browser, this warning creeps you out! Why bother with commercial CA when your need is just securing your own router management interface for your own use?
Of course, you can just buy a properly signed certificate for your own openwrt.lan domain and ip address to get rid of the annoying browser warning. You can also just import the self-signed root CA used for certificate creation to your browser certificate store. See also How to get rid of LuCI HTTPS certificate warnings
This little hack is convenient for devices with very limited storage.
|1. Secure encryption over SSH tunnel||1. More complicated to setup|
|2. No additional TLS libraries needed.|
On standard OpenWrt installation, an SSH server daemon is always available. This is good news for limited-storage devices , since it's not necessary to install additional TLS libraries. Just use your favorite SSH client to setup port forwarding and all LuCI HTTP connection will be encapsulated within SSH packets.
This means that you get the same level protection of SSH, while getting rid of those TLS disadvantages for OpenWrt devices with low storage. Of course, there is disadvantages for this method. It requires more work to be done on SSH-client to setup the SSH-tunnel. I think the setup complexity is for the first time only. Later, it will be more simple to start the tunnel.
If you are willing to spend a little effort to setup SSH-tunnel, here is a simple guide for some popular SSH clients. This guide is just about setting up a local port forwarding to LuCI web interface.
This setup will forward all traffic passing through port 8000 from 127.0.0.1 on your local machine (desktop or laptop) to port 80 of your OpenWrt device, which has a local address of 127.0.0.1. You may understand better by viewing this graph.
|Local machine||OpenWrt device|
|sending packets →||receiving packets|
|receiving response||← sending response|
All traffic bypassing through port 8000 on local machine will be forwarded to port 80 on the remote machine. That's why this SSH-tunnel setup is called local port forwarding.
This is the standard SSH client for GNU/Linux and BSD distributions. To establish an SSH tunnel for LuCI web interface access, just add a local port forwarding options to the command line. Make necessary adjustments if needed (hostname, port, identity file, etc).
ssh -L127.0.0.1:8000:127.0.0.1:80 email@example.com
The SSH-tunnel is active as long as the SSH session is active.
For convenient setup, you may create host profile for this setup. Edit ~/.ssh/config file and add the following line. For more explanation about all available configuration, refer to ssh_config(5). Be sure to make necessary adjustments if needed.
Host LuCI-Tunnel Hostname openwrt.lan Port 22 User root LocalForward 127.0.0.1:8000 127.0.0.1:80
After creating the above configuration, the SSH-tunnel can be started by issuing the following command.
The command will read “LuCI-Tunnel” host profile and set up the SSH-tunnel accordingly.
PuTTY is popular Windows SSH client. To establish SSH-tunnel, you need to perform more steps.
1. Navigate to Connection ⇒ SSH ⇒ Tunnels.
2. Fill 8000 on the Source port field.
3. Fill 127.0.0.1:80 on the Destination field.
4. Click Add until the port forwarding setup appears on Forwarded ports section. Typically, the shown forwarding setup is L8000 127.0.0.1:80.
5. Navigate to Session. Fill firstname.lastname@example.org on Host Name field and 22 on Port field. If you have modified your OpenWrt hostname and SSH listen port, you need to adjust the value accordingly.
6. On the Saved Sessions field, type a unique name, such as OpenWrt LuCI Tunnel. Click Save, so that you don't need to repeat this setup for future use.
7. To start the SSH-tunnel session, click Open. The tunnel will be active as long as the SSH session is active.
8. To start the SSH-tunnel in the future, just select OpenWrt LuCI Tunnel on the PuTTY new session dialog, click Load and then click Open.
To access LuCI web interface securely, type http://127.0.0.1:8000
http://192.168.1.1. The traffic between your browser to LuCI
webserver is encapsulated within SSH-tunnel, so that the http traffic
gains the same level of SSH traffic encryption.
If you have finished accessing LuCI web interface, don't forget to end the SSH session.
For additional security, you may disable LuCI webserver altogether and start the service via SSH when needed.
/etc/init.d/uhttpd disable /etc/init.d/uhttpd stop
If you need access to LuCI webserver, just start uhttpd service without enabling it from SSH and access it via SSH-tunnel.
When you are done with LuCI webserver, don't forget to stop uhttpd service.
With this setup, you minimize the risk of LuCI webserver being brute-forced and prevent unauthorized access to LuCI web interface, as long as your SSH setup is secure (disabling password and using only public key authentication)
As a bonus, your OpenWrt device performance will (slightly) increase because of some system resources (memory, swap, and cpu usage) freed from uhttpd process.
You need to choose which of these methods suit your security needs. Don't be so attached about one method that you despise others in favor of your preferred methods.
Security is about doing things securely.