User Tools

Site Tools


Secure your router's access

There are some possibilities to grant access to the router (or to any PC/Server):

  1. ask for nothing: anybody who can establish a connection gets access
  2. ask for username and password on an unsecured connection (e.g. telnet)
  3. ask for username and password on an encrypted connection (e.g. SSH) (e.g. by following firstlogin)
  4. ask for username and merely a signature instead of a password (e.g. SSH with signature.authentication)

If you ask for username/password, an attacker has to guess the combination. If you use an unencrypted connection, he could eavesdrop on you and obtain them.

If you use an encrypted connection, any eavesdropper would have to decrypt the packets first. This is always possible. How long it takes to decrypt the content, depends on the algorithm and key length you used.

Also, as long as an attacker has network access to the console, he can always run a brute-force attack to find out username and password. He does not have to do that himself: he can let his computer(s) do the guessing. To render this option improbable or even impossible you can:

  1. not offer access from the Internet at all, or restrict it to certain IP addresses or IP address ranges
    1. by letting the SSH server dropbear and the web-Server uhttpd not listen on the external/WAN port
    2. by blocking incoming connections to those ports (TCP 22, 80 and 443 by default) in your firewall
  2. make it more difficult to guess:
    1. don't use the username root
    2. don't use a weak password with 8 or less characters
    3. don't let the SSH server dropbear listen on the default port (22)
  3. but by using the combination of
    1. username different than root
    2. tell dropbear to listen on a random port (should be >1024): System → Administration → Dropbear Instance → Port

SSH Port

  1. public key authentication. Your public keys can be specified in Administation → System → SSH-keys. An older guide to DropBear SSH public key authentication has detailed information on generating SSH keypairs which include the public key(s) you should upload to your configuration.

SSH Keys

System Hardening

If you have an external disk you may want to encrypt it.

Network hardening

1) You don't have to open any ports to WAN.
With, you can execute any pre-defined command remotely, without any open port! How it works: portknock daemon listens for specific packets on specific ports (either opened or closed), and will run a command when it hears the correct sequence. It is usually used to hide ports from public view for better privacy/security. For example: it can open the port for SSH on WAN, but just for a short period of time, until you can establish a new connection through that port.

2) Alternatively you could use Ostiary.
Ostiary, like port knocking, adds an additional layer of security. Or it could be used to simply initiate a script or task remotely (without needing SSH access)

3) To protect open ports against brute force attack, the attacker ip address can be banned via iptables configuration:

4) Dependent on you situation you may want to employ an Intrusion prevention system like fail2ban or better yet implement your own one based on logtrigger.

Create a non-privileged user in OpenWrt

Example that adds a user called nicolaus:

opkg update
opkg install shadow-useradd
useradd nicolaus
Or add the user by hand (Take care that uid/gid (e.g.=1000) are not already in use!)
/etc/passwd: USER:x:1000:1000:GROUP:/mnt/usb:/bin/false
/etc/group: GROUP:x:1000:
/etc/shadow: USER:RANDOMSTUFWillBeUpdatedWithPasswd:16666:0:99999:7:::
passwd USER
However, you can't ssh to this user yet. To enable ssh access, you should make a password for that user, create his home folder and most importantly indicate the shell of that user:
passwd nicolaus
mkdir /home
mkdir /home/nicolaus
chown nicolaus /home/nicolaus
vi /etc/passwd

Allow temporary privileged access using sudo

First, you should install sudo:

opkg install sudo
Additionally, you must allow your desired user by manipulating '/etc/sudoers' by tool visudo. Now you can follow ONE of the methods below to choose how the user should be able to run commands as root:

Method 1: 'sudo'ing by any user with root password (more secure)

In this method any user can temporarily run commands as root only if he knows the root password. This way when the user runs a command with sudo he should enter root's password instead of his password.

For enabling this method you should open the file '/etc/sudoers' by entering the command

Then uncomment the 2 lines below in that file and then save
## Uncomment to allow any user to run sudo if they know the password         
## of the user they are running the command as (root by default).            
Defaults targetpw  # Ask for the password of the target user                 
ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'
This method is more secure because you don't need to protect both root and privileged (sudoer) users to keep the whole system safe.

