I am using Luci to manage my OpenWrt router. Being a newbie, I only know very basic commands in SSH (like opkg), so I need some help.

I have a password set on my OpenWrt router, but I do not want to take the chance that a hacker could brute force my password, so I want to make sure all forms of remote access are completely disabled.

OpenWrt's HOWTO (http://wiki.openwrt.org/doc/howto/secure.access) suggests doing this by:

1. Not offer access from the Internet at all, or allow only from certain IP addresses or IP-address ranges
    A. by make the ssh-server dropbear and the Web-Server uhttpd not listen on the external Ethernet port
    B. by blocking incoming connections to those ports (tcp 22, 80 and 443) in your firewall

Since I'm a total newbie to OpenWrt, I'm not sure how to do this. (How can I not offer access from the Internet at all?) I didn't know how to configure dropbear to not offer any Internet access, so I did this in SSL:

opkg remove dropbear

Does this solve my problem? Is there an alternative? I'm afraid to remove uhttpd because I'm not sure what it does.

I also want to block incoming connections to the ports 22, 80, and 443 in my firewall. Do the default traffic rules in Luci already do this, or do I have to add explicit block rules?

Please let me know if I'm omitting anything. I don't need any kind of remote access, and I just want to turn it off completely.

(Last edited by onewhoprowls on 23 Mar 2013, 05:18)

Yes, securing you router is possible. However, you need to understand what the current status is now before you make any changes. The wiki page is describing the concept of securing a router, but this doesn't mean that your router is in this state now.

Removing dropbear is not the way to go about it though - you now cannot SSH into the router even from within your own network.

To start, re-install drobear:

opkg install dropbear

enable it to start at boot:

/etc/init.d/dropbear enable

and start the dropbear process:

/etc/init.d/dropbear start

Confirm you can log back into the router and we'll proceed from there.

*Mod - suggest moving this to the general discussion forum *

If you're going to try to secure your router, you should decide why you want to do that. Realize that even the wireless side is insecure and if you are really trying to "secure" things, the weakest link is what will fail.

ssh and a solid password is generally considered reasonably secure for non-commercial systems. A certificate (even with a password to use the certificate) is better, but probably overkill based on what I am guessing the "value" of compromising your router would likely be.

In my opinion, for most non-commercial users, ssh-only access from the WAN side with a strong password (and perhaps changing the name of the "root" user) is probably enough. If they've got access to your LAN side, you already have a problem -- either a compromised internal host or compromised wireless.

If you have users on your LAN that you don't trust (for example, open or public WiFi) you should consider your whole WiFi infrastructure "throw away" from a security viewpoint, at least in my opinion.

by default firewall rules for WAN zone are already blocking ALL, so no need to bother..

I already can log into the router, even without Dropbear installed. After all, I was able to SSH in to do opkg install dropbear.

Well, secure or not, I don't need SSH from WAN or any other kind of remote access, so I think I have good reason to make sure it's disabled. You're right that there are other potential problems, but they don't exist in my situation. My wireless is off and I don't have any untrusted LAN users. If I make sure remote access is disabled, then I think I'm reasonably safe.

By the way, how can I change the username from "root" to something else? I wanted to do this but couldn't find any documentation on it.

Cool! If you're right, then remote access is already off. Which firewall rules are blocking everything? Maybe they aren't visible in the web interface.

(Last edited by onewhoprowls on 26 Mar 2013, 20:12)

see the "reject" action under wan (empty) row, input column:

http://upload.wikimedia.org/wikipedia/c … rewall.png

Interesting, I never quite understood that section. Just to be clear, "input" means from left to right (e.g. WAN to everywhere, or LAN to WAN), and output is right to left, right?

I was confused because under LAN to WAN, "output" is "accept" by default. I thought this meant all WAN to LAN traffic was accepted (meaning NAT is not working?).

Clearly I need to do some more reading on this. Is there anything you can point me to?

Yep, and provided that you had never rebooted or killed the dropbear process you would be fine (this was my assumption initially).  However, if the binary no longer existed and the process wasn't running, what would you SSH into afterwards? You'd have to re-install via luci.

At the outset, you stated that there were two objectives that you were pursuing:

Others have discussed the second point here and this is certainly an efficient way to enforce general security policy. 

It is still desirable though to configure the SSH server (dropbear by default) to only listen on particular interfaces and achieve the first suggestion (be that lan or a particular SVI / vlan interface). For example, if you only want to have dropbear listen on your lan interface (ie. remote access is impossible even if the port was not blocked explicitly by the firewall), execute:

uci set dropbear.@dropbear[0].Interface=lan
uci commit dropbear

You may also like to choose a high non-standard port for SSH (eg. 52,415):

uci set dropbear.@dropbear[0].Port=52415
uci commit dropbear

An even more secure move would be to disable password authentication and require SSH keys instead. This is discussed here:

http://wiki.openwrt.org/oldwiki/dropbea … ationhowto

You'll have to make your own determination as to whether this is right for you network though.  In any case, I'd always advise having a serial connection (even one by a usb adapter) just in case something went wrong.

You can also verify the above steps by showing the current listening servers.

Assuming your lan interface was 192.168.1.1, execute:

/etc/init.d/dropbear restart
netstat -ln

Active Internet connections
Proto Recv-Q Send-Q  Local Address      Foreign Address     State    
...
tcp        0      0  192.168.1.1:52415  0.0.0.0:*           LISTEN