From: Phil Sutter <phil@nwl.cc>
To: "U.Mutlu" <um@mutluit.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
imnozi@gmail.com, netfilter-devel@vger.kernel.org,
netfilter@vger.kernel.org
Subject: Re: [nftables/nft] nft equivalent of "ipset test"
Date: Wed, 18 Oct 2023 16:37:51 +0200 [thread overview]
Message-ID: <ZS/tv6BVsXwFN2iZ@orbyte.nwl.cc> (raw)
In-Reply-To: <652FBC5B.5000006@mutluit.com>
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
next prev parent reply other threads:[~2023-10-18 14:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 17:11 [nftables/nft] nft equivalent of "ipset test" U.Mutlu
2023-10-17 21:35 ` Florian Westphal
2023-10-17 21:55 ` U.Mutlu
2023-10-17 22:05 ` Florian Westphal
2023-10-17 22:36 ` U.Mutlu
2023-10-18 9:23 ` Pablo Neira Ayuso
[not found] ` <20231017200057.57cfce21@playground>
2023-10-18 9:36 ` Pablo Neira Ayuso
2023-10-18 9:54 ` U.Mutlu
2023-10-18 10:00 ` Pablo Neira Ayuso
2023-10-18 11:07 ` U.Mutlu
2023-10-18 11:49 ` Pablo Neira Ayuso
2023-10-18 13:03 ` U.Mutlu
2023-10-18 14:37 ` Phil Sutter [this message]
2023-10-18 11:54 ` Kerin Millar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZS/tv6BVsXwFN2iZ@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=imnozi@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=um@mutluit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).