One usecase can be allowing remote ssh with password from WAN: For more security (still less than RSA key) you can only allow users other than root to ssh with their password (optionally on a custom port) from WAN. And for even more security you can request root's password after running sudo. Therefor in this scenario a hacker should find 3 different strings user's username, user's password and root's password to get full access to the system. Even if the user's account get compromised, then the intruder still can't damage your system because he doesn't have root password yet.

Method 2: 'sudo'ing with the user's password

In this method, after logging in by the desired user, when you enter sudo you should enter the user's password again. The end result is similar to how you use sudo in Ubuntu or other popular Linux disros, but this method doesn't utilize group 'sudo' for this purpose.

For enabling this method you should also enter the command

And then add a line allowing your user, under comment "## User privilege specification":
## User privilege specification                                              
root ALL=(ALL) ALL                                                           
nicolaus ALL=(ALL) ALL                                                           

Method 3: 'sudo'ing with the user's password if he is member of group 'sudo' (needs installing some packages)

This method is very similar to Method 2, except that it allows any member of group 'sudo' to use sudo with their own password. This method is exactly the same one used in Ubuntu and other popular Linux distros to allow 'sudo' access for a user.

For activating this method first you should allow group 'sudo' to use command sudo by entering

And then uncomment the line below:
## Uncomment to allow members of group sudo to execute any command           
%sudo ALL=(ALL) ALL 
Second you should create group 'sudo'. You can do it by manually editing '/etc/group' but it's more standard to install and use tools for this purpose:
opkg install shadow-groupadd
groupadd --system sudo
And finally add your current user to the group 'sudo'. You can directly append your user to '/etc/group' but again it's better to use usermod:
opkg install shadow-usermod
usermod -a -G sudo nicolaus
This method is more convenient because you can simply allow sudo access for any user you want, just by usermod -a -G sudo <USER> but takes more space (for installing new packages) than method 2 which may be more suitable for systems with very limited space.


If you are using ppp in the default configuration with username and password in /etc/config/network, then the unprivileged user can read it from pppd's command line (with e.g. ps w). To prevent that, you can add "user <username>" to /etc/ppp/options and "<username> * <password>" to /etc/ppp/{chap|pap}-secrets and then remove the username / password options from uci configuration.

Of course /etc/ppp/{chap|pap}-secrets should not be world readable:

chmod go-rw /etc/ppp/chap-secrets


For secure web access, OpenWrt can be accessed via HTTPS (TLS) instead of the unencrypted HTTP protocol. If HTTP is not secure enough for you, you can disable the existing (unencrypted) web access and either

  • Set up SSL protected access with uhttpd using the following steps (verified with 15.05)
    1. Install cert generator and web server TLS plugin:
      opkg install luci-ssl
      1. While luci-ssl automatically installs px5g that can be utilized, you can also use openssl to generate your own certificate authority and certs, then use that certificate authority to sign the certificate you use for uhttpd. Certificates can also be named or placed in whatever directory you wish by editing /etc/config/uhttpd
      2. Note that uhttpd-mod-tls is not needed after r35295 in Jan2013. But you need a ustream-ssl wrapper library on top of the actual SSL library (polarssl, mbedtls, cyassl, openssl). Luci-ssl includes by default libustream-mbedtls (since Dec2016).
    2. Optionally instruct the server to not listen on plain HTTP anymore:
      uci delete uhttpd.main.listen_http ; uci commit

OR Rebind to LAN only and redirect all http requests to https:

  1. uci set uhttpd.main.listen_http=
    uci set uhttpd.main.listen_https=''
    uci set uhttpd.main.redirect_https='1'
    uci commit
    1. Restart the web server to trigger certificate generation:
      /etc/init.d/uhttpd restart
    2. Optionally remove the key generator:
      opkg remove px5g

to do: indicate how mandatory client certificate checking could be set up

If you require remote SSH access, follow the hardening instructions on SSH mentioned above.

doc/howto/secure.access.txt · Last modified: 2016/12/29 16:39 by hnyman