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

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jan 21, 11:54am, jeanyves.migeon%free.fr@localhost (Jean-Yves Migeon) wrote:
-- Subject: Re: blacklistd is now available for current  =?UTF-8?Q?=28comment

| I always preferred this way of tweaking fw rulesets instead of relying 
| on "complex" (regex-based) parsers of logfiles written in 
| <insert-a-la-mode-language here>. Tt requires a minor annoyance though: 
| patching the listening daemon.

Yes, but this is done ones...

| 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?

| I do have a few recommandations and remarks, and some depend on its use 
| in base. I know, talk is cheap :)
| - blacklist_r(3) and blacklist_r() in code do not have the same 
| prototype. WIP?

Yes, fixed.

| - ideally blacklistd would run under its own chrooted user; alas this 
| requires some change to the code (open /dev/npf, chroot, and use libnpf 
| onwards. Maybe for v2 :) );

Yes, I've been thinking amongst those lines, but its attack surface
is small. Yes, for v2 I am planning to use libnpf as an option.

| - 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...

| - 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).

| - 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.

christos