How to setup IPFW working with blacklistd

[Cos Chan]

On Sun, Nov 19, 2017 at 3:42 PM, Ian Smith <smithi at nimnet.asn.au> wrote:

> On Sat, 18 Nov 2017 23:18:15 +0100, Cos Chan wrote:
>
>  >     Michael Ross <gmx at ross.cx>
>
> Michael, you're still stuck on this loop, let us know if you want out :)
>
>  > On Thu, Nov 16, 2017 at 10:40 PM, Cos Chan <rosettas at gmail.com> wrote:
>  > > On Thu, Nov 16, 2017 at 3:53 PM, Ian Smith <smithi at nimnet.asn.au>
> wrote:
> [..]
>
>  > >> [ Cos, do you get any different behaviour if you set duration to some
>  > >> value other than '*'?  30d should be near enough forever for testing
> ]
>  > >>
>  > >
>  > > RIght, I can't see same "increased after ipfw blocked" issue while I
>  > > change the * to 30d.
>  > >
>  > > I will check again tomorrow.
>  > >
>  >
>  > 2 days test on 30d configuration, there is no issue of increasing fail
>  > times after IPFW.
>  >
>  > So, only * option has such issue?
>
> Maybe.  To confirm whether '*' = -1 = 'forever' duration has an issue,
> I'd try changing one thing - and only one thing - for another day or so.
>
> first take a full 'blacklistctl dump -ad > file1' for complete state.
> and 'ipfw table port66 list', a copy of the config .. everything.
>
> Update blacklistd.conf to change just that one '30d' to '*'
>
> service blacklistd restart
>
> Make observations :) then afterwards 'blacklistctl dump -ad >file2' etc.
>

I followed the instruction and got bctldumpad for 30d and bctldumpad2 for *

$ cat bctldumpad | grep [3-9]/2
(nothing since all 2/2 or 1/2)

$ cat bctldumpad2 | grep [3-9]/2
153.149.173.211/32:22   OK      3/2     2017/11/20 14:09:45
 171.78.235.174/32:22   OK      4/2     2017/11/20 14:18:25
 115.146.127.81/32:22   OK      3/2     2017/11/20 14:09:32
    60.7.70.205/32:22   OK      3/2     2017/11/20 15:06:30
  60.172.229.43/32:22   OK      3/2     2017/11/20 14:51:15
  103.48.116.47/32:22   OK      3/2     2017/11/20 14:59:50
  122.114.207.2/32:22   OK      3/2     2017/11/20 15:01:41
   91.99.102.90/32:22   OK      3/2     2017/11/20 15:02:37
 36.189.255.161/32:22   OK      3/2     2017/11/20 15:02:06

Please let me know in case you wanna see diff.

I found another thing might be interesting.
seems even I stop the IPFW the 2/2 will not be increased to 3/2 in case the
duration is 30d instead of *.

short summary :
1. while the duration is *, even IPFW blocks the IP the nfail number is
still increased. (we saw from past logs)
2. while the duration is 30d, even IPFW not running the nfail number would
not be increased to more than maximum one.


>
> Perhaps assisting debugging, in the sources I noticed something that
> might benefit some users by a mention in blacklistd(8) under 'Signals'.
>
> If you start blacklistd with the -d switch, as we've seen, it stays in
> foreground and sets debug to 1 (debug++).  So like before, you get lots
> of debug info, but that to stdout and without timestamps.
>
> If instead you start it without -d, blacklistd becomes a daemon and
> creates its pidfile, but then doesn't seem to log much detail - which is
> normally what you'd want.
>
> But then if you signal sigusr1 (kill -USR1 /var/run/blacklistd.pid) it
> increases debug by 1.  sigusr2 decreases debug by 1.  And sighup, like
> any respectable daemon, has blacklistd reread its config - so you should
> not really need to run 'service .. restart' on config changes anyway.
>
> There's code that runs with debug > 1 and some even with debug > 2, but
> that's likely overkill.  But as long as you haven't used -v (to log to
> stderr instead of syslog) if you set debug = 1 (or more) you should get
> that copious amount of debug info you were getting, but timestamped in
> your 'myblacklistd.log' to compare with sshd and blacklistd-helper logs.
>

Yes your updated command "# kill -s USR1 `cat /var/run/blacklistd.pid`" is
running well. I could get detailed logs instead.

Seems the command "#kill -USR1 5028" is also working? the 5028 is
blacklistd pid I got from ps -aux.


>
> Just a thought ..
>
> cheers, Ian
>



-- 
with kind regards