How can we protect OpenWrt against this type of attack, beside setting a strong Ssh password?
Don't use passwords.
Use Ed25519 keys or, if you must, an RSA key of at least 4096 bits.
6 Likes
Don’t expose port 22 on WAN.
7 Likes
Agreed. Spin up a wireguard interface if you want remote access to your OW router.
1 Like
Also, with all the exploits of IoT devices in the wild, expose port 22 to as few LAN hosts as you can and isolate IoT devices on your LAN from your PCs, printers, NAS boxes and each other.
A quote from the article:
"The bulk of the malware code contains an implementation of an SSH 2.0 client that can connect and brute force any SSH server that supports Diffie-Hellmann key exchange with 768-bit or 2048-bit keys and data encryption using AES128-CTR."
Use more secure encryption and disable vulnerable encryption so it can't be used.
Can't we change port 22 to something else ON OW?
Are you suggesting that OpenWrt move the default ssh port to some other port number? Port 22 is the standard port, and it would likely cause confusion if the ssh port was changed to avoid this brute force attack (which is relatively unlikely to be an issue in most installations).
Individual users could easily change the listening port if they are concerned about this attack vector, but I wouldn't think it would be a good idea to change the standard/default behavior of OpenWrt.
3 Likes
Individual users, e.g I use a different port on some of my devices for SSH.
Ah... ok, so you were thinking the same thing. So yes, it is trivially easy to change the port, and I would think this would be a viable option (at the user level) if there is concern.
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
