OpenWrt Forum Archive

Topic: Fail2ban replacement and RBL firewall sync'ing - in lightweight ash

The content of this topic has been archived between 5 Apr 2018 and 29 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I noticed that my mbedTLS is version 1.3.16, so that may be it. I was looking back through the patches for something but nothing jumped out. My build is at r48443 if that matters.

robzr wrote:

I haven't experienced this, but it may be a known issue with newer curl builds on OpenWRT: https://dev.openwrt.org/ticket/19621

From what it looks like to me, curl (or rather the mbedTLS library, formerly known as PolarSSL) is not recognizing the root cert bundle and/or directory.  The ca-certificates package loads a directory with root certs and then generates hash links to the cert files.  The other method that people seem to use is to install a single cert bundle (one file with all the certs concatenated), which is what the http://curl.haxx.se/ca/cacert.pem file is.  The compiled in options in curl/mbedTLS should read at least the directory (maybe the file too).  Try this: "curl --cafile /etc/ssl/certs/ca-certificates.crt https://lists.blocklist.de/lists/ssh.txt"

If that still fails, try uninstalling the ca-certificates bundle; make sure that the only file in /etc/ssl/certs is ca-certificates.crt (the bundle), and then try it again.  Depending on the precedence that mbedTLS loads the cert files/bundles with, you might have a conflict there.

As a final band-aid you can also try "curl --insecure https://lists.blocklist.de/lists/ssh.txt" and see if that lets you sidestep the cert issue until this gets fixed.

Rob

Thanks Rob.  Unfortunately '--cafile' is not an available option for the version of curl that I have running on openwrt.  I'll rebuild without ca-certificates, then I'll try installing them separately.  I'll report back.  Thanks for all of your help and sorry to be such a pain.

Mike

mmcneil wrote:

Thanks Rob.  Unfortunately '--cafile' is not an available option for the version of curl that I have running on openwrt.  I'll rebuild without ca-certificates, then I'll try installing them separately.  I'll report back.  Thanks for all of your help and sorry to be such a pain.

Mike

Sounds like you're not the only one having trouble with curl.  Here's a workaround - grab the newest version of sub2rbl, and install the wget and openssl-util packages.  sub2rbl will use that first if it's available (then curl, then busybox/wget).  It takes up more space than curl, but it's an easy fix.  If you want to force a particular command or adjust the options, use the uci config option "webGetCmd".  You can see the default arguments for each version around line 30 in sub2rbl.

Rob

(Last edited by robzr on 22 Jan 2016, 00:34)

Because some people are using bearDropper to monitor more than just dropbear, I changed the regex filtering logic that determines which log lines are examined.  It is now done in a uci config list, which is then assembled at runtime into a sed script file.  This should make it a lot easier and more readable while adding additional filtering rules.  Anyone who is upgrading to this newer version should make sure to grab the new config file in github, or add the following:

  # Log scanning regexs for those who want to extend the pattern matching. These are run in order
  # by "sed -nE". The IP blocked by bearDropper is the first one encountered in the log line, so
  # if the log line you are scanning for has multiple IPs.  Put /d (delete) entries before /p (print) entries.
        list    logRegex 's/[`$"'\\\'']//g'            # strip escape chars
        list    logRegex '/has invalid shell, rejected$/d'    # delete (/d) - use to filter out
        list    logRegex '/ authpriv.warn dropbear\[/p'        # print (/p) - use to filter in 

The comments should be self-explanatory.  The default behavior has not changed.  The old "regexLogString" is no longer used, so anyone who was using a modified version will need to convert it to another list element. 

wyf88 - add this to the end of the list to retain your ss-server filtering:

        list    logRegex '\# kern.err /usr/bin/ss-server\[#p'

bouwew - add this to the end of your list:

        list    logRegex '/ daemon.info .*invalid IKE header/p'

Rob

robzr wrote:

bouwew - add this to the end of your list:

        list    logRegex '/ daemon.info .*invalid IKE header/p'

Rob

Got it, thanks!!

