Threat model for wireless administration

It looks like making the router only configurable over wifi is a decent amount of work.

So to make me sleep easier at night, what are the security risks of leaving the default wifi administration available?

  1. User has guest wifi (if enabled) but no router root password -> no risk above a wired LAN client in same zone
  2. User has 'private' wifi password but no router root password -> no risk above a wired LAN client in same zone
  3. User has a wifi password and root password -> full compromise of router, possibly remotely (no physical access needed as long as in wifi range)

two more that are too esoteric for this discussion:
4. Generic wifi vulnerabilities you wouldn't see on a wired-only router. Any new hardware in a system increases attack surface.
5. Generic vulnerabilities on the router / OpenWRT itself. Like if there was a special packet you could send to openWRT and have it crash / grant root.

Threats:

  • WPA2 and WPA3 have known vulnerabilities.
  • LuCI is not designed to be exposed to untrusted clients.

Solutions:

  • Only allow LuCI on trusted network and ignore WPA2/WPA3 threats.
  • Only allow LuCI over VPN/SSH tunnel.
  • Disable LuCI and only allow SSH, preferably only over VPN.

+1 to @vgaetera's comments.

However, before going full-on into the hardening process, consider the actual threat level of your network environment. For example, if you're a home user with a 10-year old and their friends and little-to-no random users who might be untrustworthy, a strong password for LuCI/SSH is likely sufficient. If you're trying to keep out people who are more knowledgable/persistent and/or if you are a target of value, you should be taking steps to secure your network and router with VLANs, firewall rules, and ssh keys or VPN to access the device.

1 Like

…and if you do have a 14-year-old at home, beware of physical access - failsafe is just a pull at the plug and a press on a button away.

2 Likes

Also note that even if you trust the users or consider user-related threats negligible, a client can be compromised by malware which may try to exploit known vulnerabilities to infect other clients and the router on the same network.

2 Likes

As it look like this topic starts using one of my old question as a reference. I just want to clarify some points
a) My original concern was to PREVENT configuring an AP using WiFi (only HW wired client are allowed)
b) The solution is quite simple when you know it, less than 10mn config.
Short how to:

  1. install the packet iptables-mod-physdev
  2. go to Luci Network\Interfaces and create a new interface (must be done for each wireless interface for multiple frequency devices)
    2-a name the interface eg: WiFiLock1
    2-b choose the protocol : unmanaged
    2-c select the interface to attach eg: wlan0 (check name on your device)
    2-d In the openning window select the firewall zone: lan
    2-e save and apply the changes
  3. go to Luci Network\Firewall\Custom rules
    3-a for the device you want to protect add a line like this (Must be done for each WIFi interface for multiple frequency devices). This line only protect the device itself.
    iptables -I INPUT -p tcp -m multiport --dports 80,443,22 -m physdev --physdev-in wlan0 -j DROP
    3-b for any devices of the network you want to protect, add a line like this (i did this for all the nodes of my network, router, AP, repeaters...).
    iptables -I FORWARD --dst IP_TO_PROTECT -p tcp -m multiport --dports 80,443,22 -j DROP
    3-c save
  4. the first time you do it, you have to permanently modify a flag
    4-a edit the file: /etc/sysctl.conf
    4-b insert the line: net.bridge.bridge-nf-call-iptables=1
    4-c save and exit
  5. reboot the device
  6. You no longer can access to the listed devices using WiFi

I'm trying to understand it in the context of OpenWRT wifi vs. non-OpenWRT wifi. Wifi is just one of those things I'm accepting in my life, like how every Intel chip has Intel Management Engine and that's a black box.

My assumption is since OpenWRT is more open, it's a lower risk than some off the shelf router. There's no way to prove this in either direction, so the only thing left would be if features of one or the other significantly change the threat model.

"WPA2/WPA3 vulns" would fall in the category of "Generic wifi vulnerabilities you wouldn't see on a wired-only router." The implication I get from that quote is that WPA1 doesn't have vulnerabilities. Is that your intent?

  • LuCI is not designed to be exposed to untrusted clients.

This feels like a security flaw vs. a generic wifi router. Or maybe it's just a more honest and explicit statement than what Netgear would say. I don't understand why this is, though. What is it about SSH that makes it more secure than LuCI? (I don't know much about SSH, but...) you could cryptographically verify clients with SSH and maybe you can't do that with LuCI?

I'm totally lost as to why a VPN would help secure the router.

hmmm... far fetched extrapolation... the statement clearly outlines that wired routers are devoid of these attack surfaces...

attack surface, eyes on code layering/auth capability at lower levels of the protocol stack

layered/hardened auth/obfustaction at lower levels of the protocol stack

1 Like

This is part of the story. Because OpenWrt is open source, it is true that there are more eyes on it and thus more opportunities to find and fix security issues. But the real reason is that OpenWrt is an active project that is improved/patched with each minor release, and is in active development with major releases incorporating new technologies, features, and bug/security fixes. And since it is not a commercial project, it doesn't get abandoned as new hardware comes out (many consumer routers have a support horizon of a few years, after which the vendors stop releasing new firmware because it isn't financially beneficial to them to continue support).

Most assuredly not the intent... WPA (1) has major vulnerabilities and that is why it is deprecated. It should never be used unless it is by absolute necessity (for super old equipment, for example), and with appropriate precautions (such as nothing sensitive on that network at all).

More honest and explicit. The web servers in small/embedded systems are not hardened for general use, and should not be exposed to the internet. This includes all consumer routers, regardless of the firmware.

SSH is secure shell, which is a much more robust security design with a much smaller attack surface. Still, it is recommended to not expose ssh to the internet on routers and similar embedded devices for the same reasons.... but this is far less likely to be a real risk that the embedded web server.

Modern VPNs are generally security-first designs. Assuming no specific vulnerabilities, a VPN won't even allow a connection to begin unless the cryptographic keys are right. Once you've proven that you have the crypto keys and can establish connection, all of the data flowing through that tunnel is encrypted (with most modern VPN technologies, anyway), so people cannot eavesdrop on your connections with the router administration features (ssh and LuCI). Compare that against say the LuCI web interface if directly exposed -- it is listening and immediately allows people to try connecting with the password. A brute force approach to crack the credentials wouldn't take that long -- hint: username is root, so you only need to brute-force the password field.

1 Like

I don't want to allow administration outside the local network. Can I access LuCI or SSH of my openwrt router outside my network, by default?

Also, I think everyone got the intent of my OP. But for clarity, I would prefer to have wired-only (no wifi) LuCI / root / SSH access. Since this looks like a little bit of work to do, I made my OP.

My passwords are all 8 to 12 character randomly generated bit strings from keepass2 so yeah that'd take hundreds of years to millions of years. At 1000 tries a second maybe 30 years for 40 bits of entropy. Perhaps a bigger issue is that the password is probably sent in clear text

1 Like

Just found this page.

Is it possible to easily toggle LuCI off and on? That way I could set up the router using the webui, disable the ui over ssh, and re enable it later if I needed administration.

IMO, the best way to secure your network is to use VLANs. Create a management network and configure it against a single physical port on your router. Put it in its own firewall zone, and set the input rule on that zone to accept. Then, on your LAN/wifi zone(s), set the input rule to drop.

1 Like

Sure just tell the uhttpd server not to run, then when you want it to run ssh in manually and start it up


/etc/init.d/uhttpd disable
/etc/init.d/uhttpd stop

When you want it back:

/etc/init.d/uhttpd start