Re: Question on rate limiting on nftables

On Mon, 2026-06-08 at 13:45 +0100, Kerin Millar wrote:
> Hi Andre,
>=20
> On Mon, 8 Jun 2026, at 12:30 PM, Andre Rodier wrote:
> > Hello,
> >=20
> > I am testing nftables SSH connections attempts limit, and I read
> > about "meters"
> >=20
> > I would like to know the difference between these two methods of
> > new=20
> > connections limiting, and to ensure the first one is correct.
> >=20
> > The first option:
> >=20
> > ~~~
> > table inet filter {
> > =C2=A0 [...]
> > =C2=A0 meta nfproto ipv4 tcp dport ssh ct state new,untracked \
> > =C2=A0 limit rate over 10/second \
> > =C2=A0 counter add @banned_ipv4 { ip saddr . ssh } \
> > =C2=A0 comment "Ban SSH bots"
> > }
> > ~~~
>=20
> 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:
>=20
> 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
>=20
> >=20
> > And the second option:
> >=20
> > ~~~
> > table inet filter {
> > =C2=A0 [...]
> > =C2=A0 meta nfproto ipv4 tcp dport ssh ct state new,untracked \
> > =C2=A0 meter ssh4 { ip saddr limit rate over 10/second } \
> > =C2=A0 add @banned_ipv4 { ip saddr . ssh }
> > }
> > ~~~
> >=20
> > Is there any advantage using the second method ?
>=20
> 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.
Thank you, this is a very useful and detailed answer.

>=20
> 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.
I used SSH for my example, but I use a port knocking sequence.

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



> --
> Kerin Millar

--=20
=F0=9F=8C=90 https://rodier.me/