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.
