Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
docs:guide-user:security:secure.access [2018/03/03 20:15] – ↷ Page moved from docs:user-guide:security:secure.access to docs:guide-user:security:secure.access bobafetthotmaildocs:guide-user:security:secure.access [2023/09/15 16:33] – [Elevating privileges with sudo] split vgaetera
Line 1: Line 1:
-====== Secure your router's access ======+====== Secure access to your router ======
 There are some possibilities to grant access to the router (or to any PC/Server): 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 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 an unsecured connection (e.g. telnet)
-  - ask for username and password on an encrypted connection (e.g. SSH) (e.g. by following [[doc:howto:firstlogin]]) +  - ask for username and password on an encrypted connection (e.g. SSH) (e.g. by following [[docs:guide-quick-start:walkthrough_login]]) 
-  - ask for username and merely a **''signature''** instead of a **''password''** (e.g. SSH with [[docs:techref:signature.authentication]])+  - ask for username and merely a **''signature''** instead of a **''password''** (e.g. SSH with [[docs:guide-user:security:dropbear.public-key.auth]])
  
-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 ask for username/password, an attacker has to guess the combination. 
 +If you use an unencrypted connection, they could eavesdrop on you and obtain your credentials.
  
-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. +If you use an encrypted connection, any eavesdropper would have to decrypt the packets first. 
- +This is always possible. 
-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:+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, they can always run a brute-force attack to find out your username and password.
 +They does not have to do that themself: they can let their computer(s) do the guessing.
 +To render this option improbable or even impossible you can:
   - not offer access from the Internet at all, or restrict it to certain IP addresses or IP address ranges   - not offer access from the Internet at all, or restrict it to certain IP addresses or IP address ranges
-    - by letting the SSH server [[docs:user-guide:base-system:dropbear]] and the web-Server [[docs:user-guide:services:uhttpd]] not listen on the external/WAN port+    - by letting the SSH server [[docs:guide-user:base-system:dropbear|Dropbear]] and the web server [[docs:guide-user:services:webserver:uhttpd|uHTTPd]] not listen on the external/WAN port
     - by blocking incoming connections to those ports (TCP 22, 80 and 443 by default) in your firewall     - by blocking incoming connections to those ports (TCP 22, 80 and 443 by default) in your firewall
   - make it more difficult to guess:   - make it more difficult to guess:
     - don't use the username ''root''     - don't use the username ''root''
     - don't use a weak password with 8 or less characters     - don't use a weak password with 8 or less characters
-    - don't let the SSH server [[docs:user-guide:base-system:dropbear]] listen on the default port (22)+    - don't let the SSH server Dropbear listen on the default port (22)
   - use the combination of   - use the combination of
 +    - set up [[docs:guide-user:security:dropbear.public-key.auth|Dropbear key-based authentication]]
     - username different than ''root''     - username different than ''root''
