Dropbear changes preventing Arq backup?

[Travler]

For 2016, I has Arq backing up my computers to a USB hd hanging off my 68u router. I was using SFTP (entware) to as the protocol. Everything was working great -- happy happy.

Sometime 'in the last few months' this stopped working. At first I didn't think too much about it, but now it has been several months and I need to sort it out. I noticed that Dropbear has been updated several times in 2017 firmware updates (I'm typically timely with my updates; on 380.66_6 now).

Now Arq gets rejected by Dropbear because of too many (successful) logins during a period of time (~10s). (log below)

I have confirm with the Arq developer that they haven't made changes to how they connect and how many connections they make. They say they are doing the same thing in 2017 that they did in 2016.

Did Dropbear up its security game? Is there a way to relax it a bit? GUI setting or some text file to tweak?

TIA


```
Jun 26 09:56:36 dropbear[21758]: Child connection from 192.168.1.100:53432
Jun 26 09:56:37 dropbear[21758]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53432
Jun 26 09:56:37 dropbear[21758]: Exit (belmontadmin): Exited normally
Jun 26 09:56:38 dropbear[21762]: Child connection from 192.168.1.100:53450
Jun 26 09:56:38 dropbear[21762]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53450
Jun 26 09:56:40 dropbear[21762]: Exit (belmontadmin): Exited normally
Jun 26 09:56:40 dropbear[21765]: Child connection from 192.168.1.100:53452
Jun 26 09:56:41 dropbear[21765]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53452
Jun 26 09:56:42 dropbear[21769]: Child connection from 192.168.1.100:53453
Jun 26 09:56:42 dropbear[21769]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53453
Jun 26 09:56:42 dropbear[21769]: Exit (belmontadmin): Exited normally
Jun 26 09:56:42 dropbear[21765]: Exit (belmontadmin): Exited normally
Jun 26 09:56:43 dropbear[21792]: Child connection from 192.168.1.100:53455
Jun 26 09:56:44 dropbear[21792]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53455
Jun 26 09:56:45 dropbear[21795]: Child connection from 192.168.1.100:53457
Jun 26 09:56:46 dropbear[21795]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53457
Jun 26 09:56:46 dropbear[21795]: Exit (belmontadmin): Exited normally
Jun 26 09:56:47 syslog: Detect [192.168.1.100] abnormal logins many times, system will block this IP 5 minutes.
```

 

[Adamm]

For 2016, I has Arq backing up my computers to a USB hd hanging off my 68u router. I was using SFTP (entware) to as the protocol. Everything was working great -- happy happy.

Sometime 'in the last few months' this stopped working. At first I didn't think too much about it, but now it has been several months and I need to sort it out. I noticed that Dropbear has been updated several times in 2017 firmware updates (I'm typically timely with my updates; on 380.66_6 now).

Now Arq gets rejected by Dropbear because of too many (successful) logins during a period of time (~10s). (log below)

I have confirm with the Arq developer that they haven't made changes to how they connect and how many connections they make. They say they are doing the same thing in 2017 that they did in 2016.

Did Dropbear up its security game? Is there a way to relax it a bit? GUI setting or some text file to tweak?

TIA


```
Jun 26 09:56:36 dropbear[21758]: Child connection from 192.168.1.100:53432
Jun 26 09:56:37 dropbear[21758]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53432
Jun 26 09:56:37 dropbear[21758]: Exit (belmontadmin): Exited normally
Jun 26 09:56:38 dropbear[21762]: Child connection from 192.168.1.100:53450
Jun 26 09:56:38 dropbear[21762]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53450
Jun 26 09:56:40 dropbear[21762]: Exit (belmontadmin): Exited normally
Jun 26 09:56:40 dropbear[21765]: Child connection from 192.168.1.100:53452
Jun 26 09:56:41 dropbear[21765]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53452
Jun 26 09:56:42 dropbear[21769]: Child connection from 192.168.1.100:53453
Jun 26 09:56:42 dropbear[21769]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53453
Jun 26 09:56:42 dropbear[21769]: Exit (belmontadmin): Exited normally
Jun 26 09:56:42 dropbear[21765]: Exit (belmontadmin): Exited normally
Jun 26 09:56:43 dropbear[21792]: Child connection from 192.168.1.100:53455
Jun 26 09:56:44 dropbear[21792]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53455
Jun 26 09:56:45 dropbear[21795]: Child connection from 192.168.1.100:53457
Jun 26 09:56:46 dropbear[21795]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53457
Jun 26 09:56:46 dropbear[21795]: Exit (belmontadmin): Exited normally
Jun 26 09:56:47 syslog: Detect [192.168.1.100] abnormal logins many times, system will block this IP 5 minutes.
```

Asus's BFD uses the iptables ipt_recent module. That means any connection on your SSH port that goes over this limit (It has been lowered to 4 attempts per 60 seconds in the latest releases) gets temporarily blocked. The only way to bypass this would be to disable SSH BFD (a bad idea). Or if the backup server has a static IP, you can make an accept rule at the top of the SSHBFP chain.

I've actually never seen the syslog printing of a ban (and I can't find code reference to it on the git repo) so there may also be some secondary detection, but the 4 connections per 60 seconds is definitely a limitation that Arq will be triggering.

 

[Travler]

yay -- there is a clear answer that makes general sense to me.

