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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 18, 2023 at 01:07:07PM +0200, U.Mutlu wrote:
[...]
> 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...

I may lack context, but IMO you may simplify your scripts/algorithm:

If a daemon (or fail2ban) identifies an IP to block, it must not have
been in either of the sets (or otherwise the firewall had dropped the
packet already). So they may just unconditionally add to the first set.

Also, you may get away with a single set only:

| table t {
|   set ban {
| 	type ipv4_addr
| 	timeout 2s
|   }
| }

You may add elements like so:

| add element t ban { 1.2.3.4 timeout 5m }

I.e., override the default 2s timeout and set a larger one for
individual elements. This may happen from packet path, as well:

| add rule t input ip saddr @ban update @ban { ip saddr timeout 5m }

Cheers, Phil



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux