Re: [Thread split] nftables rule optimization - dropping invalid in ingress?

Re: [Thread split] nftables rule optimization - dropping invalid in ingress?

[imnozi]

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
> 

Re: [Thread split] nftables rule optimization - dropping invalid in ingress?

[imnozi]

On Sun, 21 Apr 2024 17:50:00 -0000
"William N." <netfilter@riseup.net> wrote:

> On Sun, 21 Apr 2024 03:45:31 +0000 Eric wrote:
> 
> > I'd be very interested in seeing some statistics on how many actual
> > invalid packets you see on a live link.  Stick some counters in there
> > and collect dropped versus passed packets...  
> 
> This particular system is a desktop one (rebooted often), so that kind
> of stats won't make any sense.
> 
> > My naive guess would be there are only tiny percentage of rejected
> > packets.  
> 
> Without a particular attack - quite possible. However, it is always
> good to learn what is better/worse/futile.
> 

[Again, this is iptables; your mileage with nftables may vary.]

From my firewall that's been up 30 days; I think these are reasonable numbers. It shows the total packets that passed PREROUTING, the packets from internet dropped due to my blocklists (which probably includes at least some INVALID packets), and the remaining INVALID packets from internet and internal sources. These two are the only DROPs in PREROUTING. Ballpark, about 0.5% of the packets are INVALID. Small, but not necessarily 'tiny'.
-----
*mangle
:PREROUTING ACCEPT [728638:3046835361]
[43686:2232175] -A PREROUTING -i eth3 \
    -m set --match-set blockSetHost src -j blDrop
[37712:1840302] -A PREROUTING \
    -m state --state INVALID -j invdrop
-----

Note that dropping them at the top of PREROUTING prevents them from passing through the rest of the rules in PREROUTING (and mangle), and rules in nat, and any rules in filter they might hit before finally being DROPped.

N