enable ssh brute force protection not working

[William Higgs]

I had initially configured my router so that it could be accessible via ssh from the LAN and WAN, but have now switched it to just LAN, as the "enable ssh brute force protection" feature doesn't protect against diddly:

Dec 15 23:24:32 dropbear[7518]: Login attempt for nonexistent user from 95.189.201.76:49087
Dec 15 23:24:32 dropbear[7518]: Login attempt for nonexistent user from 95.189.201.76:49087
Dec 15 23:24:33 dropbear[7518]: Login attempt for nonexistent user from 95.189.201.76:49087
Dec 16 00:09:39 dropbear[8214]: Login attempt for nonexistent user from 5.101.40.10:60065
Dec 16 00:09:43 dropbear[8217]: Login attempt for nonexistent user from 5.101.40.10:48942
Dec 16 00:09:43 dropbear[8217]: Login attempt for nonexistent user from 5.101.40.10:48942
Dec 16 00:09:48 dropbear[8220]: Login attempt for nonexistent user from 5.101.40.10:60501
Dec 16 00:12:46 dropbear[8266]: Login attempt for nonexistent user from 221.122.119.83:50613
Dec 16 00:12:50 dropbear[8267]: Login attempt for nonexistent user from 221.122.119.83:50995
Dec 16 00:12:54 dropbear[8269]: Login attempt for nonexistent user from 221.122.119.83:51701
Dec 16 01:17:34 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:34 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:35 dropbear[9265]: Client trying multiple usernames from 58.68.151.25:6212
Dec 16 01:17:35 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:35 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:36 dropbear[9265]: Client trying multiple usernames from 58.68.151.25:6212
Dec 16 01:17:36 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:36 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:37 dropbear[9265]: Client trying multiple usernames from 58.68.151.25:6212
Dec 16 01:17:37 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:37 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:37 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:17:38 dropbear[9265]: Login attempt for nonexistent user from 58.68.151.25:6212
Dec 16 01:23:21 dropbear[9351]: Login attempt for nonexistent user from 118.144.87.76:52136
Dec 16 01:23:22 dropbear[9351]: Login attempt for nonexistent user from 118.144.87.76:52136
Dec 16 01:23:23 dropbear[9351]: Login attempt for nonexistent user from 118.144.87.76:52136
Dec 16 01:27:27 dropbear[9418]: Login attempt for nonexistent user from 90.151.42.70:44772
Dec 16 01:27:28 dropbear[9418]: Login attempt for nonexistent user from 90.151.42.70:44772
Dec 16 01:27:28 dropbear[9418]: Login attempt for nonexistent user from 90.151.42.70:44772
Dec 16 02:13:09 dropbear[10112]: Login attempt for nonexistent user from 156.203.34.93:47133
Dec 16 02:13:17 dropbear[10115]: Login attempt for nonexistent user from 184.170.10.159:44372
Dec 16 02:13:22 dropbear[10118]: Login attempt for nonexistent user from 37.45.110.74:34710
Dec 16 03:56:04 dropbear[11759]: Login attempt for nonexistent user from 78.212.228.175:46378
Dec 16 03:56:04 dropbear[11758]: Login attempt for nonexistent user from 78.212.228.175:46368
Dec 16 03:56:04 dropbear[11759]: Login attempt for nonexistent user from 78.212.228.175:46378
Dec 16 03:56:04 dropbear[11758]: Login attempt for nonexistent user from 78.212.228.175:46368
Dec 16 06:41:07 dropbear[14424]: Login attempt for nonexistent user from 115.230.213.113:47102
Dec 16 06:41:08 dropbear[14424]: Login attempt for nonexistent user from 115.230.213.113:47102
Dec 16 06:41:09 dropbear[14424]: Login attempt for nonexistent user from 115.230.213.113:47102
Dec 16 08:06:34 dropbear[15730]: Login attempt for nonexistent user from 221.174.48.76:49479
Dec 16 08:06:34 dropbear[15730]: Login attempt for nonexistent user from 221.174.48.76:49479
Dec 16 08:06:35 dropbear[15730]: Login attempt for nonexistent user from 221.174.48.76:49479
Dec 16 08:51:50 dropbear[16423]: Login attempt for nonexistent user from 220.197.207.238:41197
Dec 16 08:51:53 dropbear[16425]: Login attempt for nonexistent user from 220.197.207.238:41944
Dec 16 08:51:56 dropbear[16426]: Login attempt for nonexistent user from 220.197.207.238:42675
Dec 16 08:52:09 dropbear[16431]: Login attempt for nonexistent user from 125.119.13.94:34316
Dec 16 08:52:10 dropbear[16431]: Login attempt for nonexistent user from 125.119.13.94:34316
Dec 16 08:52:11 dropbear[16431]: Login attempt for nonexistent user from 125.119.13.94:34316
Dec 16 10:38:03 dropbear[18059]: Login attempt for nonexistent user from 180.123.32.29:47161
Dec 16 10:38:03 dropbear[18059]: Login attempt for nonexistent user from 180.123.32.29:47161
Dec 16 10:38:04 dropbear[18059]: Login attempt for nonexistent user from 180.123.32.29:47161
Dec 16 11:12:30 dropbear[18585]: Login attempt for nonexistent user from 110.163.137.170:57316
Dec 16 11:12:30 dropbear[18584]: Login attempt for nonexistent user from 110.163.137.170:57314
Dec 16 11:12:30 dropbear[18585]: Login attempt for nonexistent user from 110.163.137.170:57316
Dec 16 11:12:30 dropbear[18584]: Login attempt for nonexistent user from 110.163.137.170:57314
Dec 16 11:20:21 dropbear[18711]: Login attempt for nonexistent user from 5.189.139.2:59876
Dec 16 11:20:26 dropbear[18713]: Login attempt for nonexistent user from 5.189.139.2:33184
Dec 16 11:49:03 dropbear[19150]: Login attempt for nonexistent user from 112.65.223.26:34917
Dec 16 11:49:03 dropbear[19150]: Login attempt for nonexistent user from 112.65.223.26:34917
Dec 16 11:49:04 dropbear[19150]: Login attempt for nonexistent user from 112.65.223.26:34917
Dec 16 12:18:22 dropbear[19603]: Login attempt for nonexistent user from 60.165.208.28:46804
Dec 16 12:18:22 dropbear[19603]: Login attempt for nonexistent user from 60.165.208.28:46804
Dec 16 12:18:23 dropbear[19603]: Login attempt for nonexistent user from 60.165.208.28:46804
Dec 16 13:08:47 dropbear[20374]: Login attempt for nonexistent user from 220.197.207.238:43021
Dec 16 13:08:52 dropbear[20375]: Login attempt for nonexistent user from 220.197.207.238:43743
Dec 16 13:08:55 dropbear[20377]: Login attempt for nonexistent user from 220.197.207.238:44755

 

