How to setup IPFW working with blacklistd

[Ian Smith]

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.

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.  

Just a thought ..

cheers, Ian