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.