[skeal]

Never and I mean ever allow ssh access from WAN!! That's just crazy!

 

[skeal]

looks like each ip was able to try 3 times and then was banned. So brute force protection is working.

 

[sfx2000]

Dec 16 13:08:47 dropbear[20374]: Login attempt for nonexistent user from 220.197.207.238:43021
Dec 16 13:08:52 dropbear[20375]: Login attempt for nonexistent user from 220.197.207.238:43743
Dec 16 13:08:55 dropbear[20377]: Login attempt for nonexistent user from 220.197.207.238:44755

That's how it works...

Word to the wise - be careful what services on the router are exposed to the WAN side - there have been issues in the past where the router/AP can be compromised.

 

[Gingernut]

That's how it works...

Word to the wise - be careful what services on the router are exposed to the WAN side - there have been issues in the past where the router/AP can be compromised.

I have SSH wan access enabled for remote router management through a proxy tunnel.

I have password access disabled and a SSH key for authentication and also brute force protection enabled.

Would that be the most secure way to have it setup?

I do see constante login attempts like the OP and it does kinda worry me.

 

[sfx2000]

I have SSH wan access enabled for remote router management through a proxy tunnel.

I have password access disabled and a SSH key for authentication and also brute force protection enabled.

Would that be the most secure way to have it setup?

