Date: Thu, 9 Nov 2017 14:25:52 +0100 From: Cos Chan <rosettas@gmail.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-questions <freebsd-questions@freebsd.org>, Michael Ross <gmx@ross.cx>, Kurt Lidl <lidl@freebsd.org> Subject: Re: How to setup IPFW working with blacklistd Message-ID: <CAKV%2BxLAkfiQCLXfgZOtQGUXOW8gYN7sjOD5uWezv-N%2BTBjybMQ@mail.gmail.com> In-Reply-To: <CAKV%2BxLCQ9NE6%2BEg6NvHZuEED8Cf6ZX74unvk9ajfLyG-yA2rXA@mail.gmail.com> References: <mailman.87.1509969603.28633.freebsd-questions@freebsd.org> <20171106235944.U9710@sola.nimnet.asn.au> <CAKV%2BxLCizjt5M%2BmJmTZj-cr=D6rhXRwDjCkE=6Q-VQX73iY%2B4A@mail.gmail.com> <20171107033226.M9710@sola.nimnet.asn.au> <CAKV%2BxLBWgU6zmc7tQNA=0%2B=2aF23C1QfJ2i3q1gKYDttwsCTkg@mail.gmail.com> <20171107162914.G9710@sola.nimnet.asn.au> <CAKV%2BxLDQQcG3bvo1b2nUAu7oOVhdNzDDrPWTVp2qOmkWVV89BQ@mail.gmail.com> <20171108012948.A9710@sola.nimnet.asn.au> <CAKV%2BxLCQ9NE6%2BEg6NvHZuEED8Cf6ZX74unvk9ajfLyG-yA2rXA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear All
Thanks Ian's great help, I have solved problem to post banned entries from
blacklistd to ipfw.
To my knowledge the problem is:
I setup sshd+blacklistd without ipfw at first. Then I got problem the entry
was never reached nfail number (is it a bug?).
so I have to change the nfail to * to get the entry into banned list.
But while I setup ipfw, the nfail=* would not activate blacklistd-helper so
no entry in blacklist banned list were added to ipfw.
I have modify the blacklistd nfail to 2, sshd MaxAuthTries to 3. The
blacklist entries working fine.
BUT I found another problem.
The output of blacklist dump is strange:
$ sudo blacklistctl dump
address/ma:port id nfail last access
96.227.104.132/32:22 0/2 1970/01/01 01:00:00
89.245.78.187/32:22 0/2 1970/01/01 01:00:00
116.193.162.203/32:22 1/2 2017/11/09 11:48:05
Since the blacklistd accepts instruction from sshd. how could be 0/2
entries presented there? I am sure my successful logins were not added to
blacklistd.
I am trying to find out the reason from log but I dont know how to see
blacklistd log. man page said that is to syslogd but what the facility it
is? or some other ways to get out log?
On Tue, Nov 7, 2017 at 10:10 PM, Cos Chan <rosettas@gmail.com> wrote:
> On Tue, Nov 7, 2017 at 4:10 PM, Ian Smith <smithi@nimnet.asn.au> wrote:
>
>> On Tue, 7 Nov 2017 12:09:31 +0100, Cos Chan wrote:
>> > On Tue, Nov 7, 2017 at 7:17 AM, Ian Smith <smithi@nimnet.asn.au>
>> wrote:
>> >
>> > > On Mon, 6 Nov 2017 22:43:02 +0100, Cos Chan wrote:
>> > >
>> > > > On Mon, Nov 6, 2017 at 5:50 PM, Ian Smith <smithi@nimnet.asn.au>
>> wrote:
>> > > >
>> > > > > On Mon, 6 Nov 2017 16:41:41 +0100, Cos Chan wrote:
>> > > > > > On Mon, Nov 6, 2017 at 3:09 PM, Ian Smith <
>> smithi@nimnet.asn.au>
>> > > wrote:
>> > >
>> > > [ time to cut mightily .. also cc'ing blacklistd maintainer Kurt Lidl
>> > > <lidl@FreeBSD.org> for whom I'll point to the start of this thread
>> at:
>> > > https://lists.freebsd.org/pipermail/freebsd-questions/
>> > > 2017-November/279598.html
>> > > ]
>>
>> At this time it seems Kurt may not have received this yet ..
>>
>> from mx2.freebsd.org [8.8.178.116]
>> ----- Transcript of session follows -----
>> <lidl@pix.net>... Deferred: Operation timed out with hydra.pix.net.
>> Warning: message still undelivered after 4 hours
>> Will keep trying until message is 1 week, 3 days old
>>
>> > > I suppose you will have created the flagfile?
>> > > # echo 'ipfw_offset=4000' > /etc/ipfw-blacklist.rc
>> > > You could put that in /etc/rc.local to be sure it survives updates.
>> >
>> > Exactly, I followed all steps same as https://people.freebsd.org/~
>> > lidl/blacklistd.html except the patch updating since my server is i386.
>>
>> Hopefully that won't matter as those patches should be in 11.1 i386 too.
>>
>> > > % rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
>> >
>> > the output:
>> > $ rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
>> > /etc/rc.d/ipfw
>> > /etc/rc.d/blacklistd
>>
>> Right.
>>
>> > > Secondly, once ipfw's up, you could manually start blacklistd with
>> the
>> > > -d switch (maybe -dv) to run it in forground while it's getting
>> going to
>> > > see what it reports. -C seems to be default, but your use of -r
>> seems
>> > > smart as ipfw doesn't maintain tables across runs (without
>> scripting).
>> > >
>> > > You could also try uncommenting the 'set -x' in blacklistd-helper to
>> get
>> > > a blow-by-blow list (to stderr) of its progress while doing its
>> thing,
>> > > which should provide some solid clues.
>> > >
>> >
>> > I have tried to run
>> > $ sudo blacklistd -dvr
>> > and
>> > $sudo blacklistd -dvr -C /usr/libexec/blacklistd-helper
>> >
>> > got same result:
>> >
>> > [local]
>> > target type proto owner name nfail
>> duration
>> > 25 6 * * * 2 *
>> > 22 6 * * * * *
>> > 21 6 * * * 2 *
>> > [remote]
>> > source type proto owner name nfail
>> duration
>> > Connected to blacklist server
>> > received 0 from poll()
>> > ...
>> > received 1 from poll()
>> > processing type=4 fd=5 remote=121.201.96.113:19720 msg=user uid=0
>> gid=0
>> > listening socket: 192.168.11.15:22
>> > look: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=,
>> nfail:*,
>> > duration:*
>> > check: target:25, proto:6, family:*, uid:*, name:*, nfail:2,
>> duration:*
>> > check: target:22, proto:6, family:*, uid:*, name:*, nfail:*,
>> duration:*
>> > found: target:22, proto:6, family:*, uid:*, name:*, nfail:*,
>> duration:*
>>
>> Doesn't nfail:* mean to never fail these matches? From
>> blacklistd.conf(5):
>>
>> The nfail field contains the number of failed attempts before access
>> is
>> blocked, defaulting to ``*'' meaning never, and the last field
>> disable
>> specifies the amount of time since the last access that the blocking
>> rule
>> should be active, defaulting to ``*'' meaning forever. The default
>> unit
>> for disable is seconds, but one can specify suffixes for different
>> units,
>> such as ``m'' for minutes ``h'' for hours and ``d'' for days.
>>
>> But maybe these don't reflect your blacklistd.conf .. please show that?
>>
>> And don't you need a [remote] section for matching non-local addresses -
>> I gather from the above it's defaulting to the [local] settings for :22,
>> but still '*' should mean to never fail them - or am I confused?
>>
>
> Well, that is something also confused me.
>
> the nfail * is from my blacklist.conf, no mistake. this is blacklist.conf:
> [local]
> ssh stream * * * * *
> ftp stream * * * 2 *
> smtp stream * * * 2 *
>
> The blacklist database is updated by sshd while I enable these options in
> sshd_config:
>
> MaxAuthTries 3
> UseBlacklist yes
>
> But in case I configure the nfail in blacklist.conf as 3 or 2, it could
> never create banned records, it only made records like this:
>
> #when the nfail is 2
> 200.229.186.129/32:22 1/2 2017/11/03 15:46:23
>
> #when the nfail is 3
> 125.66.246.56/32:22 2/3 2017/11/02 10:49:46
>
> #when the nfail is 1
> 187.108.37.126/32:22 0/1 1970/01/01 01:00:00
>
> as you can see. Always nfail-1 but never reached maximum and ban it, the
> blacklistctl dump -b outputted nothing.
> I had checked sshd log and make sure that IP reached maximum 3 times
> failed login attempts. No idea why blacklistd only records nfail-1 times.
>
> I have to change it to * then it was working to have banned list but still
> strange number:
> 115.84.233.228/32:22 3/-1 2017/11/07 02:10:24
>
> I dont know what the "-1" means.
>
> I didnt mention that from begging because I dont want to make this thread
> too complicated. but anyway maybe it help you find the reason.
>
> By the way, you could also see while the nfail is 1, the record's date is
> strange: 1970/01/01 01:00:00. I assume that is bug.
>
>
>> > conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
>> > nfail:*, duration:*
>> > conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:0,
>> name:=,
>> > nfail:*, duration:*
>> > conf_apply: result: target:192.168.11.15:22, proto:6, family:2,
>> uid:*,
>> > name:*, nfail:*, duration:*
>> > Applied address 121.201.96.113:22
>> > Applied address 121.201.96.113:22
>> > process: initial db state for 121.201.96.113:19720: count=3/-1
>> > last=2017/11/07 11:09:34 now=2017/11/07 11:46:26
>> > process: final db state for 121.201.96.113:19720: count=3/-1
>> > last=2017/11/07 11:09:34 now=2017/11/07 11:46:26
>>
>> > received 1 from poll()
>> > processing type=1 fd=5 remote=121.201.96.113:19720 msg=ssh uid=22
>> gid=22
>> > listening socket: 192.168.11.15:22
>> > look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
>> > nfail:*, duration:*
>> > check: target:25, proto:6, family:*, uid:*, name:*, nfail:2,
>> duration:*
>> > check: target:22, proto:6, family:*, uid:*, name:*, nfail:*,
>> duration:*
>> > found: target:22, proto:6, family:*, uid:*, name:*, nfail:*,
>> duration:*
>> > conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
>> > nfail:*, duration:*
>> > conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22,
>> name:=,
>> > nfail:*, duration:*
>> > conf_apply: result: target:192.168.11.15:22, proto:6, family:2,
>> uid:*,
>> > name:*, nfail:*, duration:*
>> > Applied address 121.201.96.113:22
>> > Applied address 121.201.96.113:22
>> > process: initial db state for 121.201.96.113:19720: count=3/-1
>> > last=2017/11/07 11:09:34 now=2017/11/07 11:46:26
>> > process: final db state for 121.201.96.113:19720: count=4/-1
>> > last=2017/11/07 11:46:26 now=2017/11/07 11:46:26
>> >
>> > I can't see the blacklistd-helper was running.
>>
>> Well it won't run unless an entry is to be added or removed from the
>> table; it's not clear from the above that a rule should have been added?
>>
>
> Right on, I clear all record from blacklistd by blacklistd -f then tried
> again. here are outputs
>
> $ sudo blacklistd -dvr -C /usr/libexec/blacklistd-helper
> [local]
> target type proto owner name nfail duration
> 25 6 * * * 2 *
> 22 6 * * * * *
> 21 6 * * * 2 *
> [remote]
> source type proto owner name nfail duration
> Connected to blacklist server
> received 0 from poll()
> ...
> received 1 from poll()
> processing type=4 fd=5 remote=200.60.117.210:37896 msg=mqm uid=0 gid=0
> listening socket: 192.168.11.15:22
> look: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=,
> nfail:*, duration:*
> check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
> check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
> nfail:*, duration:*
> conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:0,
> name:=, nfail:*, duration:*
> conf_apply: result: target:192.168.11.15:22, proto:6, family:2,
> uid:*, name:*, nfail:*, duration:*
> Applied address 200.60.117.210:22
> Applied address 200.60.117.210:22
> process: initial db state for 200.60.117.210:37896: count=0/-1
> last=1970/01/01 01:00:00 now=2017/11/07 22:01:06
> process: final db state for 200.60.117.210:37896: count=0/-1
> last=1970/01/01 01:00:00 now=2017/11/07 22:01:06
> received 1 from poll()
> processing type=1 fd=5 remote=200.60.117.210:37896 msg=ssh uid=22 gid=22
> listening socket: 192.168.11.15:22
> look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
> nfail:*, duration:*
> check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
> check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
> nfail:*, duration:*
> conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22,
> name:=, nfail:*, duration:*
> conf_apply: result: target:192.168.11.15:22, proto:6, family:2,
> uid:*, name:*, nfail:*, duration:*
> Applied address 200.60.117.210:22
> Applied address 200.60.117.210:22
> process: initial db state for 200.60.117.210:37896: count=0/-1
> last=1970/01/01 01:00:00 now=2017/11/07 22:01:06
> process: final db state for 200.60.117.210:37896: count=1/-1
> last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
> received 1 from poll()
> processing type=1 fd=5 remote=200.60.117.210:37896 msg=ssh uid=22 gid=22
> listening socket: 192.168.11.15:22
> look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
> nfail:*, duration:*
> check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
> check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
> nfail:*, duration:*
> conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22,
> name:=, nfail:*, duration:*
> conf_apply: result: target:192.168.11.15:22, proto:6, family:2,
> uid:*, name:*, nfail:*, duration:*
> Applied address 200.60.117.210:22
> Applied address 200.60.117.210:22
> process: initial db state for 200.60.117.210:37896: count=1/-1
> last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
> process: final db state for 200.60.117.210:37896: count=2/-1
> last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
> received 1 from poll()
> processing type=1 fd=5 remote=200.60.117.210:37896 msg=ssh uid=22 gid=22
> listening socket: 192.168.11.15:22
> look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
> nfail:*, duration:*
> check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
> check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
> conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
> nfail:*, duration:*
> conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22,
> name:=, nfail:*, duration:*
> conf_apply: result: target:192.168.11.15:22, proto:6, family:2,
> uid:*, name:*, nfail:*, duration:*
> Applied address 200.60.117.210:22
> Applied address 200.60.117.210:22
> process: initial db state for 200.60.117.210:37896: count=2/-1
> last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
> process: final db state for 200.60.117.210:37896: count=3/-1
> last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
>
> seems the helper script still not running.
>
>
>>
>> > The ipfw was running with following options in rc.conf
>> >
>> > #ipfw
>> > firewall_enable="YES"
>> > firewall_quiet="YES"
>> > firewall_type="open"
>> >
>> > The outputs of
>> > $ sudo ipfw list
>> > were not changed after blacklistd running:
>> >
>> > $ sudo ipfw list
>> > 00100 allow ip from any to any via lo0
>> > 00200 deny ip from any to 127.0.0.0/8
>> > 00300 deny ip from 127.0.0.0/8 to any
>> > 00400 deny ip from any to ::1
>> > 00500 deny ip from ::1 to any
>> > 00600 allow ipv6-icmp from :: to ff02::/16
>> > 00700 allow ipv6-icmp from fe80::/10 to fe80::/10
>> > 00800 allow ipv6-icmp from fe80::/10 to ff02::/16
>> > 00900 allow ipv6-icmp from any to any ip6 icmp6types 1
>> > 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
>> > 65000 allow ip from any to any
>> > 65535 deny ip from any to any
>>
>> Sure, that'll work as well as firewall_type="workstation" for a test.
>>
>> > the output of
>> > $ cat /etc/ipfw-blacklist.rc
>> > ifpw_offset=4000
>>
>> Right. Well perhaps try setting ssh attempts to fail on the first
>> try, just for a test, to see blacklistd-helper actually working.
>>
>> % head -3 blacklistd-helper
>> #!/bin/sh
>> #echo "run $@" 1>&2
>> #set -x
>>
>> Rather than uncommenting 'set -x' you could replace the first
>> commented command temporarily with such as:
>>
>> echo "`date` $0 run $@" >>/var/log/blacklistd-helper.log
>>
>> So you get an actual log of blacklistd's attempts to add rules?
>>
>
> the log outputs:
>
> $ tail blacklistd-helper.log
> Tue Nov 7 17:32:48 CET 2017 /usr/libexec/blacklistd-helper run flush
> blacklistd
> Tue Nov 7 21:14:37 CET 2017 /usr/libexec/blacklistd-helper run flush
> blacklistd
> Tue Nov 7 21:50:52 CET 2017 /usr/libexec/blacklistd-helper run flush
> blacklistd
>
> It looks like automatically flush but not activated by then entries adding
> event.
>
>
>>
>> Cheers, Ian
>>
>
>
>
> --
> with kind regards
>
--
with kind regards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKV%2BxLAkfiQCLXfgZOtQGUXOW8gYN7sjOD5uWezv-N%2BTBjybMQ>