-    - tell ''dropbear'' to listen on a random port (should be >1024): System -> Administration -> Dropbear Instance -> Port{{ :media:doc:howtos:secure-access-02-ssh-port.png |SSH Port}} +    - tell Dropbear to listen on a random port (should be >1024): System -> Administration -> Dropbear Instance -> Port{{ :media:doc:howtos:secure-access-02-ssh-port.png |SSH Port}}
-    - public key authentication. Your public keys can be specified in Administation -> System -> SSH-keys. An older [[oldwiki:dropbearpublickeyauthenticationhowto|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. +
-{{ :media:doc:howtos:secure-access-01-ssl-keys.png |SSH Keys}}+
  
-===== System Hardening ===== +===== System hardening ===== 
- +If you have an external disk you may want to [[docs:guide-user:storage:disk.encryption|encrypt it]].
-If you have an external disk you may want to [[docs:user-guide:storage:disk.encryption|encrypt it]].+
  
 ===== Network hardening ===== ===== Network hardening =====
-  -  [[https://www.cipherdyne.org/fwknop/|Fwknop]] (FireWall KNock OPerator) implements an authorization scheme called [[wp>Single Packet Authorization]] (SPA). This method of authorization is based around a default-drop packet filter and libpcap. SPA is essentially next generation port knocking. 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. +  -  [[https://www.cipherdyne.org/fwknop/|Fwknop]] (FireWall KNock OPerator) implements an authorization scheme called [[wp>Single Packet Authorization]] (SPA) alongwith [[https://secure.wphackedhelp.com/blog/wordpress-two-factor-authentication/|setting up two factor authentication]]. This method of authorization is based around a default-drop packet filter and libpcap. SPA is essentially next generation port knocking. 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. 
-    * See detailed instructions at: [[docs:user-guide:services:fwknop|Fwknop]] \\ \\ +    * See detailed instructions at: [[docs:guide-user:services:fwknop|Fwknop]] \\ \\ 
   -  [[http://ingles.homeunix.net/software/ost/index.html|Ostiary]], like port knocking, adds an additional layer of security. It can be used to simply initiate a script or task remotely (without needing SSH access). See detailed instructions for configuring Server or Client by going to the corresponding links below.   -  [[http://ingles.homeunix.net/software/ost/index.html|Ostiary]], like port knocking, adds an additional layer of security. It can be used to simply initiate a script or task remotely (without needing SSH access). See detailed instructions for configuring Server or Client by going to the corresponding links below.
-    * [[docs:user-guide:services:remote_control:ostiary.server|Ostiary Server]] +    * [[docs:guide-user:services:remote_control:ostiary.server|Ostiary Server]] 
-    * [[docs:user-guide:services:remote_control:ostiary.client|Ostiary Client]] \\ \\+    * [[docs:guide-user:services:remote_control:ostiary.client|Ostiary Client]] \\ \\
   -  To protect open ports against brute force attack, the attacker ip address can be banned via iptables configuration:   -  To protect open ports against brute force attack, the attacker ip address can be banned via iptables configuration:
     * [[https://forum.openwrt.org/viewtopic.php?id=7493|forum thread 7493]]     * [[https://forum.openwrt.org/viewtopic.php?id=7493|forum thread 7493]]
Line 40: Line 42:
   - Dependent on you situation you may want to employ an [[wp>Intrusion prevention system]] like [[wp>fail2ban]] or better yet implement your own one based on ''logtrigger''.   - Dependent on you situation you may want to employ an [[wp>Intrusion prevention system]] like [[wp>fail2ban]] or better yet implement your own one based on ''logtrigger''.
  
-===== Create a non-privileged user in OpenWrt ===== +===== Protecting web interface ===== 
-Example that adds a user called nicolaus+For secure web access, OpenWrt can be accessed via HTTPS (TLS) instead of the unencrypted HTTP protocol. 
-<code> +If HTTP is not secure enough for you, you can disable the existing (unencrypted) web access and either 
-opkg update +  * [[docs:guide-user:luci:luci.secure|Tunnel your connection via SSH]] 
-opkg install shadow-useradd +  * Follow [[docs:guide-user:luci:luci.essentials#providing_encryption|Providing encryption]] to set up SSL protected access 
-useradd nicolaus +    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** 
-</code> +    - Optionally instruct the server to not listen on plain HTTP anymore:\\ <code bash>uci -q delete uhttpd.main.listen_http 
-Or add the user by hand (Take care that **uid/gid** (e.g.=1000) are not already in use!) +uci commit uhttpd 
-<code> +/etc/init.d/uhttpd restart 
-/etc/passwd: USER:x:1000:1000:GROUP:/mnt/usb:/bin/false +</code> **OR** Rebind to LAN only and redirect all http requests to https:\\ <code bash
-/etc/group: GROUP:x:1000: +uci set uhttpd.main.listen_http="192.168.1.1:80" 
-/etc/shadow: USER:RANDOMSTUFWillBeUpdatedWithPasswd:16666:0:99999:7::: +uci set uhttpd.main.listen_https="192.168.1.1:443" 
-passwd USER +uci set uhttpd.main.redirect_https="1" 
-</code> +uci commit 
-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: +/etc/init.d/uhttpd restart
-<code> +
-passwd nicolaus +
-mkdir /home +
-mkdir /home/nicolaus +
-chown nicolaus /home/nicolaus +
-vi /etc/passwd +
-   nicolaus:x:1000:1000:nicolaus:/home/nicolaus:/bin/ash+
 </code> </code>
  
-==== Allow temporary privileged access using sudo ==== +Can mandatory client certificate checking be set up with uhttpd? -[[http://lists.infradead.org/pipermail/lede-dev/2017-August/008692.html|not possible with uhttpd]]
-First, you should install ''sudo'': +
-<code> +
-opkg install sudo +
-</code> +
-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) === +If you require remote SSH access, follow the hardening instructions on SSH mentioned above.
-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 +===== Protecting PPP credentials ===== 
-<code> +When using PPP, protect its credentials from unprivileged users.
-visudo +
-</code> +
-Then uncomment the 2 lines below in that file and then save +
-<code> +
-## 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' +
-</code> +
-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 WANAnd 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'username**, **user's password** and **root's password** to get full access to the systemEven if the user's account get compromised, then the intruder still can't damage your system because he doesn't have root password yet+<code bash> 
- +PPP_IF="wan" 
-=== Method 2: 'sudo'ing with the user's password === +PPP_USER="$(uci -q get network.${PPP_IF}.username)" 
-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. +PPP_PASS="$(uci -q get network.${PPP_IF}.password)" 
- +cat << EOF >> /etc/ppp/options 
-For enabling this method you should also enter the command +user ${PPP_USER} 
-<code+EOF 
-visudo +cat << EOF >> /etc/ppp/chap-secrets 
-</code+${PPP_USER} * ${PPP_PASS} 
-And then add a line allowing your user, under comment "## User privilege specification": +EOF 
-<code> +cat << EOF >> /etc/ppp/pap-secrets 
-##                                                                            +${PPP_USER} * ${PPP_PASS} 
-## User privilege specification                                               +EOF 
-##                                                                            +chmod go-rw /etc/ppp/*-secrets 
-root ALL=(ALL) ALL                                                            +uci -q delete network.${PPP_IF}.username 
-nicolaus ALL=(ALL) ALL                                                           +uci -q delete network.${PPP_IF}.password 
 +uci commit network 
 +/etc/init.d/network restart
 </code> </code>
  
-=== 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 
- 
-<code> 
-visudo 
-</code> 
- 
-And then uncomment the line below: 
- 
-<code> 
-## Uncomment to allow members of group sudo to execute any command            
-%sudo ALL=(ALL) ALL  
-</code> 
- 
-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: 
- 
-<code> 
-opkg install shadow-groupadd 
-groupadd --system sudo 
-</code> 
- 
-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'': 
- 
-<code> 
-opkg install shadow-usermod 
-usermod -a -G sudo nicolaus 
-</code> 
- 
-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. 
- 
-=== 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: 
-<code> 
-chmod go-rw /etc/ppp/chap-secrets 
-</code> 
- 
-===== WebUI ===== 
- 
-For [[docs:user-guide:luci:luci.secure|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 
-  * [[docs:user-guide:luci:luci.secure|Tunnel your connection via SSH]] 
-  * Set up SSL protected access with uhttpd using the following steps (verified with 15.05) 
-    - Install cert generator and web server TLS plugin:\\ <code>opkg install luci-ssl</code> 
-      - //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**// 
-      - 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). 
-    - Optionally instruct the server to not listen on plain HTTP anymore:\\ <code>uci delete uhttpd.main.listen_http ; uci commit</code> 
-**OR** Rebind to LAN only and redirect all http requests to https: 
-  - <code> 
-uci set uhttpd.main.listen_http=192.168.1.1:80 
-uci set uhttpd.main.listen_https='192.168.1.1:443' 
-uci set uhttpd.main.redirect_https='1' 
-uci commit 
-</code> 
-    - Restart the web server to trigger certificate generation:\\ <code>/etc/init.d/uhttpd restart</code> 
-    - Optionally remove the key generator:\\ <code>opkg remove px5g</code> 
-  * If you are running older software (8.x) see this [[https://forum.openwrt.org/viewtopic.php?id=18288 forum thread]]. 
- 
-Can mandatory client certificate checking be set up with uhttpd? -> [[http://lists.infradead.org/pipermail/lede-dev/2017-August/008692.html|not possible with uhttpd]] 
- 
-If you require remote SSH access, follow the hardening instructions on SSH mentioned above. 
  • Last modified: 2023/09/15 17:59
  • by vgaetera