Re: [nftables/nft] nft equivalent of "ipset test"

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Oct 18, 2023 at 01:07:07PM +0200, U.Mutlu wrote:
> Pablo Neira Ayuso wrote on 10/18/23 12:00:
> > On Wed, Oct 18, 2023 at 11:54:30AM +0200, U.Mutlu wrote:
[...]
> > > I just don't understand why the author cannot simply add a real 'test'
> > > function to the nft tool...
> > 
> > I just don't understand your usecase :-), why do you need this atomic
> > check on two different sets?
> > 
> > Could you explain your ruleset in more detail?
> 
> It's maybe complicated: I've a restrictive firewall where
> the default is to block all ports for traffic from INPUT,
> except those explicitly allowed.

INPUT is late if you know what ports you want to allow, use
netdev/ingress instead.

> Then, at the end of the firewall rules I can _auto-add_ all
> the unhandled IPs to such a set for blocking. The blocking
> happens at top by testing whether the IP is in that set.

This should be easy to handle with a dynamic set, which allows for
packet path to add elements to set.

> But another feature of this solution is that not only
> the firewall can (auto-) add IPs to the set for blocking,
> but also the external handlers after ACCEPT can do it,
> ie. say a mailserver. It too has to be able to add an IP
> to the same set for  blocking. The blockign itself happens
> centrally in the firewall script at the next attempt of the attacker.
> 
> Lately I've extended this to make it a 2-stage: if blocked IP
> continues sending more than x packets while in timeout of y minutes,
> then add this attacker to the second set that has a much higher timeout of z
> minutes.
>
> One additional practical benefit of this approach is that
> now one sees the hardcore attackers grouped (they are those in set2).
> 
> The correct managing of these two sets requires the said
> atomicity by testing of BOTH sets before adding the IP to the first set...
>
> If you have got a better solution for this use-case,
> so let me/us know please. As said I'm new even to ipset
> but which I find very effective & useful in practice.

You should look at nftables concatenations, you do not have to split
this information accross two sets in nftables. For adding entries from
packet path, have a look at dynamic sets.

Two sets also means two lookups from packet path.

> If you have got a better solution for this use-case,
> so let me/us know please. As said I'm new even to ipset
> but which I find very effective & useful in practice.
> As said I'm still continuing using iptables with ipset,
> just evaluating whether it would make sense to switch to nftables/nft,
> though the learning-curve seems not that small, IMO.

You pick your poison. I keep listening to this argument, I think
things got a lot better. There is still room to improve documentation,
that I can take. I don't think it makes sense to start a firewall with
iptables/ipset in 2023.