I do see constante login attempts like the OP and I kind a worries me.

Using Certificates and disabling PW access is smart, and the brute force protection is also good to have.

Best you can do considering what you have to work with.

Keep in mind - scans like that are folks rattling doorknobs - it's a fact that one has to deal with on exposed services.

In my case, yes, I have SSH open to the WAN, but not with the router/AP itself, but port forwarded to a linux machine inside my LAN, and a very locked down OpenSSH instance as a jump box that I can access when I'm on the road (it also serves as a 'poor mans' VPN server as OpenSSH does allow for tunneling, but that's another discussion perhaps)

 

[john9527]

I have password access disabled and a SSH key for authentication and also brute force protection enabled.

Would that be the most secure way to have it setup?

You can also change to use a different port for ssh....that will also cut down on the hacking attempts.

 

[skeal]

Or.....use a vpn! A OpenVPN link...it's awesome. Leave ssh to Lan only and use the VPN to put yourself on the Lan.

 

[sfx2000]

You can also change to use a different port for ssh....that will also cut down on the hacking attempts.

Not really - these days, the bots are smart enough to just move - and this increases the load on the local system when it's being scanned...

And this is the worst case of security - security by obscurity is no security at all...

 

[sfx2000]

Or.....use a vpn! A OpenVPN link...it's awesome. Leave ssh to Lan only and use the VPN to put yourself on the Lan.

One has to be careful with VPN, seriously, as it's a trusted resource, so if misconfigured, it can be an open door into your LAN for all devices - lot of folks miss this one...

With VPN, just moving things to somewhere else, it's still a WAN interface for many - and if one doesn't own/control the other end, then that can be a problem.

 

[john9527]

Not really - these days, the bots are smart enough to just move - and this increases the load on the local system when it's being scanned...

Tend to have to disagree with you on this one....while there are no doubt some bots that do this, whenever I check I just see scans to known ports or ports with known exploits. They don't want to waste time on systems that appear not to be accessible.

 

[ColinTaylor]

Tend to have to disagree with you on this one....while there are no doubt some bots that do this, whenever I check I just see scans to known ports or ports with known exploits. They don't want to waste time on systems that appear not to be accessible.

That's been my experience as well. It might be different if you're being targeted specifically (think Bank or Government) but for general web crawlers they to tend to stick to the original ports or obvious variations like 80, 8080, 8000, 21, 2121, etc. It's low hanging fruit they're after. I've also never detected any "load" on my router from all these devices allegedly doing complete ports scans because I don't have common ports open to the internet.

And this is the worst case of security - security by obscurity is no security at all...

This mantra doesn't really apply here. There was no suggestion that by moving SSH to another port somehow all access restrictions (passwords, certificates, etc.) would be removed. The security would be the same as before but slightly obscured, certainly no worse and not "no security at all".

 

[RMerlin]

Tend to have to disagree with you on this one....while there are no doubt some bots that do this, whenever I check I just see scans to known ports or ports with known exploits. They don't want to waste time on systems that appear not to be accessible.

I second that. The goal for bots is to find easily exploitable targets. It's more likely that they will find a vulnerable target if they scan 65535 different IPs than if they scan 65535 ports on one single target.

I've made it an habit of moving the SSH port to a non-standard one on most servers that I manage. The amount of brute-force attacks drops to nearly zero (if not flat out zero) on all of these servers.

It's not security by obscurity, it's about removing the obvious target from plain sight. Security by obscurity would be relying on the use of a non-standard port to secure a remote access that has no real authentication-based security. Like an extranet website without at least a basic httpd auth mechanism.

