[SOLVED] Supporting an OpenWrt router remotely

Installing and Using OpenWrt
1

Hi, I want to help some of my relatives by installing OpenWRT on their routers, but by doing so I am implicitly committing to supporting those routers. That is not such a bad thing as long as it does not take a lot of my time; best if it mostly automated.

If anyone here supports remotly located routers, could you pls share the high level setup that you use so that you can remotly manage those devices: upgrade, configuration merge during upgrade if there was a config change in a new version, etc.

Thanks in advance.

1 Like
2

Everything can be managed remotely, if you've got SSH access. Even more than the GUI can provide.

You can always port forward the GUI through ssh for remote management as well.

The "only" tricky part is if their outside IP changes. I've handled that in several ways in the past

  • cron job that periodically does a GET on a web server I have access to the logs
  • cron job that uses MQTT to post their outside IP to an outside MQTT server

DDNS will also handle this, though I haven't used it myself,

3

Isn’t it unsafe to expose an ssh port to the Internet?

4

These days I'd favour VPN access (OpenVPN, strongswan (IPsec) or wireguard) over direct ssh access. ssh itself is safe, provided you use ssh keys and forbid passwords - but if dropbear matches openssh's security is another question (opening ssh temporarily for invasive changes which could risk VPN operations (e.g. sysupgrade) might be a middle ground).

2 Likes
5

@slh Is e.g. Wireguard more straightforward than hardening Dropbear?

It is, unless you block access without SSH keys. Running your SSH daemon on a higher, non-standard port will also filter out a lot of bots and similar login attempts. I combine both. Downside: you need to have the SSH keys with you (which, for me, means my laptop).

My setup is as follows (I maintain multiple routers and access points remotely for friends and family):

  • Dropbear on a high port. To make it easy to remember, I use a high power of 2 by default - e.g. 8192, ...
  • Two dropbear instances: one listening on the WAN, with key-only access; the second listening on LAN, allows regular password logins.
  • OpenWrt's DDNS scripts combined with a provider supporting dynamic DNS (there's plenty to pick from, some free, some paying). Check the corresponding wiki page.

Since I use a high port and have key-only access enforced, I did not bother with running something like Fail2ban; but you can for ease of mind, but do look for something more light-weight then suitable to an embedded environment. There's basic similar functionality in iptables as well I think.

6

It isn't more straightforward, but personally I'd trust its security status more. Personally I haven't tested wireguard so far (it's useless to me until it's supported mainline and available cross-distro/ cross-OS), for my own uses I prefer strongswan and have given OpenVPN a test in the past.

7

Hashlimit seems better to me than fail2ban, just limit all ips to no more than 5 new connections per minute or similar, prevents dictionary attacks from DOSing you.

Password login with random passwords from keepass or similar should be OK in theory, the big issue with dropbear is a potential remote attack that bypasses all the authentication entirely, but I don't think such an exploit is known or has been published in the past, there are remote execution bugs in the past but it looked like maybe they were post authentication.

8

A DDNS subscription would be preferred. I personally prefer Dyn, which is $32/yr if buying the 5yr subscription package ($160). It provides 30 hosts and supports wildcards. See DDNS Client.

No. SSH should be configured to only utilize keys (RSA: 2048bit ; ED25519 ; ECDSA 256bit), with password authentication disabled/prohibited.

  • The higher the WAN side port, the better, as port scanners won’t scan all 65,535 ports.

  • As @Borromini mentioned, a non-default port WAN side (>10000) should be forwarded to the SSH port LAN side. Choose a port that's >10,000 and is not on this list.
    For example: /etc/config/firewall
    config redirect
    option  target          'DNAT'
    option  family          'ipv4'
    option  proto           'tcp'
    option  src             'wan'
    option  src_dport       37476
    option  dest            'lan'
    option  dest_port       22
    option  dest_ip         192.168.1.1
    option  name            'Allow Redirect WAN -> LAN (SSH)'
    • A non-default port prevents the router from having to deal with the thousands of daily requests that will be seen on WAN 22

  • I personally wouldn't run fail2ban, or an equivalent, unless there are default WAN side service ports that are open, as fw3 blocks all inbound WAN traffic by default

VPN type should be determined by what one is intending to use the VPN for.

  • IPSec VPNs [StrongSwan] and SSL VPNs [OpenVPN] have different use cases, and if one is looking for a VPN for remote access to their LAN devices, an SSL VPN would be better than an IPSec VPN.
    • SSL VPNs should be used when access to an entire subnet is required.

SSH access should never be allowed with a password, due to the security implications of doing so.

  • This is even more important on single user OSes, such as OpenWrt.

Provided the device has flash storage >4MB, install OpenSSH, and once confirmed working, uninstall DropBear.
See OpenSSH (Server Setup)

9

Thx everyone, who provided their feedback. I think I got it.

10

In the absence of exploitable bugs, the security implications are the same, anyone who knows the secret can get access.

