From: <imnozi@gmail.com>
To: netfilter-devel@vger.kernel.org
Subject: Re: [Thread split] nftables rule optimization - dropping invalid in ingress?
Date: Sat, 20 Apr 2024 14:32:18 -0400 [thread overview]
Message-ID: <20240420143218.085d31a5@playground> (raw)
In-Reply-To: <20240420084802.6ff973cf@localhost>
On Sat, 20 Apr 2024 08:48:02 -0000
"William N." <netfilter@riseup.net> wrote:
> As per advice by Kerin Millar, this is a continuation of another
> discussion [1] which resulted in a different topic.
>
> On Sat, 20 Apr 2024 03:36:00 +0100 Kerin Millar wrote:
>
> > To begin with, I would recommend that you jettison these rules
> > outright. It is probable that they would otherwise end up being
> > useless. But why? [...]
>
> Actually, I have read about all this in older posts here. I should have
> probably clarified better the forest, not just the trees.
>
> The rules I mention (along with a few others) were inspired by a few
> sources - some using iptables (where INVALID may be different in its
> code definition from nftables and thus need such rules). That said, I
> have actually tested and am aware that e.g. Xmas is an invalid TCP
> packet that will be dropped by conntrack anyway. Similarly, the others
> too.
>
> However, in the setup I am trying to implement, I am attempting to be
> "clever" and optimize things by dropping bad traffic earlier, so I am
> doing it in the ingress hook where, AFAICS, conntrack is not available.
> Why ingress? - Because I am following the general principle that
> attacks should be stopped as soon and as far as possible, rather than
> allowing them go further inside (in this case - next hooks). And even
> though the next hook (prerouting) can drop e.g. Xmas of FINSYN as
> invalid, I assume it would be a waste of CPU cycles to allow further
> processing of such traffic. So, I thought: why not prevent the
> unnecessary load on stateful conntrack? - Hence the whole idea to drop
> early.
>
> OTOH, adding more rules to ingress adds CPU cycles itself.
>
> Which is more optimal - dropping early or not piling up extra rules in
> ingress? Looking for an answer to that, I have done this:
INVALID packets are those that netfilter has no idea what to do with and will eventually drop them after they fit no existing ACCEPT rules. A couple examples of INVALID packets would be (1) a TCP RESET for a non-existent conn (possibly one that was just reset, possibly a DoS attack), and (2) a TCP data packet for a non-existent conn. Neither of these is routable because there is no place to send them. Thus they are dropped in due time. The choice is whether to drop them after they pass through all the rules they will pass through or to drop them as soon as possible after conntrack tags them as INVALID.
With iptables, I found the earliest I could drop bad traffic (large blocksets of addrs I never want access to or from whether or not they are INVALID, and all other INVALID packets) was at the top of PREROUTING in table mangle. I would think nftables is similar.
The most optimal involves the least amount of processing. I would think conntrack is more efficient at tagging INVALID packets than a bunch of rules somewhere. Then it takes only one rule to drop INVALID packets early in PREROUTING. Or two if you jump to a chain that has a DROP rule; said chain would allow you to easily add or remove a log rule.
Neal
>
> As per earlier advise from you in a different context, I checked this:
>
> # zgrep BPFILTER /proc/config.gz
> # CONFIG_BPFILTER is not set
>
> If I am reading this correctly, it means there is no BPF JIT
> optimization. Is this normal? Is BPF still experimental and for that
> reason not available? I don't know, which is why I asked and still hope
> for an answer:
>
> https://marc.info/?l=netfilter&m=171345423924347&w=2
>
> Why am I referring to BPF? - Because I suppose having it available
> would make the difference between the "drop early" (in ingress) and
> "drop as invalid" (in prerouting) cases negligible.
>
> Now, the question comes down to: How big is the actual difference? Is
> it negligible right now (without BPF)? - I really don't know. Hence
> this other thread:
>
> https://marc.info/?l=netfilter&m=171354240711565&w=2
>
> Any info and advice is very welcome, as the whole thing discussed here
> is very unclear to me.
>
> --
>
> [1] https://marc.info/?l=netfilter&m=171358042732609&w=2
>
next parent reply other threads:[~2024-04-20 18:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240420084802.6ff973cf@localhost>
2024-04-20 18:32 ` imnozi [this message]
[not found] ` <20240420183750.332ffbad@localhost>
[not found] ` <rNVqfcHpj4XyJlxISjkKDdyRHbyPqlyF8MOHq07xz1_V3vc99maPQTsAuxgA2PZNbvff2dUfl2s0YdJBI4muw8A7FiMeKu2KvnjK0fG7kYo=@proton.me>
[not found] ` <20240421175000.5fa666d7@localhost>
2024-04-21 20:13 ` [Thread split] nftables rule optimization - dropping invalid in ingress? imnozi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240420143218.085d31a5@playground \
--to=imnozi@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).