How to setup IPFW working with blacklistd

[Cos Chan]

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:
>
>> On Wed, 15 Nov 2017 11:02:30 -0500, Kurt Lidl wrote:
>>  > On 11/15/17 6:46 AM, Cos Chan wrote:
>>  >
>>  > > blacklistd.log:
>>  > > Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22
>>  > > <http://132.148.128.234/32:22> for -1 seconds
>>  > > Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
>>  > > Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22
>>  > > <http://132.148.128.234/32:22> for -1 seconds
>>  >
>>  > The "-1 seconds" looks fishy to me.
>>  >
>>  > What is the /etc/blacklistd.conf on this machine?
>>
>> Whether or not the first block succeeded, which if it had, should have
>> precluded another one two minutes later .. just on this point:
>>
>> -1 here means "never remove" ie duration='*', like nfail='*' is also set
>> to -1 for 'never block'.  Noticed in ..
>>
>> [ here /usr/head/src/contrib/blacklist/ ]
>> bin/blacklistd.c: update(void)
>> [..]
>>                 if (c.c_duration == -1 || when >= ts.tv_sec)    <<<----
>>                         continue;
>>                 if (dbi.id[0]) {
>>                         run_change("rem", &c, dbi.id, 0);
>>                         sockaddr_snprintf(buf, sizeof(buf), "%a", ss);
>>                         syslog(LOG_INFO, "released %s/%d:%d after %d
>> seconds",
>>                             buf, c.c_lmask, c.c_port, c.c_duration);
>>                 }
>>                 state_del(state, &c);
>>
>> One of the problems with blocklistd-helper is that return codes from it
>> are mostly not checked, in some cases it's run as (void)run_change(..)
>> so it's dependant on the helper script succeeding, and simply ignores
>> any indicated failure - except possibly for an add operation, where it
>> returns -1 if it gets a NULL response (empty string I assume) otherwise
>> it returns 0 after copying the output string to the id (here always OK)
>> .. but it seems nothing cares about the return code eithe rway ..
>>
>> A bit more about making the script more robust - and more informative
>> for debugging, at least re ipfw - is slowly brewing, but I'm running out
>> of spare time at the moment, and will have to quit digging this deep
>> into code I'm unlikely ever to run myself :)
>>
>> [ 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?


>
>
>>
>> cheers, Ian
>>
>
>
>
> --
> with kind regards
>



-- 
with kind regards