From: <imnozi@gmail.com>
To: "Andre Rodier" <andre@rodier.me>
Cc: <netfilter@vger.kernel.org>
Subject: Re: Question on rate limiting on nftables
Date: Mon, 8 Jun 2026 17:54:38 -0400 [thread overview]
Message-ID: <20260608175438.34c41f02@playground> (raw)
In-Reply-To: <DJ3MTZXMKPIT.1A41M4YZMF8UY@rodier.me>
On Mon, 08 Jun 2026 12:30:55 +0100
"Andre Rodier" <andre@rodier.me> wrote:
> Hello,
>
> I am testing nftables SSH connections attempts limit, and I read about "meters"
>
> I would like to know the difference between these two methods of new connections limiting, and to ensure the first one is correct.
>
> The first option:
>
> ~~~
> table inet filter {
> [...]
> meta nfproto ipv4 tcp dport ssh ct state new,untracked \
> limit rate over 10/second \
> counter add @banned_ipv4 { ip saddr . ssh } \
> comment "Ban SSH bots"
> }
> ~~~
>
> And the second option:
>
> ~~~
> table inet filter {
> [...]
> meta nfproto ipv4 tcp dport ssh ct state new,untracked \
> meter ssh4 { ip saddr limit rate over 10/second } \
> add @banned_ipv4 { ip saddr . ssh }
> }
> ~~~
>
> Is there any advantage using the second method ?
>
> Thanks for your insights
>
The first method, as already explained, effectively drops packets when too many arrive too quickly from all sources. The second tracks individual IPs.
In my F/W, attempts from internet to access ports that are *not* open/forwarded are logged as 'badtraffic' and dropped. Attempts, again from internet, to access open/forwarded ports too quickly (N SYNs in M seconds) are logged as 'badtraffic' and dropped. The limiter looks at all open/forwarded ports.
I also have a script that runs periodically; it gathers the IPs from the 'badtraffic' log entries (and IPs from other sources) and adds them to an IP set if they are not already covered there by a /16 or /24 set and not already present in the IP set. Periodically blocking them allows the rate-limited IPs to expire from the rate limiter. They stay blocked until they fall out of the logs.
This and the other measures I've taken have reduced bandit* traffic from well over 100kbit/s to around 3kbit/s on average. They've reduced guests on my forum from over 400 (up to 5000) to less than 15. Alas, there is one drawback to my methods: I don't know how many false positives they trigger; my limits are probably a little too tight. The rate limiter has 2048 entries. At present, the sets contain 9000 blocked nets and 535k blocked IPs. That's about 1/8000 of the internet, so my methods mightn't be too aggressive.
Neal
* - Yes, I call all of those miscreants 'bandits', for that is what they are.
prev parent reply other threads:[~2026-06-08 21:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 11:30 Question on rate limiting on nftables Andre Rodier
2026-06-08 12:45 ` Kerin Millar
2026-06-08 13:14 ` Andre Rodier
2026-06-08 14:32 ` Slavko
2026-06-08 15:01 ` Andre Rodier
2026-06-08 15:57 ` Lars Noodén
2026-06-08 17:05 ` Kerin Millar
2026-06-25 17:20 ` Gordon Fisher
2026-06-08 16:05 ` Reindl Harald
2026-06-08 17:10 ` Kerin Millar
2026-06-26 17:04 ` Gordon Fisher
2026-06-08 16:56 ` Slavko
2026-06-08 17:24 ` Kerin Millar
2026-06-08 15:25 ` Kerin Millar
2026-06-25 16:55 ` Gordon Fisher
2026-06-08 21:54 ` imnozi [this message]
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=20260608175438.34c41f02@playground \
--to=imnozi@gmail.com \
--cc=andre@rodier.me \
--cc=netfilter@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.