On Jan 21, 11:54am, [email protected] (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
