Re: Question on rate limiting on nftables

Hi Andre,

On Mon, 8 Jun 2026, at 12:30 PM, Andre Rodier 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"
> }
> ~~~

This sets up a single token bucket whose state is controlled by any host that sends packets to port 22, facilitating trivial denial-of-service attacks. Consider the following scenario:

1) one or more third-party hosts hammer port 22, keeping the bucket empty
2) while it is empty, you innocently try to ssh in
3) you are added to @banned_ipv4

>
> 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 ?

Yes, because an individual token bucket ends up being maintained for each ip saddr. Be mindful of matters pertaining to resource consumption, though. You probably don't want to size your sets with the intent of being able to cover all 4.29 billion addresses that exist in the IPv4 namespace. As such, it might be preferable to ban shorter prefixes - such as /24 - rather than individual addresses [*]. To do so would reintroduce the problem of collateral damage (as with your first option) but would limit the blast radius to batches of 256 addresses within each /24.

It might also be useful to reconsider the problem that is ostensibly being solved. If the problem can be characterised as "I endure too much log noise from sshd and I find it annoying" then perhaps configure sshd(8) to additionally bind to some other random port than 22 and expose only that port. If, instead, the problem can be characterised as "I'm worried about being hacked" then be sure not to permit password authentication.

[*] This is made possible in nftables by its support for bitwise arithmetic, e.g. "ip saddr & 255.255.255.0".

--
Kerin Millar