Secure your router's access
There are some possibilities to grant access to the router (or to any PC/Server):
- ask for nothing, anybody who can establish a connection gets access
- ask for username and password on an unsecured connection (e.g. telnet)
- ask for username and password on a secure connection (e.g. ssh) (by following firstlogin you already achieved exactly that)
- ask for username and a merely a
signatureinstead of apassword(e.g. ssh with signature.authentication)
If you ask for username/password, an attacker has to guess the combination. But if you use an insecure connection, he could eavesdrop on you and obtain them. If you use a secure 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 access (german: Zugang, he can type in passwords), he can always run a brute-force attack to gain access (german: Zugriff). He does not have to do that himself, he can make his computer(s) do the guessing. To render this options improbable or even impossible you can:
- not offer access from the Internet at all, or allow only from certain IP addresses or IP-address ranges
- by blocking incoming connections to those ports (tcp 22, 80 and 443) in your firewall
- not using the combination of
- username
root - weak password with 8 or less characters
dropbearlistening on port 22 (as this is the standard port for ssh)
- but by using the combination of
- username different than
root - public key authentication (basically this is a very long password, and you do not type it into a prompt, it is contained in file on the client and is handled by the software)
dropbearlistening on a random port (should be >1024)
System Hardening
- You could use http://www.portknocking.org/. OpenWrt packages for this are
knockdandknockwithlibcap-Dependency only. HowTos have yet to be written:- portknock.server and
- portknock.client. (Please use template_howto)
- Or you could use Ostiary which, like port knocking, adds an additional layer of security (the more layers the harder it is to break in). Or it could be used to simply initiate a script or task remotely (without needing to faff around with ssh and sshkeys.)
- Dependent on you situation you may want to employ an Intrusion prevention system like fail2ban or better yet implement an own one based on
logtrigger.
Create a non-privileged user in OpenWrt
opkg update opkg install shadow-useradd useradd nicolaus
ppp
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
WebUI
If you require remote web access, OpenWrt can be accessed via https (TLS). If HTTPS is not secure enough for your, consider disabling the existing (unencrypted) web access and either
- Tunneling your connection via SSH, OR
- Set up SSL-protected access with uhttpd using the following steps (verified with 10.3)
- Install cert generator and web server TLS plugin:
opkg install px5g uhttpd-mod-tls
- Optionally instruct the server to not listen on plain HTTP anymore:
uci delete uhttpd.main.listen_http uci commit
… or rebind it to LAN only:
uci set uhttpd.main.listen_http=192.168.1.1:80 uci commit
- Restart the web server to trigger certificate generation:
/etc/init.d/uhttpd restart
- Optionally remove the key generator:
opkg remove px5g
- If you are running older software (8.x) see this https://forum.openwrt.org/viewtopic.php?id=18288 forum thread.
If you require remote SSH access:
- Change the default SSH incoming port (Administration → Services → Dropbear SSHd → Port)
- Setup 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.
doc/howto/secure.access.txt · Last modified: 2012/02/18 21:54 by barium


