Re: Synflood filtering and Conntrack

[Mart Frauenlob <mart.frauenlob@chello.at>]

On 28.07.2010 08:11, netfilter-owner@vger.kernel.org wrote:
>
> On Wednesday 2010-07-28 07:24, Mart Frauenlob wrote:
>> On 28.07.2010 00:50, dennisml@conversis.de wrote:
>>>
>>> iptables -A INPUT -m state --state NEW -p tcp -m tcp --syn \
>>> -m recent --name synflood --set
>>> iptables -A INPUT -m state --state NEW -p tcp -m tcp --syn \
>>> -m recent --name synflood --update --seconds 1 --hitcount 30 -j DROP
>
> Consider using -m conntrack --ctstate ...
>
Which in this case makes no difference but more typing.

>>> What I'm wondering about is the "--state NEW" part. If I re-enable
>>> connection tracking again for the above rules to work wouldn't these
>>> fill up again and basically make these rules useless? Or can I
>>> essentially remove the state module bits and just use the plain packets
>>> for this since the syn flag is only used in establishing a new
>>> connection anyway which makes the "--state NEW" bit not necessary?
>>
conntrack is not disabled only because you do not use a match.
once conntrack is loaded (module) it is active.
using --[c]state NEW -p tcp ! --syn -j DROP|REJECT sorts out all tcp 
connection attempts of state NEW (for ct) not starting with a syn packet.

>> afaik, the (according) ct entries are destroyed on DROP.
>
> They are not destroyed on DROP, and you can easily check that.

We're not talking about ASSURED/ESTABLISHED connections, do we?

> (And stop trimming Cc.)
There was no Cc to trim?!
What do you want me (not) to do?

> Dennis,
> The TCP ct starts out with something like a timeout of 2 minutes.
> Only if the connection reaches the ASSURED status (--ctstatus
> ASSURED), it will get bumped to the standard lifetime of 5 days.
> Dropping all packets in a connection is of course the way to inhibit
> this transition to ASSURED.
>
> There was once a proposal to add a --timeout option to the xt_CT target
> (proposed by Phil Oester IIRC), however did not show up in iptables yet.
> Adding Pablo to Cc to suggest a way to set the initial ct timeout.
> (Because 2 minutes still is enough to cause a reasonable fillup.)

So what's the deal?
Not assured, but deliberately dropped packets still linger around 2 
minutes in the ct table?
Don't think so.
Testing this, nothing shows up here for 2 minutes (using conntrack -L).

Best regards

Mart