From: "William N." <netfilter@riseup.net>
To: netfilter@vger.kernel.org
Subject: [Thread split] nftables rule optimization - dropping invalid in ingress?
Date: Sat, 20 Apr 2024 08:48:02 -0000 [thread overview]
Message-ID: <20240420084802.6ff973cf@localhost> (raw)
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:
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 reply other threads:[~2024-04-20 8:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 8:48 William N. [this message]
2024-04-20 18:32 ` [Thread split] nftables rule optimization - dropping invalid in ingress? imnozi
2024-04-20 18:37 ` William N.
2024-04-20 19:16 ` Kerin Millar
2024-04-21 17:47 ` William N.
2024-04-27 19:23 ` William N.
2024-04-21 3:45 ` Eric
2024-04-21 5:47 ` Slavko
2024-04-21 17:50 ` William N.
2024-04-21 20:13 ` 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=20240420084802.6ff973cf@localhost \
--to=netfilter@riseup.net \
--cc=netfilter@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.