Date: Wed, 8 Nov 2017 02:10:30 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Cos Chan <rosettas@gmail.com> 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: <20171108012948.A9710@sola.nimnet.asn.au> In-Reply-To: <CAKV%2BxLDQQcG3bvo1b2nUAu7oOVhdNzDDrPWTVp2qOmkWVV89BQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > 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? > 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? Cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171108012948.A9710>