Another reasons why these won't scan all 65535 ports is it would make them less stealthy, increasing the likelihood of their scan triggering a security measure completely blocking them (and potentially reporting them to some kind of malicious IP database, which once distributed, would block them from a large number of potential targets).

Same reason why greylisting or tarpits can be effective as a way to limit spam - spammers tend to move on to the next target if they can't deliver on their first attempt, as it's more likely they will find an open target by trying more servers during the same period of time.

 

[RMerlin]

enable ssh brute force protection

What this setting does is limit the number of SSH connections allowed within a given period of time. On top of that, dropbear has its own built-in protection that limits the number of attempts allowed (which can be seen in your logfile as dropbear reporting multiple user attempts).

Dropbear has a fairly good track record security-wise. It has less esoteric features than OpenSSH, which means simpler codebase, therefore less possible attack vectors. I personally trust it open on the WAN, especially if one disables password login and uses RSA or ECDSA keys to authenticate.

 

[sfx2000]

Dropbear has a fairly good track record security-wise. It has less esoteric features than OpenSSH, which means simpler codebase, therefore less possible attack vectors. I personally trust it open on the WAN, especially if one disables password login and uses RSA or ECDSA keys to authenticate.

Dropbear is robust - as discussed above and earlier in the thread - use certificates and all is good. Like busybox, it's ideal for embedded distributions.

 

[sfx2000]

Tend to have to disagree with you on this one....while there are no doubt some bots that do this, whenever I check I just see scans to known ports or ports with known exploits. They don't want to waste time on systems that appear not to be accessible.

It's been kind of interesting seeing how the bots are evolving - most are multithreaded, and they hit once and go away - and you might not see them on the log the first time as they just send the TCP syn packet to get the TCP ack back for fingerprinting, and each daemon and OS can be determined programatically...

One can move the port, but it really doesn't stop the scans from happening, and moving the port by itself provides no additional benefit...

In any event, like I mentioned earlier - keys/certs are absolutely the best way to secure an sshd - whether dropbear, openssh, whatever - best line of defense outside of not exposing the service in the first place.

Even with keys, there are best practices to be used - Mozilla has a great guide on the considerations - including cipher options and the like...

https://wiki.mozilla.org/Security/Guidelines/OpenSSH

Even here - no discussion about moving the server port itself - just making sure that the sshd is properly set up...

Even NIST - use keys, manage keys, etc...

 

[ColinTaylor]

and moving the port by itself provides no additional benefit...

This is demonstrably not true.

As an experiment, yesterday I setup two honeypot servers on the internet. One was running SSH on the standard port and the other on port 5482. I then logged all incoming packets (including SYN) and connection attempts.

After verifying that both servers were freely available from the internet and the logging was working correctly I let them run for the next 18 hours 10 minutes.

After that time the first server had received 9747 packets on port 22, from 91 unique IP addresses. There were 833 attempted logins.

The second server received zero packets on port 5482.

So it is incorrect to say that moving the port "provides no additional benefit", it clearly does. Of course no one is suggesting that this alone is a substitute for strong passwords or certificates, but it will help reduce the volume of attacks.

 

[john9527]

After that time the first server had received 9747 packets on port 22, from 91 unique IP addresses. There were 833 attempted logins.

The second server received zero packets on port 5482.

Matches my experience as well...Nice little test...

BTW....if you think that the number of ssh hits was high, try the same experiment with telnet some time

 

[sfx2000]

As an experiment, yesterday I setup two honeypot servers on the internet. One was running SSH on the standard port and the other on port 5482. I then logged all incoming packets (including SYN) and connection attempts.

How did you log all your packets on that port?

 

[ColinTaylor]

How did you log all your packets on that port?

I used netfilter to monitor the incoming packets and log the ones that matched the specified port to a file. I also cross referenced the netfilter packet counts with the contents of the file to make sure I wasn't missing anything.