that's true whether the secret is the private key of an rsa pair or a 128 bit random password generated by keepass2.

The big issue is people use weak passwords, keepass2 generates truly random ones which means they aren't weak.

11

That's a pretty strong statement, and one that goes against current practice, at least with OpenSSH. I've never seen a CVE or CERT recommendation that supports that. Given a strong password, the security of user authentication is comparable.

Last I checked, OpenWRT was a multi-user system

# cat /etc/passwd 
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false

I agree, if you've got the space, OpenSSH is a better option than dropbear.

12

Passwords can be cracked, PKI using RSA 2048, ED25519, or ECDSA 256 are impossible to break, and will likely remain so until at least 2030.

  • One only needs to look at the Sony hack by NK to see why passwords should never be used when a far more secure means of authentication exists.
    • There's countless examples, as the bottom line is most do not set complex passwords of at least 20 characters which contain at least 2 uppercase, 2 lowercase, 2 numbers, and 2 symbols.
    • More often than not, when users are forced to create complex passwords, they don't memorize the complex password they created, instead writing them down or putting them in a text file (which is likely not secured via encryption by a high bit PGP key).
  • The best form of security is PKI and altogether disabling/prohibiting password based authentication.

I'm not sure why you're stating it goes against current practice in OpenSSH...

  • /etc/ssh/sshd_config:
        # Authentication #
#--------------------------------------
ChallengeResponseAuthentication   = no
PasswordAuthentication            = no
PermitEmptyPasswords              = no

PubkeyAuthentication              = yes

PermitRootLogin                   = prohibit-password

A single user OS is one which a single user [root] runs all daemons and software... all consumer router firmware are single user OSes (exceptions are full fledged router OSes, such as pfSense, Sophos UTM/XG, etc.)

13

The issue isn't so much the password in and of itself, it's the fact it's root's password.

  • root should never be allowed to authenticate via SSH by password... that's just common sense.

  • If a user is bent on a using a password in place of PKI, then set up a user and group and install sudo, as 95% of actions done via SSH will require root privileges because OpenWrt is a single user OS.
    • If one is going to go out of their way to use a random password generator, this does nothing but create a massive inefficiency when compared to simply using one of the three aforementioned key examples.
      • Clearly most are not going to memorize a randomly generated password... so how to store it?
        • The only way to securely store such a password, if one isn't going to memorize it, is in an encrypted text file.
          • At this point, the user would save themselves the headache by simply using a PKI key, else here's what they user would now need to do
            1. Decrypt the text file
            2. Type the password character by character (unless one is also using an encrypted clipboard)
            3. Securely delete the clipboard contents if using an encrypted clipboard
            4. Securely delete the text file, overwriting at least 5 times
            • It should be kept in mind this text file, along with GnuPG/GPG4Win, will need to be on every device one wishes to login to the router from, versus a PKI key, which is all that's needed (along with an SSH client [built in on Unix bases systems, whereas Windows needs Win32-OpenSSH or PuTTY)
          -- OR --
          • Simply use PKI, which takes all of 3s to login with
            • It should also be kept in mind a password remains static, whereas PKI will negotiate a new encryption key every 60min or so (re-keying)
              • In OpenSSH, this is controlled via: RekeyLimit = 500M 60m
                • A key is re-negotiated after 500MB of data or 60min, whichever comes first... so no, the security implications are definitively not the same
14

Clearly you're not familiar with keepass2 the utility I mentioned, since everyone has to have a lot of passwords these days you should check it out. It offers an encrypted database and copy and paste all from a very useful UI with strong encryption and random password generation.

I only know about 5 passwords, the others are randomly generated, and only ever get copy and pasted. Particularly for any admin who might need to log into a router, this should be the default password management mechanism. No one is going to crack my passwords, all of them are at least 48 bits strength, most 64 or more. If you have rate limiting on the firewall to 1 per second it'd take the rest of the lifetime of the planet to crack

15

As mentioned in my previous post, a password remains static, whereas PKI generates a new encryption key every 60min or so.

  • A password for root is not a secure way to access SSH as root, but don't take my word for it, use your search engine of choice and do some research, as you will not find a single recommendation to allow root to ever login via a password over SSH.

With that being said, users will do what they want to do, regardless of best practices or tried and true methods which have been around for years. root's password is not even remotely the same as a website login or other things one uses a password generator for.

16

as I understand it, SSH generates a temporary session key using a Diffie-Hellman key exchange regardless of what method is used for authentication. The password is then sent within the encrypted tunnel to validate your identity only.

The root password on my router is far less important than the website login password on my bank or brokerage account. If a keepass2 generated password is sufficient for my life savings, it's sufficient for an OpenWRT router.

The fact is, either you have a secret that is unguessable, or you have a secret that is guessable. If it's unguessable, because it's generated by a true random number generator and is 64+ bits long, then as a technique for authentication, it's a secure technique. If you choose "myname123" as your password, then yes that's a terrible technique.

