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