How OpenWRT SSH server is secure by default?

Installing and Using OpenWrt
1

Hello. I am newbie, so probably I got something wrong.

I installed OpenWRT on my router, reloaded it and accesed web page http://192.168.1.1.

  1. I logged in with username "root" and empty password.
  2. I setted up root password.
  3. I opened page "System > Administration > SSH Access".
  4. I seen that there is dropbear instance with unspecified interface (i. e. listens on all interface)

Then I checked my public IP (let's say its 1.2.3.4) and tried to access my router through SSH
ssh root@1.2.3.4
After entering password I setted up in step 2 I'm successfully logged in.

But then I have a thought: after I installed OpenWRT and before I setted up root password there was a period of time when my root password was empty. Since SSH server is accessible by everybody on the internet, does not this mean that in this period of time everybody could login to SSH on my public IP with username "root" and empty password and upload malware to my router?

2

It is not allowed by firewall. Indeed if you made a custom image without firewall then it would open all interfaces.

3

Default is WAN not open to outside, are you sure you hit the external IP for ssh.

4

I downloaded image from https://downloads.openwrt.org/releases/23.05.4/targets/ramips/mt7621/openwrt-23.05.4-ramips-mt7621-asus_rt-ax53u-squashfs-factory.bin. I assume it's official OpenWRT image.

5

Then you are fine, connecting public IP from LAN is still LAN connection.

1 Like
6

Yes. I checked site https://myexternalip.com/, copied IP from there and logged in to this IP with SSH.

7

Did you run this test from inside your network? If so, you are technically connecting from the lan, not the wan.

Try from outside your network such as via a cellular connection.

3 Likes
8

This question has been asked on this forum at least three times before:

And the answer is always "the firewall prevents access from the global Internet by default". It's a sign that there should be an FAQ on the wiki or a small note on that LuCI page to assuage these (understandable) concerns by new users. :slight_smile:

3 Likes
9

Actually it is documented https://openwrt.org/docs/guide-user/security/secure.access though would not hurt to make 2-3 PRs to tame both services.

EDIT: dropbear has all the nibbles in place, try your luck at it.

1 Like
10

Good idea, but which page?

This is actually a Zone-Based Firewall concept. If you're a n00b to that, it can indeed be confusing and alarming at first - when you're sitting on your LAN and suddenly your WAN IP responds during your very first testing.

Not realizing yet that the LAN rules applied to the SRC traffic.

11

I agree with @lleachii, we have these access questions over and over again and users simply don’t understand the whole security concept of the firewall.
And the users on top of that (also in this post) misunderstand “listening interfaces” settings for both dropbear and uhttpd with actual access control.
Which I have explained numerous times, probably also in many of the above links to these earlier questions.

But I don’t see what any pr (code added) would do to prevent it?
I guess the best is then to probably remove listening interface settings in luci for both dropbear and uhttpd?

At the same time lan input rule is default set to accept so everything the user tries to do will be accepted.
So one other alternative is to tighten up the default lan rules just to state an example?

1 Like
12

for dropbear it would be just default to lan and checkbox remains
for uhttpd it is a bit tricky as it uses pre-rendered 0 listener and does not acquire it from interfaces.

13

But it doesn’t matter, that setting only defines what IP address it want you to call to, not from?

The whole security concept is based on the fact that you must define a access rule in the firewall for the IP address that you want to use for access, both from and to.
If you want tighter access control to dropbear and uhttpd.

14

So what this always comes down to is actually that users don’t understand the Input setting for a firewall zone, that one is pretty much always the “bad boy” that makes everyones security idea crash, not until that single setting with accompanying rules is fully understood will everything start to work as the user want it to work.