Brook Milligan <[email protected]> writes: >> On Dec 30, 2025, at 09:45, Greg Troxel <[email protected]> wrote: >> >> I am looking at the NetBSD 9 man pages and example, reproduced below > > I’m confused; where did you find those man pages? I’m seeing no such > information in the cvs tree > (https://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/blocklist/bin/), the > published man pages, or anywhere else. Hence my question.
I typed 'man blacklistd' and then 'man blacklistd.conf' on a NetBSD 9 system. On NetBSD 10 is blocklist and seems a little more detailed. Same on NetBSD 11. >> [remote] >> 0.0.0.0/0 stream tcp * =/24 = = >> #[0::0]/0 stream tcp * =/64 = = This is in /usr/share/examples/blacklistd/blacklistd.conf on 9 but the newer examples have dropped the v6 example and are generally more confusing. > This clears things up a lot. Unless I missed something, perhaps this should > be added to the cvs tree. I think it's just a question of clarifying the examples and adding back a :: => 64 line. >> With 9 (blacklistd), not having a remote entry for v6 leads to a /128 >> being blocked. (In my experience this is super rare.) > > OK, so there may be no need for an extra ipv6 block, I suppose. Depends on if your attackers are like my attackers. Blocking a 64 on v6 bad behavior makes sense to me; it's like blocking a v4 /24, more or less. >> I can see why you want to block a /48, but would be interested if you >> are willing to share the details of the kind of bad behavior you >> experience, and if there is a pattern of blocking /64 and then later >> having a failure form a later /64 within the same /48. > > I have no problems with ipv6 addresses, but wanted to block them as I > do ipv4. I figured the same approach (blocking subnets) would be > prudent, but perhaps that is not necessary in practice. I think it is prudent. I just meant that after you experience it for a while, I am curious what you see. I see /48 as a prefix assigned to a site/etc. and /64 to an individual "link" (e.g. ethernet).