I just fixed a bug in bearDropper's expiration logic; expired entries were not purging from the state database (they were purging from the firewall though).  I'd recommend anyone using bearDropper download the newest version.

Rob

Hi robzr.  I had a quick question regarding bearDropper.  I installed it on my openwrt routers as per your instructions and a 'ps | grep bearDropper shows that it's running, however, when I check my logs I see the following message every 30 minutes:

bearDropper[7247]: loadState() loaded 0 entries

Does this indicate a configuration problem of some sort?

Thanks,

Mike

mmcneil wrote:

Hi robzr.  I had a quick question regarding bearDropper.  I installed it on my openwrt routers as per your instructions and a 'ps | grep bearDropper shows that it's running, however, when I check my logs I see the following message every 30 minutes:

bearDropper[7247]: loadState() loaded 0 entries

Does this indicate a configuration problem of some sort?

Thanks,

Mike

Hi Mike - that line should only be output if you have logging set to verbose or debug (see the "option logLevel" line in /etc/config/bearDropper).  But it sounds like it's not finding any bad login attempts in your syslog which would be pretty unusual if your wan interface is on the internet and aren't doing any other firewalling on 22/tcp.  Out of curiosity, what do you get when you run:

logread | grep authpriv.warn\ dropbear | wc -l

Rob

(Last edited by robzr on 15 Feb 2016, 23:34)

robzr wrote:
mmcneil wrote:

Hi robzr.  I had a quick question regarding bearDropper.  I installed it on my openwrt routers as per your instructions and a 'ps | grep bearDropper shows that it's running, however, when I check my logs I see the following message every 30 minutes:

bearDropper[7247]: loadState() loaded 0 entries

Does this indicate a configuration problem of some sort?

Thanks,

Mike

Hi Mike - that line should only be output if you have logging set to verbose or debug (see the "option logLevel" line in /etc/config/bearDropper).  But it sounds like it's not finding any bad login attempts in your syslog which would be pretty unusual if your wan interface is on the internet and aren't doing any other firewalling on 22/tcp.  Out of curiosity, what do you get when you run:

logread | grep authpriv.warn\ dropbear | wc -l

Rob

Hi Rob.  Thanks for getting back.  Here's the output:

root@lnxs-rtr:~# logread | grep authpriv.warn\ dropbear | wc -l
0

So, nothing in the logs.. Let me check my firewall ruleset

Thanks,

EDIT:

Here's what I see in my logs ( my firewall zones log to my syslog server )

2016-02-16T08:10:16-08:00 lnxs-rtr.mac6.net kernel: [202695.870717] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=31.44.188.50 DST=104.49.221.253 LEN=48 TOS=0x00 PREC=0x00 TTL=106 ID=3816 DF PROTO=TCP SPT=62118 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

2016-02-16T08:54:49-08:00 lnxs-rtr.mac6.net kernel: [205368.715740] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=40.121.92.29 DST=104.49.221.253 LEN=48 TOS=0x00 PREC=0x00 TTL=109 ID=59374 PROTO=TCP SPT=49496 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

2016-02-16T09:31:39-08:00 lnxs-rtr.mac6.net kernel: [207578.240481] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=94.113.252.51 DST=104.49.221.253 LEN=48 TOS=0x00 PREC=0x00 TTL=102 ID=13461 PROTO=TCP SPT=7836 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

2016-02-16T12:28:16-08:00 lnxs-rtr.mac6.net kernel: [218175.644907] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=106.185.29.176 DST=104.49.221.253 LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=TCP SPT=50540 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

2016-02-16T12:38:38-08:00 lnxs-rtr.mac6.net kernel: [218797.591323] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=179.107.99.58 DST=104.49.221.253 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=31115 PROTO=TCP SPT=2112 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

2016-02-16T12:46:11-08:00 lnxs-rtr.mac6.net kernel: [219250.606639] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=42.113.159.113 DST=104.49.221.253 LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=22601 DF PROTO=TCP SPT=17243 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

