Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: blacklistd is now available for current (comments?)
Le 21/01/2015 03:54, christos%zoulas.com@localhost a écrit :
You can get it from http://www.netbsd.org/~christos/blacklistd.tar.gz
Appended is the README file. I wrote this over the weekend, it seems to
work :-) Please let me know what you think?
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.
Is it useful?
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.
Should I commit
it to the base system? Do you have any suggestions to improve it?
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?
- 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 :) );
- 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 would use CLOCK_MONOTONIC instead of REALTIME for calculation.
syslog(3) will log the wallclock anyway;
- 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...
Cheers,
--
jym@
Home |
Main Index |
Thread Index |
Old Index