From nobody Wed Apr 9 14:39:06 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXlvM06Hkz5rt9X; Wed, 09 Apr 2025 14:39:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXlvL3J9wz3LM7; Wed, 09 Apr 2025 14:39:10 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id 2VhiuklXK5Mqy2Wa5us5lf; Wed, 09 Apr 2025 14:39:09 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2Wa3uqVlol5eG2Wa4uhI6L; Wed, 09 Apr 2025 14:39:09 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=EO6l0EZC c=1 sm=1 tr=0 ts=67f6868d a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=_EeEMxcBAAAA:8 a=EkcXrb_YAAAA:8 a=HIpOd3htAAAA:8 a=YxBL1-UpAAAA:8 a=K8lFCU26Szz-7fEI1asA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=kmlo3kNSEkcePd_NiW6t:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 468B4C24; Wed, 09 Apr 2025 07:39:07 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (Postfix) with ESMTP id 1E7831A1; Wed, 09 Apr 2025 07:39:07 -0700 (PDT) Date: Wed, 9 Apr 2025 07:39:06 -0700 From: Cy Schubert To: Zhenlei Huang Cc: Robert Austen , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Message-ID: <20250409073906.43e4282e@slippy> In-Reply-To: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Organization: KOMQUATS X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfAeSq7tWLzZDNBPYzHzF+ULcPpAwc0DFFGXHGMjKg6oda+iV2O77EgacdS4CIEyb7f6Hmq7eSN7Yop5RLN1RQlne6edbUeNnrLsDpexYZjO3Kd3yTmph 5q2tHHYTAww1V+om7uW8ckLxhqCQiSBtoJ+IqcSpUHZo6F5QBIY1Stkb3E68SLV//0TKYlsHNyZT5mGzu8bjza94h1AWY9IteeYUsAMTvPkxKPYCPC+u/ShI aEmm1uxmvz3JuMEI0u0nPJCX+JDregJbnMkf16nmJFaB1OoRyAq5uAQ7d/zLQmRfzEpb9BSiAkVjGTXV2MTOtC/y+mZ7nqiGABatahRUFedN1YnoNUQVxlH9 tB//G1PGv9CifLXhA8OeFL2zRm/Dxg== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXlvL3J9wz3LM7 X-Spamd-Bar: ---- On Wed, 9 Apr 2025 15:48:11 +0800 Zhenlei Huang wrote: > > On Apr 9, 2025, at 1:01 AM, Robert Austen wrote: > > > > I respectfully disagree. > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call to enable itself, ie. to apply any hooks. > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults to PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP. > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTART ) or netlink command to enable it. > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, the pfil layer in the kernel has no idea what the filter will be, > > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and likewise the equivalents from the other filters). > > As for ipfw(4), by default it enables filtering on load, unless you disable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`. > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet.ip.fw.default_to_accept` controls the default behavior to drop or accept. > See also https://cgit.freebsd.org/src/commit/?id=5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd . > > > > > as I said, this is because there's no mechanism within PFIL to drop by default, which is why I proposed (and am using on my system) the PFIL_DEFAULT_TO_DROP, > > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effect at all, > > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP can ever provide. I don't know whether it should default drop or not. In the case of ipfilter, default drop will drop with or without a log message depending whether IPFILTER_LOG is defined in the kernel config or in the module's Makefile -- both are default. There's something to be said about default block in that there is absolutely no chance any packets will get through without a rule permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled and loaded before any interfaces are brought up so the point is mostly moot. However in unattended situations there is a better chance you could be able to remotely log in to fix any brokenness whereas with a default block you'd have to travel, possibly thousands of kilometres, to fix any problem. Both scenarios should be considered before making the decision whether to default block or default open. Then again, a badly conceived firewall rule, regardless of the default block setting, can make for a very bad day. IIRC -- it's been a couple of decades since I used IPFW -- IPFW is default block while IPFILTER is default open (unless otherwise configured). Considering that firewall rules are loaded before interfaces are brought up -- just run rcorder(8) to see the startup order for yourself -- this argument is moot. > > It appears ipf(4) unconditionally enable filtering on load, and does not have any tunables to control that. CC @Cy who is more familiar with ipf(4). This is not entirely correct. If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. Otherwise by default it will not block by default. This can be adjusted at runtime in two ways. First through the sysctl net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. The value is not intuitive. It's a hex value representing internal flags. If the hex value contains 0x2, ipfilter operates in default pass mode. If the hex value contains 0x1, it operates in default block mode. It will tell you at boot which mode is default: stinky# dmesg | grep IP\ Filter IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled stinky# Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T default_pass to adjust the flag is preferred. Setting the default_block or ipf_pass is not entirely intuitive. > > > > > thanks! > > From: Zhenlei Huang > > > Sent: April 7, 2025 7:55 PM > > To: Robert Austen > > > Cc: freebsd-current@freebsd.org >; freebsd-net@freebsd.org >; Kristof Provost > > > Subject: Re: pfil_default_to_drop > > > > You don't often get email from zlei@freebsd.org . Learn why this is important > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: > >> > >> > >> > >> From: Robert Austen > > >> Sent: April 7, 2025 4:33 PM > >> To: freebsd-current@freebsd.org >; freebsd-net@freebsd.org > > >> Subject: Fw: pfil_default_to_drop > >> > >> > >> From: Robert Austen > >> Sent: April 7, 2025 4:21 PM > >> To: freebsd-current@freebsd.org > > >> Subject: pfil_default_to_drop > >> > >> Hello, > >> I've been playing with FreeBSD and PF to build myself a new firewall, as Open/FreeBSD + PF seems to be a common starting point. > >> > >> I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP and the like, with the observations that it's hard > >> to ensure that packets all default to drop if the rule file(s) for whatever reason fail to load. > > > > Hi Robert, > > > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.ko ( via the loader(8), /boot/loader.conf ) ? > > > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.ko. > > See also https://cgit.freebsd.org/src/commit/?id=c531c1d1462c45f7ce5de4f9913226801f3073bd . > > > >> > >> After looking thru the online documentation, forums and scripts, I came to the conclusion that it's not a PF problem or IPFW etc > >> or really a problem with any of the filters or scripts, the problem is at the level of PFIL, the kernel packet filtering code: If no > >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything thru to its destination. So my thought > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_DEFAULT_TO_DROP) that drops all the > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded chosen filter (PF or whatever) at any given time the > >> hooks are unhooked. > > > > If no firewalls loaded, then the system should behave as is. I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > >> > >> [No one filters on local loopback nor the link layer, so I've left those hooks untouched. I suppose one could add them, > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt there's much demand for it.] > >> > >> Normally I'm an embedded linux kernel basher. > >> I'm not entirely sure where to send this patch. Most of the threads asking the above PF questions are closed to changes, > >> so that doesn't seem a good place. Sir Dice seems to be a common answerer of questions; I would have sent it to him/her > >> if I could... > >> > >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch"... > >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > >> but I suspect the kernel code in the networking core doesn't change much from platform to platform, or version to version. > >> > >> But it works, it's pretty simple, pretty small and so just in case it might be useful, I'm passing it along. > >> > >> thanks! > >> > >> > >> Robert > >> > >> > >> > >> > >> > > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0