2016-02-16T12:46:12-08:00 lnxs-rtr.mac6.net kernel: [219251.323902] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=42.113.159.113 DST=104.49.221.253 LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=22650 DF PROTO=TCP SPT=17243 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

So the firewall is clearly rejecting inbound traffic destined for port 22, however, I don't understand why bearDropper isn't picking it up.


Mike

(Last edited by mmcneil on 17 Feb 2016, 03:24)

mmcneil wrote:

2016-02-16T08:10:16-08:00 lnxs-rtr.mac6.net kernel: [202695.870717] REJECT(src wan)IN=eth0 OUT= MAC=c0:56:27:77:60:ab:94:62:69:75:16:50:08:00 SRC=31.44.188.50 DST=104.49.221.253 LEN=48 TOS=0x00 PREC=0x00 TTL=106 ID=3816 DF PROTO=TCP SPT=62118 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

Mike

Hey Mike - so I think there's a couple things going on here:

- bearDropper works by examining the dropbear syslog messages that are logged when there are failed authentication attempts; in your case at least some of the traffic is being blocked by iptables before it even makes it to dropbear (the ssh server), so there is no authentication attempt at all.  Do you know what criteria you are using for blocking ssh in the firewall?

- if you're logging to a remote syslog server, then I don't think the log entries would make it into the local syslog ring buffer (but I could be wrong about this).  bearDropper runs locally on the OpenWRT box and examines the local syslog ring buffer.  We can verify if any logging at all makes it into the local ring buffer if you do a "logread | wc -l"

Rob

Rob,

I've verified that the logging is indeed making it to the ring buffer.  You're correct in that the firewall is blocking ALL SSH traffic coming in from the WAN interface and therefore preventing anything from showing up in the logs. As for the criteria for blocking ssh, I'm simply using the default iptables ruleset.  I'm a complete noob to iptables, so forgive me.  How would I go about creating/modifying a rule for ssh?

Thanks,

Mike

They easiest way is to edit /etc/config/firewall - the documentation is https://wiki.openwrt.org/doc/uci/firewall  The first example under "Opening ports" is exactly what you're looking for wink

Rob

Never mind, the issue is gone in build r48933.

Hi Rob,

Just updated my router (to Arokh's WDR4900-build r48874) and installed bearDropper again.
Logs show something strange:

root@router ~# wget -qO- http://rawgit.com/robzr/bearDropper/master/install.sh | sh
Detected previous version of bearDropper - stopping
Stopping bearDropper 7258
Retrieving and installing latest version...
Processing historical log data
Running in entire mode
processLogLine(,1457088093) malformed line (Fri Mar  4 11:41:33 2016 authpriv.warn dropbear[4847]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)
processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.warn dropbear[4846]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)
processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.warn dropbear[4846]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))
processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.warn dropbear[4846]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)))
processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088367) malformed line (Fri Mar  4 11:46:07 2016 authpriv.warn dropbear[4846]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))))
processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.warn dropbear[5906]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)
processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.warn dropbear[5906]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))
processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.warn dropbear[5906]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)))
processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.warn dropbear[5906]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))))
processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457088885) malformed line (Fri Mar  4 11:54:45 2016 authpriv.warn dropbear[5906]: wtmp_write: problem writing /dev/null/wtFri Mar  4 11:57:33 2016 authpriv.notice sub2rbl[6092]: RBL (https://www.openbl.org/lists/base_30days.txt) added 2049 entries)
processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.warn dropbear[5899]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)
processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.warn dropbear[5899]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))
processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.warn dropbear[5899]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)))
processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089059) malformed line (Fri Mar  4 11:57:39 2016 authpriv.warn dropbear[5899]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))))
processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.warn dropbear[6519]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)
processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.warn dropbear[6519]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))
processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.warn dropbear[6519]: wtmp_write: problem writing /dev/null/wtmp: Not a directory)))
processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.warn dropbear[6519]: wtmp_write: problem writing /dev/null/wtmp: Not a directory))))
processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.notice bearDropper[5341]: processLogLine(,1457089121) malformed line (Fri Mar  4 11:58:41 2016 authpriv.warn dropbear[6519]: wtmp_write: problem writing /dev/null/wtFri Mar  4 11:59:22 2016 authpriv.notice bearDropper[7258]: Running in follow mode)
Starting background process
Starting bearDropper

