bl[ao]cklistd, some first impressions...

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Tue, 21 Nov 2023 11:46:12 UTC
I have played around with bl[ao]cklistd on 13.2 and I am not terribly impressed:

A) It would be nice to be able to specify in bl[ao]cklistd.conf
   that violations of a particular rule should get the IP banned
   for any trafic, not just the one they happened to trigger first.

   This is particular necessary/useful for instance when you run a
   "HTTP-sandwich", and spot the problem in the inner layers, but
   want to block access to the exterior port 443 from a process
   which does not hold that socket.  (ie: varnish behind hitch)

B) The OaM commands for pf take obscurity to a new level:

	pfctl -a blacklistd/80 -sr -v

	pfctl -a blacklistd/80 -t port80 -T show

   and that is just for one specific port: repeat manually for all
   of 22, 25, 443 etc.

   Going to a default "totally block IP's" policy would simplify this.

C) Anchor-wildcards do not work in pfctl and the diagnostics are criminal:

	root@test-net:~ # pfctl -a 'blacklistd/*' -t port80 -T show
	pfctl: Unknown error: -1.
	root@test-net:~ # pfctl -t port80 -T show
	pfctl: Unknown error: -1.


D) It would be nice to be able to have bl[ao]cklistd cooperate across
   machines, so that for instance all VM's on the same hardware could
   benefit from each others detections.

E) It should be possible to inject an entry with bl[ao]cklistctl, so
   that simple text-based processing of logfiles can contribute too.

Other than that, once you get it set up right, it seems to get the job done...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.