SSH brute force protection question

[redhat27]

I have enabled SSH brute force protection on the web UI, but am not very clear how to determine whether it is working or not.

This is in my iptables-save filter section:

Spoiler: iptables filter

admin@RT-AC66R-D700:/tmp/home/root# iptables-save | grep -i ssh
:SSHBFP - [0:0]
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j SSHBFP
-A SSHBFP -m recent --set --name SSH --rsource
-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j logdrop
-A SSHBFP -j logaccept

Yet these appear in the syslog (fw logging enabled):

Spoiler: syslog

Apr 6 16:44:20 kernel: ACCEPT <4>ACCEPT IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=40 TOS=0x00 PREC=0x20 TTL=48 ID=40639 PROTO=TCP <1>SPT=29513 DPT=22 SEQ=1203836498 ACK=0 WINDOW=21357 RES=0x00 SYN URGP=0
Apr 6 16:44:24 kernel: ACCEPT <4>ACCEPT IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=47 ID=61106 DF PROTO=TCP <1>SPT=46709 DPT=22 SEQ=2849169839 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A00200F1D00000000)
Apr 6 16:44:26 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:26 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:27 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:27 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:28 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:29 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:29 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:30 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:30 kernel: ACCEPT <4>ACCEPT IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=48 ID=61883 DF PROTO=TCP <1>SPT=46737 DPT=22 SEQ=2938101967 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A0020117400000000)
Apr 6 16:44:30 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:31 dropbear[6199]: Login attempt for nonexistent user from 41.103.215.126:46709
Apr 6 16:44:32 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:32 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:33 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:33 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:34 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:34 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:35 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:36 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:36 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:37 dropbear[6200]: Login attempt for nonexistent user from 41.103.215.126:46737
Apr 6 16:44:42 kernel: DROP <4>DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=48 ID=34164 DF PROTO=TCP <1>SPT=46778 DPT=22 SEQ=3126301521 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A0020162500000000)
Apr 6 16:44:45 kernel: DROP <4>DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=48 ID=34165 DF PROTO=TCP <1>SPT=46778 DPT=22 SEQ=3126301521 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A0020175100000000)
Apr 6 16:44:51 kernel: DROP <4>DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=48 ID=34166 DF PROTO=TCP <1>SPT=46778 DPT=22 SEQ=3126301521 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A002019A900000000)
Apr 6 16:45:03 kernel: DROP <4>DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=48 ID=34167 DF PROTO=TCP <1>SPT=46778 DPT=22 SEQ=3126301521 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A00201E5900000000)
Apr 6 16:45:27 kernel: DROP <4>DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <1>SRC=41.103.215.126 DST=x.x.x.x <1>LEN=56 TOS=0x00 PREC=0x20 TTL=48 ID=34168 DF PROTO=TCP <1>SPT=46778 DPT=22 SEQ=3126301521 ACK=0 WINDOW=5440 RES=0x00 SYN URGP=0 OPT (020405500402080A002027B900000000)

I have x'ed out the router MAC and my external IP

Why do I have so many login attempts from 41.103.215.126?
I thought the SSHBFP would limit 4 connects in a 60 second period from the same IP to my SSH port.

BTW, my sshd is running on port 22, but only an only a higher (more obscure) port is opened externally that forwards to port 22

Also, FYI here is parts of my iptables -nvL:

admin@RT-AC66R-D700:/tmp/home/root# iptables -nvL | grep SSH
  116  5768 SSHBFP     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW
Chain SSHBFP (1 references)
  116  5768            all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: SET name: SSH side: source
   30  1624 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source

 

[sfx2000]

Your syslog entries show that dropbear is doing what it should be doing... so that's ok.

