Question on rate limiting on nftables

Question on rate limiting on nftables

[Andre Rodier]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

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

-- 
🌐 https//rodier.me/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Question on rate limiting on nftables

[Kerin Millar]

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

Re: Question on rate limiting on nftables

[Andre Rodier]

On Mon, 2026-06-08 at 13:45 +0100, Kerin Millar wrote:
> 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.
Thank you, this is a very useful and detailed answer.

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

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



> --
> Kerin Millar

-- 
🌐 https://rodier.me/

Re: Question on rate limiting on nftables

[Slavko]

Dňa 8. júna 2026 12:45:55 UTC používateľ Kerin Millar <kfm@plushkava.net> napísal:

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

Not worth of change ports, soon or latter it will be found
and abused as default port.

Fail2ban or so, can block addresses selectively. BTW, here after
long time (1-2 years) of banning the counts drops from hundreds/thousands
addresses daily to tens daily. Currently, i have banned 30 addresses
with bantime up to 90 days, from that the ~20 is today "spike".

regards


-- 
Slavko
https://www.slavino.sk/

Re: Question on rate limiting on nftables

[Andre Rodier]

On Mon, 2026-06-08 at 14:32 +0000, Slavko wrote:
> Dňa 8. júna 2026 12:45:55 UTC používateľ Kerin Millar
> <kfm@plushkava.net> napísal:
> 
> > 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.
> 
> Not worth of change ports, soon or latter it will be found
> and abused as default port.

There is a big advantage on changing the port number, though. It is
reducing the noise considerably. Also, a connection attempts on a
different port should immediately raise attention, as it is involving
more than a basic SSH scan bot.

> Fail2ban or so, can block addresses selectively. BTW, here after
> long time (1-2 years) of banning the counts drops from
> hundreds/thousands
> addresses daily to tens daily. Currently, i have banned 30 addresses
> with bantime up to 90 days, from that the ~20 is today "spike".
> 
> regards

-- 
🌐 https://rodier.me/

Re: Question on rate limiting on nftables

[Lars Noodén]

On 6/8/26 18:01, Andre Rodier wrote:
> Also, a connection attempts on a
> different port should immediately raise attention, as it is involving
> more than a basic SSH scan bot.

Shifting ports might quiet the logs somewhat, but your SSH port will be 
found both quickly and easily by bots.  That has been the case for a 
long time:

  https://bsdly.blogspot.com/2013/02/theres-no-protection-in-high-ports.html

It is difficult to fit nftables into mitigations for those probes 
because modern scans usually come from a wide spread of addresses and 
networks.  In the case of SSH, using SSH keys (or even SSH certificates) 
and turning off password authentication clears out a lot of the bots, 
but that has been mentioned already.

/Lars

Re: Question on rate limiting on nftables

[Kerin Millar]

On Mon, 8 Jun 2026, at 4:57 PM, Lars Noodén wrote:
> On 6/8/26 18:01, Andre Rodier wrote:
>> Also, a connection attempts on a
>> different port should immediately raise attention, as it is involving
>> more than a basic SSH scan bot.
>
> Shifting ports might quiet the logs somewhat, but your SSH port will be 
> found both quickly and easily by bots.  That has been the case for a 
> long time:
>
>   https://bsdly.blogspot.com/2013/02/theres-no-protection-in-high-ports.html

This blog post argues against security-by-obscurity. It has nothing whatsoever do with the substance of my initial post in this thread, in which I wrote:

«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.»

Nothing more, nothing less. I did not write, "I want to make it impossible for any bot anywhere to discover that I am running an sshd service on a given port forever more". Nor did I write, "I'm worried about being hacked and I think that switching to a different port will make that eventuality less likely".

Indeed, Mr Hansteen's post concedes precisely that:

«The immediate effect in almost all cases was a much quieter authentication log.»

The implied question can thus be framed as: do I think that increasing the signal-to-noise ratio of my logs is worth a port change? In my case, the answer is an unequivocal yes.

--
Kerin Millar

Re: Question on rate limiting on nftables

[Reindl Harald]

Am 08.06.26 um 17:01 schrieb Andre Rodier:
> On Mon, 2026-06-08 at 14:32 +0000, Slavko wrote:
>> Dňa 8. júna 2026 12:45:55 UTC používateľ Kerin Millar
>> <kfm@plushkava.net> napísal:
>>
>>> 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.
>>
>> Not worth of change ports, soon or latter it will be found
>> and abused as default port.
> 
> There is a big advantage on changing the port number, though. It is
> reducing the noise considerably. Also, a connection attempts on a
> different port should immediately raise attention, as it is involving
> more than a basic SSH scan bot

and in fact you can have a few ports before as trigger to put the IP on 
a drop-list for a few minutes which isn't possible when you host ftp servers

Re: Question on rate limiting on nftables

[Kerin Millar]

On Mon, 8 Jun 2026, at 5:05 PM, Reindl Harald wrote:
> Am 08.06.26 um 17:01 schrieb Andre Rodier:
>> On Mon, 2026-06-08 at 14:32 +0000, Slavko wrote:
>>> Dňa 8. júna 2026 12:45:55 UTC používateľ Kerin Millar
>>> <kfm@plushkava.net> napísal:
>>>
>>>> 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.
>>>
>>> Not worth of change ports, soon or latter it will be found
>>> and abused as default port.
>> 
>> There is a big advantage on changing the port number, though. It is
>> reducing the noise considerably. Also, a connection attempts on a
>> different port should immediately raise attention, as it is involving
>> more than a basic SSH scan bot
>
> and in fact you can have a few ports before as trigger to put the IP on 
> a drop-list for a few minutes which isn't possible when you host ftp servers

Indeed. I have implemented a fairly aggressive anti-scanning methodology in nftables on that basis, with only a handful of services exempted (those that absolutely must remain open to the Internet at large, come what may).

-- 
Kerin Millar

Re: Question on rate limiting on nftables

[Slavko]

Dňa 8. júna 2026 15:01:37 UTC používateľ Andre Rodier <andre@rodier.me> napísal:

>There is a big advantage on changing the port number, though. It is
>reducing the noise considerably. Also, a connection attempts on a
>different port should immediately raise attention, as it is involving
>more than a basic SSH scan bot.

I used high port for ~10 years. Yes for first year or two
the noise dropped significantly. That is from server where
SSH access have only i and password auth is disabled anyway,
thus i didn't watch it then in detail for multiple years as
it was just noise. About 5 years ago i did some closer
inspection and i collected some stats, and i found, that
in average there was attempts from ~1k unique IPs daily,
with spikes over 2k daily, i decided what i stated -- not
worth to setup non-default port on clients.

Thus again, changing port is only short term solution. My
scanners catching stats (on some sort of honeypot) shows
~8k unique ports scanned in last 90 days, and that are only
most obvious scans blocked after first acces, without well
known scanners (shodan and familly), which are catched by
other way before...

Try to guess how long it will take novadays to discover,
that your SSH listens on different port and how long it
will take to appear/share/sold that info on some dark
forums?

regards


-- 
Slavko
https://www.slavino.sk/

Re: Question on rate limiting on nftables

[Kerin Millar]

On Mon, 8 Jun 2026, at 5:56 PM, Slavko wrote:
> Dňa 8. júna 2026 15:01:37 UTC používateľ Andre Rodier <andre@rodier.me> napísal:
>
>>There is a big advantage on changing the port number, though. It is
>>reducing the noise considerably. Also, a connection attempts on a
>>different port should immediately raise attention, as it is involving
>>more than a basic SSH scan bot.
>
> I used high port for ~10 years. Yes for first year or two
> the noise dropped significantly. That is from server where
> SSH access have only i and password auth is disabled anyway,
> thus i didn't watch it then in detail for multiple years as
> it was just noise. About 5 years ago i did some closer
> inspection and i collected some stats, and i found, that
> in average there was attempts from ~1k unique IPs daily,
> with spikes over 2k daily, i decided what i stated -- not
> worth to setup non-default port on clients.
>
> Thus again, changing port is only short term solution. My
> scanners catching stats (on some sort of honeypot) shows
> ~8k unique ports scanned in last 90 days, and that are only
> most obvious scans blocked after first acces, without well
> known scanners (shodan and familly), which are catched by
> other way before...
>
> Try to guess how long it will take novadays to discover,
> that your SSH listens on different port and how long it
> will take to appear/share/sold that info on some dark
> forums?

Allow me to put it as forthrightly as I can: I do not care in the least where such information appears. I will continue to select a non-standard port for as long as it demonstrably improves the signal-to-noise ratio of my logs. And I will gladly change the port again, should I wish to. Although, my recently introduced anti-scanning measures should diminish the likelihood of that happening any time soon.

-- 
Kerin Millar

Re: Question on rate limiting on nftables

[Kerin Millar]

On Mon, 8 Jun 2026, at 3:32 PM, Slavko wrote:
> Dňa 8. júna 2026 12:45:55 UTC používateľ Kerin Millar 
> <kfm@plushkava.net> napísal:
>
>>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.
>
> Not worth of change ports, soon or latter it will be found
> and abused as default port.

In my experience, choosing a random high port has a demonstrable effect on reducing sshd(8) log noise. I make no claim that it eliminates log noise outright, nor that it places the service beyond the purview of bots at large.

>
> Fail2ban or so, can block addresses selectively. BTW, here after
> long time (1-2 years) of banning the counts drops from hundreds/thousands
> addresses daily to tens daily. Currently, i have banned 30 addresses
> with bantime up to 90 days, from that the ~20 is today "spike".

I understand that you probably have different requirements to the OP. Still, no userspace tool is needed if the only criteria by which a ban is to be exacted is that of exceeding a TCP connect rate limit. Netfilter, itself, is best positioned to manage that.

--
Kerin Millar

Re: Question on rate limiting on nftables

[imnozi]

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.