From owner-freebsd-questions@freebsd.org Tue Nov 7 15:10:43 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F77DE5B2AE for ; Tue, 7 Nov 2017 15:10:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 381116D7CB; Tue, 7 Nov 2017 15:10:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id vA7FAUVm067505; Wed, 8 Nov 2017 02:10:30 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 8 Nov 2017 02:10:30 +1100 (EST) From: Ian Smith To: Cos Chan cc: freebsd-questions , Michael Ross , Kurt Lidl Subject: Re: How to setup IPFW working with blacklistd In-Reply-To: Message-ID: <20171108012948.A9710@sola.nimnet.asn.au> References: <20171106235944.U9710@sola.nimnet.asn.au> <20171107033226.M9710@sola.nimnet.asn.au> <20171107162914.G9710@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:10:43 -0000 On Tue, 7 Nov 2017 12:09:31 +0100, Cos Chan wrote: > On Tue, Nov 7, 2017 at 7:17 AM, Ian Smith wrote: > > > On Mon, 6 Nov 2017 22:43:02 +0100, Cos Chan wrote: > > > > > On Mon, Nov 6, 2017 at 5:50 PM, Ian Smith wrote: > > > > > > > On Mon, 6 Nov 2017 16:41:41 +0100, Cos Chan wrote: > > > > > On Mon, Nov 6, 2017 at 3:09 PM, Ian Smith > > wrote: > > > > [ time to cut mightily .. also cc'ing blacklistd maintainer Kurt Lidl > > 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 ----- ... 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