This isn’t actually necessary as the firewall, by default, blocks ssh on the wan. It is only exposed if the user creates a rule to allow it.
4 Likes
Everything about “listening to” in dropbear and uhttpd is pretty much false security if misunderstood and is only about general order in the network or something similar. It has absolutely nothing to do with security.
It is only the firewall that can decide what can be listening to, or more exact who can do the call to “the device” to begin with.
But it is very hard to see this in reality if you only have the standard lan/wan setup with the standard firewall setup. But if you do a multi vlan setup with a admin vlan it gets very obvious very fast what the firewall do and what “to device” and Input means in the firewall.
I have had port 22 exposed on WAN for ages, and SSH brute force attacks have always happened.
2 Likes
Moving the port doesn't really help, the scanners have gotten smarter, and scan other ports too.
I've got mine open, and as @eduperez says, the login attempts have already been there.
What I've done is to restrict the external access to a few IPs, and the IP ranges of my cell phone carrier, also got fail2ban running on top of it.
3 Likes
I have just setup 22.03 rc6 and the default for SSH was 'unspecified' which means all ports.
I changed manually to LAN
"or, if unspecified, on all"
Would be great if the default was actually just LAN for basic security. And then power users can turn on WAN
No, it means all interfaces, just as the description next to the box says.
But there's a firewall in front of some of them...
3 Likes
Sorry, yes I meant all interfaces which means also WAN. A few people have said SSH WAN is disabled by default
Ok noted
1 Like
I've got SSH running on the WAN on a high port, but as pointed out earlier that won't defeat scanners who look for other ports than the default TCP 22. I've set login to key-only though, so password login attempts are refused. I warmly recommend enforcing key-only SSH logins if you expose it to the WAN.
4 Likes
Is a password like this below (using random generator) unlikely to ever be brute forced?
Where unlikely to ever = 20,078,001,260,325,550,000 billion years
Don't know if it still works that way, but you don't need to guess the password, but generate a random string that have the same hash.
2 Likes
Noob question, but how do I check the login attempts from logs?
Thanks to great advice on this forum, I've just set this up.
So I keep Dropbear active but I disable root login as per below screenshot, correct?
But Luci https page , is still functional via root password.
Is it more difficult to brute force ssh and not Luci? (uHTTPd)
Or same difficulty ?
Is this the default setting? I remember in the past when I flashed a fresh openwrt the Interface for Dropbear/SSH specified was something like unspecified - would that by accident include the wan interface?
1 Like
ii is already protected, don't panic.
by default nothing (with very few exceptions) is accepted from WAN. so unless you manually expose a port you are protected from external attempts because network traffic is firewalled in owrt.
3 Likes
So I just figured I can disable uHTTPd via SSH. I rarely need use Luci after everything is setup.
I can enable uHTTPd manually via SSH when required.
And with SSH now only by 4096 bit KEY, I think that is good enough for security.
I'm new to OpenWRT . Thanks to the advice shared by this community
LuCI was never intended to be secure enough to leave open to the Internet. If you want to access LuCI remotely, always use a SSH tunnel or VPN.
A ssh tunnel is configured by adding -L 8080:localhost:80 to your CLI ssh login. Then leave the ssh session open and go to your web browser where http://localhost:8080 (your localhost) is now linked to the remote LuCI (port 80 on that localhost).
Also note that https protects the client user from certain security risks, it does nothing to protect the server from a third party brute-force or other intrusion. So LuCI with https is not less risky than without.
5 Likes
I tried this but failed. Can you please help
In terminal from a laptop I did:
ssh root@192.168.1.1 -L 8080:localhost:80
What is 'localhost' supposed to be there?
and then put in my passphrase for SSH key
But when I went to my browser, the old 192.168.1.1 went to Luci login screen (I didn't need 8080)
Appreciate any guidance
You need to reread what @mk24 wrote, and the tunnel doesn't stop the regular 192 access, unless you tell uhttpd to only bind to localhost.
Yes I've read a few times with no luck.
Can you help with how to do this please