EDIT: All this being said, I personally agree that a PKI solution is a good one, and I use it on my routers.

17

There is confusion here between authentication and encryption. The encryption keys are independent of the manner of authentication, and re-keying of the encrypted channel is, as far as I know, independent of the manner of authentication. See https://tools.ietf.org/html/rfc4253#page-23 If you have evidence that re-keying is not performed by reputable SSH implementations, that would be a surprise to many.

As pointed out by @dlakelan the issue is not so much with passwords themselves, but with the strength of those passwords. As long as you're not using deprecated password hashing methods (crypt, md5, ...) and that you're not exposing the password (sending over unencrypted channels, such as not using TLS for your management channel, sharing with other services, ...) then a sufficiently strong password is acceptable for many, including those wearing tinfoil hats. The trick is not to let the tinfoil cover your eyes. "Fluffy" as a password, which is on your Facebook page, is a weak password. There are plenty of reputable articles on either generation and storage of "random" passwords (where the storage is only as good as the encryption used by the "safe" and the password used to access it), or the use of long, but easily remembered passwords. For example (and don't copy this verbatim)

This is probably a decent password to use 4 1 thing?

is a lot better than "Fluffy" or "p@ssword"

That the default configuration for OpenSSH disables many things does not indicate that they are things that should remain disabled. It is simply that when a server comes up in a potentially hostile environment, you want it locked down. That the default firewall for FreeBSD is

65535 deny ip from any to any

doesn't mean that FreeBSD suggests that you shouldn't allow packets. It's just the "safest" default configuration.

Now, let's look at the "single-user OS" statement. First off, hopefully we all agree that you shouldn't be running "user" services on a router. Commercial marketing demands that consumer-grade products provide all kinds of features, like file sharing and whatever they think can sell routers. What really needs to be running on a router/AP and does it need to run as "root"? Looking at my box:

  • ubusd
  • login
  • rpcd
  • netifd
  • sshd
  • ntpd
  • wpa_supplicant
  • hostapd

All of those pretty much require privileged access to the system

  • uhttpd

OK, that one bothers me, but given the structure of how the management interface runs (requiring "root" access to modify the system), I understand why. Would it be better to have uhttpd running as a limited-privelege user but then opening a socket or the like to a privileged process that can modify the system? Meh, still has issues.

I don't run services on my routers, but if you find some in OpenWRT that don't run as limited- or non-privileged user that could, that would be a great project to resolve and open a pull request.

Bottom line, for me:

  • Strong, "long" passwords, be they pass phrases or randomly generated are generally sufficient
  • Passwords provide the very significant advantage over keyed access in a remote-management situation of not needing to carry all your private keys with you at all times
  • If you're going to expose ssh to a hostile network (yes, your wireless should be considered hostile), use of OpenSSH over dropbear is a wise decision
  • If you're running LuCI
    • Install your choice of luci-ssl-openssl or luci-ssl-mbed
    • Modify the uhttpd configuration to only listen on
      • Your isolated management interface that isn't bridged to your wireless
      • Failing that, only your "inside" interface
      • And don't allow "plain" HTTP access, only HTTP-S
  • Install your services on something other than your router
18

Why is then OpenSSH not a default?

19

It's big, too big for routers with less flash, and for those that like to load their routers up with other services.

Size is likely the primary reason that things like busybox, dnsmasq, and uhttpd are used in the default configuration (and that TLS is not "default" for uhttpd -- mbed isn't much smaller, when I checked).

A quick check on sizes (and there might be more needed):

  • 637 k libopenssl
  • 286 k openssh server
  • 313 k openssh client
  • 165 k openssh keygen
20

You're totally right, my bad.

This in itself isn't necessarily necessary, unless a user doesn't already have a generated SSL cert for uhttpd (for example, if they have their own openssl.cnf they use to generate CAs and certs for a VPN or other servers).

  • The only difference between luci and luci-ssl-* is the latter includes a script uhttpd uses to auto generate a self-signed cert, along with the named SSL library.
    • I personally have never been a proponent of utilizing this method because a self-signed cert isn't secure due to lacking chain of trust. While convenient for a user, since it requires no input from them, it's also not the correct way of issuing SSL certs. While not likely, the possibility is always there that self-signed cert setup can be exploited, and not necessarily via WAN.
      • The script uhttpd uses (unless it's been updated recently) incorrectly configures it's self-signed cert by placing the IP as the CN, which was depreciated decades ago, with Google finally removing trusted status a few months back for any SSL cert not complying with the IP/DNS name in the SAN and not CN.
        • I believe Google did slightly modify this policy to allow access to RFC 1918 addresses which are not in compliance, however Chrome may still throw "Network is not Trusted" page.

      • I understand the reasoning as to why the uhttpd script is the way it is, as it's there for user convenience, but it also can feed into users learning the improper way of doing something, of which, to a degree, makes the server less secure, opening it to potential exploits (not necessarily from WAN).