Any idea what's wrong?

(Last edited by bouwew on 7 Mar 2016, 10:37)

Hi bouwew - sorry about the delay - so it looks like dropbear was using authpriv.warn facility to report the wtmp issue, and the bearDropper regex's were a little too dumb, so they picked up on that, and then they picked up on bearDropper itself reporting the bad log line.  I hadn't seen that before, but it makes perfect sense.

I fixed the regex's, it's one line in bearDropper and one line in the config file - check github for the updates.  Thanks for bringing this to my attention.

Rob

Forgive my ignorance, i'm fairly new to Openwrt, but are BearDropper and Sub2rbl complimentary to each other and meant to be installed together or are they two scripts that do similar things only differently?
Also, I am running Arokh's build on my Wrt1900AC v2 and it already has dropbrute, how do I disable and get rid of dropbrute and replace it with BearDropper and/or Sub2rbl. Thanks in advance

They are complementary.  Sub2RBL downloads existing lists of IPs known to be sources of bad scanning activity and blocks them.  bearDropper will monitor your system logs to find IPs who are actively scanning you, and then block those.

If you run Sub2RBL, then bearDropper in theory won't have to do as much work.  I'd recommend you run them both smile

Rob

robzr wrote:

They are complementary.  Sub2RBL downloads existing lists of IPs known to be sources of bad scanning activity and blocks them.  bearDropper will monitor your system logs to find IPs who are actively scanning you, and then block those.

If you run Sub2RBL, then bearDropper in theory won't have to do as much work.  I'd recommend you run them both smile

Rob

Thanks for the  quick answer. How about the removing of dropbrute, how do I go about that? I don't see it in the system > software tab so I'm guessing I need to remove it manually somehow. Isn't it just an older less capable  version of beardropper?

Would I just delete dropbrute.sh from /usr/sbin and delete dropbrute.leases & dropbrute.log from /tmp. Then via web interface remove this line, (*/10 * * * * /usr/sbin/dropBrute.sh 2>&1 >> /tmp/dropBrute.log), from System > Scheduled Tasks. And remove theses lines,

(# SSH brute force protection
WAN=`uci get network.wan.ifname`
iptables -w -N logndrop
iptables -w -N dropBrute
iptables -w -A logndrop -j LOG
iptables -w -A logndrop -j DROP
# Allow max 4 new SSH connections pr minute
iptables -w -A input_rule -p tcp --dport 22 -i $WAN -m state --state NEW -m recent --set
iptables -w -A input_rule -p tcp --dport 22 -i $WAN -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j logndrop
# Check for bans in the dropBrute chain
iptables -w -A input_rule -p tcp --dport 22 -j dropBrute
),

from Network > Firewall > Custom Rules, or is there more to it than that?

Thanks again for any help you may provide.

(Last edited by FreeByrdE on 27 Apr 2016, 03:56)

Hi, you are right, it is an older and simpler version, bearDropper is improved pretty much across the board.

I would remove everything you cited, including the rate limiting of ssh connections.  The bearDropper installation is pretty simple in comparison.

Rob

so after I remove all those iptable entries do I need to create any new ones in their place manually or does the Beardropper and Sub2Rbl install scripts take care of all that is needed in that regard. Sorry for being a pest, I'm just new to Openwrt. Been using DD-Wrt for years and tried Tomato but OpenWrt is a whole other beast, it's so flexible and configurable it's a bit overwhelming.

Yah, just follow the instructions for installing on the github pages, it's pretty short & sweet and that's all you need to do smile

Good luck with OpenWRT, it's a great little OS.

Rob

Hi Rob,

Think bearDropper is really very good.  An anomaly/enhancement request.... Last night I had a persistent person connecting in 'batches' to dropbear, not authenticating and then disconnecting; eg.