Questions:

1. BFD? Something Fault Detection?

2. Can you provide a pointer adding a rule to the SSHBFP chain? I'm hoping just editing a text file, assuming there isn't a GUI in merlin.

TIA

 

[Adamm]

1. BFD? Something Fault Detection?

Brute force detection (sometimes referenced as BFP - Brute force protection)

2. Can you provide a pointer adding a rule to the SSHBFP chain? I'm hoping just editing a text file, assuming there isn't a GUI in merlin.

Going by the logs you posted, Arq uses the IP 192.168.1.100 to-do whatever it needs. First you will want to make sure this machine has a static IP address (you can do this in the UI)

Second of all, you will want to design an IPTables rule, assuming again 192.168.1.100 is the IP Arq will use, you will want to modify your /jffs/scripts/firewall-start file to look like the following;

#!/bin/sh

iptables -I SSHBFP -s 192.168.1.100 -j ACCEPT

Please also make sure custom scripts is enabled in the UI. After doing all this type in SSH;

service restart_firewall

This will apply the changes for the current session without the need of a reboot.

 

[RMerlin]

Note that they are currently two different types of BFP in the firmware. The option on the webui is the one I implemented years ago. And recent firmware release have a new one implemented by Asus, and which isn't user-controlable (and starting with firmware 382, the source code to that new protection will be closed source).

I'm not a big fan of how Asus implemented their protection. I'm still debating what to do about it, either disable it, or at least make sure it works in a sane way.

 

[sfx2000]

Is it just me?

Jun 26 09:56:45 dropbear[21795]: Child connection from 192.168.1.100:53457
Jun 26 09:56:46 dropbear[21795]: Password auth succeeded for 'belmontadmin' from 192.168.1.100:53457
Jun 26 09:56:46 dropbear[21795]: Exit (belmontadmin): Exited normally
Jun 26 09:56:47 syslog: Detect [192.168.1.100] abnormal logins many times, system will block this IP 5 minutes

Dropbear is reporting successful connections, so it's not likely at fault - if one were to stick shift this by hand, and use bad credentials, you should see dropbear reporting something different.

Perhaps like mentioned above however, Asus' BFD is just triggering on port activity, and not whether the session is successful or not - so it thinks it's a denial of service attack at the network level, even though at the application layer, it's all good, and desired...

Weird...

 

[Adamm]

Note that they are currently two different types of BFP in the firmware. The option on the webui is the one I implemented years ago. And recent firmware release have a new one implemented by Asus, and which isn't user-controlable (and starting with firmware 382, the source code to that new protection will be closed source).

I'm not a big fan of how Asus implemented their protection. I'm still debating what to do about it, either disable it, or at least make sure it works in a sane way.

That makes a lot more sense to why I couldn't find the code in the GPL merge commit. I feel like counting successful attempts is a pretty silly idea, but being closed source it leaves you with limited options in dealing with it. Your iptables implementation of BFP at-least can be modified by the user like I do in my script. Is it possible to disable Asus's implementation post-compile, give the user an option possibly to select "Asus / Merlin / None" for the BFP switch in the UI?

Also I assume their BFP applies at all times where as your's only applies if WAN logins are enabled. The only way I can see this being useful is if some sort of malware on your computer attempts to gain access?

 

[RMerlin]

That makes a lot more sense to why I couldn't find the code in the GPL merge commit. I feel like counting successful attempts is a pretty silly idea, but being closed source it leaves you with limited options in dealing with it.

Note that the protection_server code is still open sourced in 380. It's the next version in 382 that won't be.

Is it possible to disable Asus's implementation post-compile, give the user an option possibly to select "Asus / Merlin / None" for the BFP switch in the UI?

Not in an easy way. Asus' implementation actually involves modifying the source code of busybox (telnetd) and dropbear (ssh), is is one of the things that bothers me with their implementation. You'd have to disable it at compile time.

Also I assume their BFP applies at all times where as your's only applies if WAN logins are enabled.

Correct. I might change that in the future tho, as a compromised client might attempt a brute force attack against your router.

 

[sfx2000]

Correct. I might change that in the future tho, as a compromised client might attempt a brute force attack against your router.

Some of the IoT botnet worms could trigger behavior - not intending to hack the router specifically, but anything that has a port open.

 

[Travler]

I find this really interesting -- also love the deep knowledge on the happenings of the firmware. Makes me happy to run Merlin.

Another thread seems to have an iptables addition that might change the "4per60s Rule". I assume this would change it for the LAN and WAN, though, so be more vulnerable than allowing the static IP address, like Adamm suggested. But is this line changing the Asus settings? I'm new to iptables, but this seems like it might be relevant to the discussion of making them behave better.

```
-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j logdrop
```

 

[Adamm]

I find this really interesting -- also love the deep knowledge on the happenings of the firmware. Makes me happy to run Merlin.

Another thread seems to have an iptables addition that might change the "4per60s Rule". I assume this would change it for the LAN and WAN, though, so be more vulnerable than allowing the static IP address, like Adamm suggested. But is this line changing the Asus settings? I'm new to iptables, but this seems like it might be relevant to the discussion of making them behave better.

```
-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j logdrop
```

That is the rule I was referencing and that Merlin added himself, theres also another new implementation by asus called protection_server which is what you were actually triggering, but disabling it will have to be done at compile time.