Re: [RFC] inetd(8) changes proposal
On Thu, Jun 01, 2023 at 09:08:52AM +0200, tlaro...@polynum.com wrote: > > But for now, it will be far simpler to only modify the NetBSD source > without trying to merge something external. > It isn't external - the mods were made to the NetBSD source code. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: bl*cklist configuration, ssh only
On Thu, Jun 01, 2023 at 05:05:16PM +0100, Patrick Welche wrote: > > What puzzles me is: > > # blocklistctl dump -a | wc > 53 2182497 > > BUT: > > # npfctl rule blocklistd list | wc >3 45 254 > > Only 3 hosts apparently being blocked by npf vs 53. blocklistctl dumps the policy database. npf doesn't implement that policy, but only specfic blocking rules. blocklistd adds npf rules when the policy is violated (e.g. the 3rd login failure) and removes rules when a timeout is reached. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: bl*cklist configuration, ssh only
On Tue, May 30, 2023 at 03:54:52PM -, Michael van Elst wrote:
> ignat...@cs.uni-bonn.de writes:
>
> >Hello,
>
> >is there a minimal example how to configure bl*cklistd and npf to
> >block attacks on sshd?
>
> /etc/bl*cklistd.conf:
> # Bl*cklist rule
> # adr/mask:port typeproto owner namenfail disable
> [local]
> ssh stream tcp * * 5 3h
> ssh stream tcp6* * 5 3h
>
> /etc/npf.conf:
> $primary_if = "wm0"
> group "external" on $primary_if {
> ruleset "bl*cklistd"
> }
>
> # bl*cklistctl dump -a | wc
> 13 53 609
>
>
What puzzles me is:
# blocklistctl dump -a | wc
53 2182497
BUT:
# npfctl rule blocklistd list | wc
3 45 254
Only 3 hosts apparently being blocked by npf vs 53.
Cheers,
Patrick
mtree(8) vs mtree(5)
We have mtree(8) man page for our mtree that documents the format of the mtree spec. We also have an mtree(5) page that documents the format of the mtree spec, but that pages comes from libarchive. This is kinda confusing. What is the relationship between the two? (libarchive borrowed bsd code? are they kept in sync?) Can we drop the format description from mtree(8) and rely on mtree(5) from libarchive? Should we drop the format description from mtree(8), move it to *our own* mtree(5) and don't install mtree(5) from libarchive? (We can document any differences in our mtree(5) b/c we know/control both our own implementation and also which version of libarchive we ship). -uwe
Re: [RFC] inetd(8) changes proposal
Le Thu, Jun 01, 2023 at 12:50:30PM +0930, Brett Lymn a écrit : > On Wed, May 31, 2023 at 12:43:40PM +0200, tlaro...@polynum.com wrote: > > > > And I think you're right: the info will go in a 0400 file in /tmp, and > > will be a way to obtain various running infos---but for now, just the > > running config (it could perhaps be extended, but not now, to add > > stats, what is masked by a secmodel etc.) > > > > There was a GSoC project last year that was looking to extend inetd. > Unfortunately, it is incomplete but one of the things that was done was > to write a inetdctl that could, among other things, dump the running > configuration. You may be able to use some of that code. Thank you for the info. But for now, it will be far simpler to only modify the NetBSD source without trying to merge something external. In fact, what I'm going to do is not very difficult. And, from an engineering point of view, the problems now present are the consequence of putting a new syntax without realizing that it totally changes a fundamental implicit assumption: every directive in the conf file (legacy version) was totally distinct from the others, so failing to parse a directive was only impacting _this_ service and could not impact others. So it was safe and indeed logical to continue, precisely as to not impact other services because one blunder for another service. So, since I have now a quite clear vision of what I have to do and want to obtain, it would be unwise to try to master or to incorporate a code made with another vision. It will simply harden my task and risk introducing by the window bugs I want to put out by the door. Let's put the code right again. A side effect will be that it will be easier to extend. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
