Re: [nftables] netdev rate limiting | timeouts rfq

[Pablo Neira Ayuso <pablo@netfilter.org>]

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.

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