Re: pfil_default_to_drop
- Reply: Cy Schubert : "Re: pfil_default_to_drop"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 09 Apr 2025 07:48:11 UTC
> On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowglensystems.com> 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 <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. 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). > > thanks! > From: Zhenlei Huang <zlei@FreeBSD.org <mailto:zlei@FreeBSD.org>> > Sent: April 7, 2025 7:55 PM > To: Robert Austen <robert.austen@willowglensystems.com <mailto:robert.austen@willowglensystems.com>> > Cc: freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> <freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>>; freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org> <freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org>>; Kristof Provost <kp@FreeBSD.org <mailto:kp@FreeBSD.org>> > Subject: Re: pfil_default_to_drop > > You don't often get email from zlei@freebsd.org <mailto:zlei@freebsd.org>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowglensystems.com <mailto:robert.austen@willowglensystems.com>> wrote: >> >> >> >> From: Robert Austen <robert.austen@willowglensystems.com <mailto:robert.austen@willowglensystems.com>> >> Sent: April 7, 2025 4:33 PM >> To: freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> <freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>>; freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org> <freebsd-net@freebsd.org <mailto: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 <mailto:freebsd-current@freebsd.org> <freebsd-current@freebsd.org <mailto: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 <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 >> >> >> >> >> <FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip>