How to setup IPFW working with blacklistd
smithi at nimnet.asn.au
Sun Nov 19 14:42:42 UTC 2017
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 ..
More information about the freebsd-questions