Tue May  3 23:01:19 2016 authpriv.info dropbear[6571]: Child connection from 121.42.203.212:50425
Tue May  3 23:01:19 2016 authpriv.info dropbear[6576]: Child connection from 121.42.203.212:50565
Tue May  3 23:01:19 2016 authpriv.info dropbear[6581]: Child connection from 121.42.203.212:50700
Tue May  3 23:01:19 2016 authpriv.info dropbear[6586]: Child connection from 121.42.203.212:50840
Tue May  3 23:01:19 2016 authpriv.info dropbear[6591]: Child connection from 121.42.203.212:50981
Tue May  3 23:01:19 2016 authpriv.info dropbear[6571]: Exit before auth: Exited normally
Tue May  3 23:01:19 2016 authpriv.info dropbear[6576]: Exit before auth: Exited normally
Tue May  3 23:01:19 2016 authpriv.info dropbear[6604]: Child connection from 121.42.203.212:51161
Tue May  3 23:01:20 2016 authpriv.info dropbear[6586]: Exit before auth: Exited normally
Tue May  3 23:01:20 2016 authpriv.info dropbear[6591]: Exit before auth: Exited normally
Tue May  3 23:01:20 2016 authpriv.info dropbear[6604]: Exit before auth: Exited normally
Tue May  3 23:01:21 2016 authpriv.info dropbear[6581]: Exit before auth: Exited normally

The normal exits are ignored by bearDropper and there's no harm done as such...but I do think persistent 'do nothing' connections like this should be banned.  Is that possible with a tweak of the sed strings (I hate regexp :-) or does it need a tweak to dropbear to report IP addresses in the 'exit before auth' report?

thanks for your time,

Kevin

Hi Kevin - so this one is not a simple regex tweak, because unlike the authpriv.warn errors, the error message and the IP address are not on the same line.

This could be added but it would require tracking the "Child connection from 121.42.203.212" lines in order to correlate the PID of the child process with the IP address; then the main tracking logic would have to make a special case out of the "Exit before auth" errors, to go back and correlate the PID with the IP from the previous statement in order to know what IP to add to the ban list.

It'd be a (moderate, not huge) amount of work to add this to bearDropper in an intelligent and efficient way.

As an interim step, it would be pretty trivial to make a second script which could monitor exactly for this situation, and then inject a new single log entry into the log buffer that bearDropper would parse.  That would also make testing easier so I could eventually integrate that logic back in bearDropper.  Hrmmm...

Last comment - if this were in bash it would be much easier, unfortunately ash does not support arrays (amongst other limitations).  For bddb tracking I had to essentially write hash-like data structure handling from scratch (including expiration and purging so memory use does not run away), and it's tedious and relatively inefficient.  A couple ideas are coming to mind, like a quasi-array with a fixed number of elements that would be pretty simple to implement, or possibly extending bddb....

Rob

(Last edited by robzr on 7 May 2016, 21:32)

Thanks Rob,

Did you also see the issue I raised on github?

Cheers,

Kevin

Hey Kevin - I didn't see that, thanks for the heads up, as well as troubleshooting it - that makes it a lot easier!  I'll check it out and respond on GitHub.

Rob

Kevin - I added in support for banning "Exit before auth:" entries by just hooking into getLogIP, it took just 6 extra lines.  Instead of maintaining another db in memory, it does one extra sed statement to determine if it is an "Exit before auth:", and if so it scans the log buffer to get the corresponding connection log entry, and parses the IP from that.

So it does add a little extra overhead, but it is (somewhat) tuneable via cmdLogreadEba (if using a very long ring buffer, it may be advisable to add a "-l 1000" or something here; but it would come at the expense of the ability to run an entire scan and get entries older than the last 1000 lines...)

Anyways, it's up on GitHub, the config file needed a slight change so if you're using a custom config you'll have to manually add another logRegex.  If using the stock config, the one on GitHub is correct.

I had wanted to add this in a while back, because if you turn off password auth (using key based only), a lot more is logged like this, so now it works with password-less configs...

Rob