(one must ask -- why open an ssh port to the outside world directly on the fireware/gateway, but that's another discussion)

What I do...

/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j LOGDROP

In another thread - RMerlin and I had a similar discussion - and this is very similar to what he implemented in his fork - if one is not mucking about outside of his defaults, and options, should be ok.

And now I'll drop the real question - why are you opening up a port into your router/gateway directly? Especially these days, when routers and internet of things kind of devices are under some serious attack.

If there's not a valid need, then don't open the port/service - just asking for some trouble here - if the bots see the port open, they're going to note it, and start hammering it...

Don't be a nail if you don't need to be.

 

[kvic]

BTW, my sshd is running on port 22, but only an only a higher (more obscure) port is opened externally that forwards to port 22

Did you hand craft all your iptables rules? I can't comment on rules created by firmwares because I never used them.

I would guess your port 22 is not blocked and/or the port forward bypasses the throttle rules as a side effect. From what you posted, throttle rules on WAN (eth0) and port 22. If you accept from WAN on a different port and forward to SSHD, the throttle rules are bypassed.

 

[redhat27]

@sfx2000 there is a valid need. I need to use a ssh tunnel from outside, I do use pubkey auth, and have disabled password auth. A vpn setup will not work for my particular need. My question was how to determine that the brute force protection was working as I thought it would limit the ssh connections from a single source to 4 hits in a 60 sec period.

@kvic , no I did not handcraft these SSHBFP rules (they are from firmware), there are a few rules that I added, but I do not think these syslog entries I posted have anything to do with that.

I would guess your port 22 is not blocked and/or the port forward bypasses the throttle rules as a side effect. From what you posted, throttle rules on WAN (eth0) and port 22. If you accept from WAN on a different port and forward to SSHD, the throttle rules are bypassed.

Thanks, I think you may be correct. Is there a way I can handcraft the iptable rules and disable the brute force on the UI? It is a bit confusing, as the iptables stats show that SSHBFP target has packet counts

 

[redhat27]

I would guess your port 22 is not blocked

I just checked, my port 22 is not open from outside, I can only connect on the higher port that forwards to port 22

So I guess the port forward is bypassing the bfp throttle then

 

[redhat27]

Silly me!
I just noticed on my OP that the FW has changed the ACCEPTs to DROPs in the subsequent attempts from that IP (41.103.215.126). The brute force throttle is working fine as expected. This whole thread is moot.

 

[kvic]

lol. Worth running a more advanced syslog to categorise messages by "apps" and even finer filtering. More info here:

https://www.snbforums.com/threads/configuring-syslog-ng-with-merlin-firmware.35095/

 

[redhat27]

Thanks, I'll give syslog-ng a try. I already have entware-ng setup

 

[RMerlin]

Also, keep in mind that when someone connects to Dropbear, he can make multiple login attempts before Dropbear kicks him out. What brute force protection does it not prevent multiple login attempts, but prevents multiple reconnections attempt. So, for example, if Dropbear allows up to 3 attempts per connection and the throttling limits to 5 connections per minute, it means someone can make 15 attempts per minutes.

That's why you get multiple messages from dropbear in syslog.

 

[RMerlin]

BTW, Asus is implementing a new service in future firmware versions, that will do something a bit similar to by throttling protection, except it will also blacklist repeated offenders. I haven't looked too closely at that new code yet (because it caused my router to crash at boot time when I enabled it), but it will be a nice security improvement once it's finalized.

 

[redhat27]

BTW, Asus is implementing a new service in future firmware versions, that will do something a bit similar to by throttling protection, except it will also blacklist repeated offenders.

That will be nice! I've had to implement similar functionality by hand. I harvest all different kinds of of login failures from:

• dropbear (that has the text "Login attempt for nonexistent user from ", "Client trying multiple usernames from ", "Pubkey auth bad signature for", etc.
• shadowsocks (shadowsocks login strings)

And add those IPs to a ipset (and also store them) for blocking future connects (even after router restarts).

 

[martinr]

Silly me!
........ This whole thread is moot.

Not at all. A very interesting read.

 

[john9527]

BTW, Asus is implementing a new service in future firmware versions, that will do something a bit similar to by throttling protection, except it will also blacklist repeated offenders. I haven't looked too closely at that new code yet (because it caused my router to crash at boot time when I enabled it), but it will be a nice security improvement once it's finalized.

Just an FYI....also crashes my AC68 at boot when I backported it.

 

[sfx2000]

@sfx2000 there is a valid need. I need to use a ssh tunnel from outside, I do use pubkey auth, and have disabled password auth. A vpn setup will not work for my particular need. My question was how to determine that the brute force protection was working as I thought it would limit the ssh connections from a single source to 4 hits in a 60 sec period.

It's not unusual to see patterns like what was observed in the original post - keep in mind that this really isn't a focused DOS/DDOS type of "attack" - it's bots looking for open ports... so once one is found, it'll check and move on...

There are a couple of members that have created scripts that parse the logs, and add IP's via ipset to deny persistent IP's..

 

[RMerlin]

Just an FYI....also crashes my AC68 at boot when I backported it.

Hm. I'd have to check their actual firmware release to see if that library was enabled in it, despite the fact that in the GPL it's enabled by default in config_base.