On Sat, 20 Apr 2024 08:48:02 -0000 "William N." <netfilter@xxxxxxxxxx> 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 >
