Invalidate conntrack using iptables rule

Invalidate conntrack using iptables rule

[halfdog]

Hello List,

Is there a way to (mis-)use an iptables rule to invalidate the
currently established conntrack entry related to an packet being
processed? The packet can be identified due to violating connbytes
and u32 match criteria.

One solution I came up so far to emulate that behaviour was to
set a mark/label on the conntrack when the criteria is met the
first time and then DROP all packets with that mark/label from
here on. But that somehow would bloat the ruleset and keep an
useless conntrack entry in memory where just terminating the
conntrack would do all of it at once.

Another solution might be to modify the conntrack timeout later
in the raw table using "-j CT --timeout [policy]" applying a
timer value of "-1" and thus hopefully immediately invalidating
the conntrack entry.



Is there an easier solution to that problem? If no, which one
of the two solutions from above seems to be easier to implement
and maintain in a stable, riskfree way in the long run?

Kind regards,
hd

Re: Invalidate conntrack using iptables rule

[halfdog]

Hi,

Any comments on this? Without any feedback I would try the policy
timeout -1 method and dig into the kernel code to see if that
should really work without side effects.

hd

halfdog writes:
> Hello List,
>
> Is there a way to (mis-)use an iptables rule to invalidate the
> currently established conntrack entry related to an packet being
> processed? The packet can be identified due to violating connbytes
> and u32 match criteria.
>
> One solution I came up so far to emulate that behaviour was to
> set a mark/label on the conntrack when the criteria is met the
> first time and then DROP all packets with that mark/label from
> here on. But that somehow would bloat the ruleset and keep an
> useless conntrack entry in memory where just terminating the
> conntrack would do all of it at once.
>
> Another solution might be to modify the conntrack timeout later
> in the raw table using "-j CT --timeout [policy]" applying a
> timer value of "-1" and thus hopefully immediately invalidating
> the conntrack entry.
>
>
>
> Is there an easier solution to that problem? If no, which one
> of the two solutions from above seems to be easier to implement
> and maintain in a stable, riskfree way in the long run?
>
> Kind regards,
> hd