From nobody Tue Apr 8 01:55:01 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 4ZWq0G62Dkz5sXth; Tue, 08 Apr 2025 01:55:10 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWq0G5ptJz3XDb; Tue, 08 Apr 2025 01:55:10 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744077310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H4T0C3CGLETbC4JPJMsXzgJ/5dB76TwQBXxdzlqwvRs=; b=mDUoaXab7t+BvI8Yozq70e4hyKjrR/ZHx2tP34uCKNQZbJk4cCY2NEGFuAsbrSLciw0heK 91QheVii1+e5sYOcTMnqYzVv2+LixJ1iyU2ieaIxobUPvSyUBYS51J4u2ssKbltXAHmmOc 0Qa6mfPqlg+GBpoFPtv833TFEvfEXmddiSI8jdwl2xd7oQCotV0aWnh6yllrWSrBGC75Jk xqeI+eT/SgZFKYgKopJV0A1rKeF5UNIg1a6GJ2maInAw8qb64rR4+JNGurQtlzAeMBPq95 UIZI5yYyFcxKsE3VsteCG7utf1U8jdCheaaDU/bwtWGKAoST4/bglwoYYkmckg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744077310; a=rsa-sha256; cv=none; b=HpqCPA2gjmLP38PudGZsdq8bsgG5g3cnC2ZnZYoh+VJyIEI9VC51IyO1+OcXbMI2r8/TkN zyJOvwYV73tGOpEZwnxDplT/SxSXmeQNx4BYKpOhvqXotNTI08VhgjM8RcfkZaK4ATYJSa sityzDuURShQpTtPKOwYFoF+GgBVnP2kGLBz1AfdeaEELFGithuyLpyC6C10X38VcjCjCk EUKinWIF2zCdKYkmrZXncNznxaUKW6MEuYEjaY6/PS2JOhQIh5dwrd+DpVsfPIRGpnnu3N Asd5qDQyNhIqpoNUp+9jXOwdSWdKk5o3L3pZdnrmKlCtD9QZFxkuRYpzOUjPgA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744077310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H4T0C3CGLETbC4JPJMsXzgJ/5dB76TwQBXxdzlqwvRs=; b=u3LObqdviW/taseLRw8WtNip+OJtkVAa4kolq1Makr1LB+AwflXmdPbAgKyDPlWy1VQU9Y Jv/Ixif61I+oTwBX82ahDbpU1E8zOy2unXb+GGijuU1Yt00bF1LDANwIZGELD0N+FKxKh2 o3ASSIn17YtZA+z+kC25mc7oSzVr+NgNZ/9uee/xGLyFdQNPSNTAUYkjegwHLaYITynhkC B554IPh+ilGORXyw9LI9ywL+r90Ce8iS/rS3lNx4zcYfArigUTUtlGOwIIbkpikH6UBvT6 8f9izj5jRFO/8KKzNdcW8qLzZXbbvbFnTiHT8LFM0vceyT6fPkqCCZLnWTwzMg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZWq0C6qm2zNt9; Tue, 08 Apr 2025 01:55:07 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD" 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 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: pfil_default_to_drop Date: Tue, 8 Apr 2025 09:55:01 +0800 In-Reply-To: Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost To: Robert Austen References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 8, 2025, at 6:36 AM, Robert Austen = wrote: >=20 >=20 >=20 > 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 > =20 >=20 > From: Robert Austen > Sent: April 7, 2025 4:21 PM > To: freebsd-current@freebsd.org = > > Subject: pfil_default_to_drop > =20 > 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. >=20 > 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.=20 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=3Dc531c1d1462c45f7ce5de4f991322680= 1f3073bd = . >=20 > 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=20 > 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=20 > hooks are unhooked.=20 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. >=20 > [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.] >=20 > 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=20 > if I could... >=20 > 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. >=20 > But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. >=20 > thanks! >=20 >=20 > Robert >=20 >=20 >=20 >=20 > --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowglensystems.com> wrote:



From: Robert Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@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 <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.


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




<FreeBSD-14.1-RELEASE-a= md64-pfil_default_to_drop.patch.zip>


= --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD--