Thanks Kerin for the Info.
The workaround is not fulfilling . The use case for me is multiple
seconds combination.
I Wanted to keep new connections, at given every 10 seconds period I
don't won't to allow more than 15 connections
Let me explain , as I Wanted to accept new connections, at given every
10 seconds period I don't won't to allow more than 15 connections .
With the below rule, ex: say on a src client If I run 15 connections
in one second because of 15 packets burst the rule will accept, from
2nd second onwards it accepts 1 each second until it reaches 10
seconds. basically the rule shouldn't accept any more until it reaches
10 seconds. this the problem with all two work around I said earlier.
The goal is at given every 10 seconds period I don't won't to allow
more than 15 connections. With burst say If accept 15 connections at
1st second, then the next connection shall be accepted only at 16th
second. This is where I am struck please.
table ip filter {
set ratelimit {
type ipv4_addr
flags dynamic
timeout 15s
}
chain INPUT {
type filter hook input priority filter; policy accept;
tcp dport 8000 ct state new update @ratelimit { ip saddr limit
rate over 1/second burst 15 packets} drop
}
Thanks
Sreedhar
On Thu, Mar 7, 2024 at 12:30 PM Kerin Millar <kfm@xxxxxxxxxxxxx> wrote:
>
> On Thu, 7 Mar 2024, at 10:08 AM, Sreedhar M wrote:
> > This is really inconvenient that we cant rate limit the packets for
> > multiple seconds , we have only the close enough but not 100% right in
> > edge cases.
> > "1/second burst 10 packets" should be close enough. The bucket will be
> > initialised with 10 tokens and refilled at a rate of 1 per second.
>
> I understand that it it is not precisely what you are asking for and am definitely not opposed to the idea of supporting more flexible intervals. At the same time, I don't see what renders the suggested rule so very inconvenient. Should the bucket be drained through flooding, it will achieve the overall aim of allowing for no more than 10 packets to pass over 10 seconds.
>
> Regardless, it is possible to implement more powerful rate limiting schemes through the use of dynamic sets, as should become clear momentarily.
>
> >
> > I really cant have an alternative for below please
> > iptables-translate -A rms0 -p tcp --dport 8000 -m state --state NEW
> > -m recent --update --seconds 10 --hitcount 15 -j DROP
> > nft # -A rms0 -p tcp --dport 8000 -m state --state NEW -m recent
> > --update --seconds 10 --hitcount 15 -j DROP
>
> Since this is a different problem to the one that you initially described, it would be premature to infer that you can't have an alternative. Fortunately, you can. Below is a small ruleset, demonstrating how it can be implemented.
>
> table ip filter {
> set ratelimit {
> type ipv4_addr . inet_service
> flags timeout
> }
>
> chain INPUT {
> type filter hook input priority filter; policy accept;
> tcp dport 8000 ct state new update @ratelimit { ip saddr . th dport timeout 10s limit rate over 1/hour burst 15 packets } drop
> }
> }
>
> It works by creating a dynamic, named set and leveraging the ability of ntables to update sets from the packet path. Each time the rule is matched, it adds or updates the set with an element consisting of both the source address and destination port. Newly added elements bear the given rate limiting policy, along with a timeout of 10 seconds, thereby matching your --seconds parameter. The capacity of the bucket is set to 15 tokens, thereby matching your --hitcount parameter. The buckets of elements that continue to survive the timeout will be credited with a single token every hour - a deliberately long interval (you may lengthen it further if you wish).
>
> I would suggest taking a look at the SET STATEMENT section of the nft(8) man page:
>
> LESS+='+/SET STATEMENT' man nft
>
> There is also some information in the wiki:
>
> https://wiki.nftables.org/wiki-nftables/index.php/Meters
>
> --
> Kerin Millar
--
Best Regards
Sreedhar
