Re: [nftables] netdev rate limiting | timeouts rfq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 28/09/2020 20:15, ѽ҉ᶬḳ℠ wrote:

On 28/09/2020 19:56, Pablo Neira Ayuso wrote:
On Mon, Sep 28, 2020 at 05:38:00PM +0000, ѽ҉ᶬḳ℠ wrote:
On 28/09/2020 19:01, Pablo Neira Ayuso wrote:
On Mon, Sep 28, 2020 at 04:47:00PM +0000, ѽ҉ᶬḳ℠ wrote:
To get a flexible evaluation period for the count value:

* ct state { new , invalid } update @glv4 { ip saddr ct count over 50
timeout 1s } log flags all prefix "glv4 DROP: " drop

update set element for any saddr that exceeds the count of 50 within 1 s for
ct state new | invalid


* ct state { new , invalid } update @glv4 { ip saddr ct count over 75
timeout 1s } log flags all prefix "glv4 DROP: " drop

update set element for any saddr that exceeds the count of 75 within 1 h for
ct state new | invalid


* ct state { new , invalid } update @glv4 { ip saddr ct count over 75
timeout 1s } log flags all prefix "glv4 DROP: " drop

update set element for any saddr that exceeds the count of 150 within 1 d
for ct state new | invalid
Thanks, these are looking better, although still not correct.

Two issues:

* 'ct count' relies on the connection tracking table. This is counting
    the number of existing connections in this table according to your
    key, ie. ip saddr. You do not have to specify timeouts here because
    it is the connection tracking time that governs when the conntrack
    entries expire.
suppose those are stipulated in net.netfilter.nf_conntrack_[proto]_timeout ?

This is a bit inflexible though, an offender might not probe within such conntrack stipulated timeout but say in infrequent intervals, one would have to stipulate a count of 1 to catch such saddr at any given time (conntrack timeout), which would be fine for ct state new but could lead to some false
positive with ct state invalid.

Moreover, if not specifying a timeout for the set then how is the saddr
element going to be removed ever? As far as I comprehend there are two
parameters (whichever yields first) for elements being purged (save for
manual purging)  from a set:

* size - if exceeded oldest elements being purged first

or

* timeout - if counted down to zero element being purged.

With no timeout in the set elements may live forever, which is not really
wanted for a dynamic sort of set.
That's not how it works: ct count implements a garbage collector to
purge old list of connections whose key is ip saddr.

http://workshop.netfilter.org/2018/wiki/images/2/23/Connlimit.pdf

The connection tracking table entries are released once they expire.
Connection in TIME_WAIT and CLOSE state are already assumed to be
close, hence not being counted.

How is that in less abstract (sort of layman) terms?

nft_connlimit stores conntrack objects from the conntrack table and once those objects expire in the conntrack table said garbage collector is retiring elements from the set?

With 'gc-interval'  one could then exercise some sort of control over the element's lifespan in the ct state set?


Just figured gc-interval does not work for ct state based sets. With no timeout control and TIME_WAIT and CLOSE state not counting there is no use for ct state based dynamic sets to gather meaningful data about offenders, even saddr ct count over 0 there is hardly any element in the set and if there is it is just too short-lived.



* You have to use 'add' instead of 'update'. Update makes sense to
    refresh timeouts when they are in place, but there is no timeouts in
    this case.

Therefore, make sure you define the dynamic set with not timeouts at
all when combining this with ct count.

Using 'update' in your rule with ct count and/or 'timeout' in your set
definition will make you hit "Operation not supported".
Having the set then as:

   set glv4 {
     type ipv4_addr
     size 65535
     flags dynamic
     counter
   }

and the rule in pre-routing chain

ct state new add @glv4 { ip saddr ct count over 25 }

and still been hitting:

  Error: Could not process rule: Not supported

until removed 'counter' from the set, then reading

   set glv4 {
     type ipv4_addr
     size 65535
     flags dynamic
   }
The counter is a stateful expression and ct count is also a stateful
expression too.

You can only use one single stateful expression per set set element at
this stage.

That is curious/confusing (me) because adding 'counter' to the rule does not throw an error:

ct state new add @glv4 { ip saddr ct count over 25 } counter











[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux