Re: blacklistd is now available for current (comments?)

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 21/01/2015 14:24, christos%zoulas.com@localhost a écrit :
> | I do think it is. TBH there are tons of services out there that fail 
> at
> | implementing proper blacklisting (with expiration) for sockets. And 
> PAM
> | does not really fit the bill.
>
> I did not find any that does this directly (not via parsing logs), have 
> you?

Nope. The closest thing I can think of is modsecurity for Apache, but it 
does not set fw rules. It blocks at application layer. Spam filters do 
something like this too, but it also stays at application layer.

Some do that directly through the firewall using rate limiting 
(sometimes with complex attributes evaluation), but IMHO it is a fragile 
approach. Counting the number of new connections over a period of time 
does not work well; you can maybe rate limit SSH to 1 attempt per 
second, less so for HTTP... And that does not really eradicate the 
noise.

> | - why have blacklist() and blacklist_r()? Make blacklist() use the
> | cookie and drop blacklist_r(). Makes the API simpler too;
> | - in case we get /etc/rc.d/backlistd, perhaps it should be integrated
> | with /etc/rc.d/npf so a restart from npf reloads blacklist 
> configuration
> | also?
>
> I modelled it after syslog...

Okay then.

> | - I would use CLOCK_MONOTONIC instead of REALTIME for calculation.
> | syslog(3) will log the wallclock anyway;
>
> Yes, that's a good idea. I like CLOCK_REALTIME for debug though :-)
> Problem is that time is recorded in the db file, and you can't mix
> debug and non-debug entries then (I don't want to add a flag to say
> what it is).

That makes sense

> | - open question: is there a chance that blacklistd can get confused 
> when
> | blacklist set is edited by hand through npfctl(8)? I am thinking 
> along
> | the lines of rem-id collision where someone removes/adds rules to
> | blacklist through npfctl and forget to stop blacklistd, which will 
> try
> | to remove the old rules later...
>
> I think that you always get new ids for the rules (ids are not reused).
> If you remove a rule manually rule removal will fail. If you add rules
> manually they won't be touched by blacklistd. As for syncing with npf,
> I might add in the future a TTL for dynamic rules in NPF so there is no
> state kept in blacklistd.

Great.

Anyway, even if it does not make get into base, I would gladly use it if 
it is in pkgsrc :)

Cheers,

--
Jean-Yves Migeon