Re: Synflood filtering and Conntrack

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

On 29.07.2010 13:21, Jan Engelhardt wrote:
>
> On Thursday 2010-07-29 13:11, Mart Frauenlob wrote:
>> 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.
>
> Oh we'll all die of earlier arthritis now...
>
FU

>>>>> 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.
>
> And can be disabled again by -j CT --notrack.
>
>>>> 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?
>
> It does not matter what state a ct is in; DROP won't destroy a ct (see
> below).
>
>>> 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).
>
> Perhaps you've forgot something?
>
> # iptables -I INPUT -p tcp --dport 23 -j DROP
> # conntrack -E&   telnet localhost 23
> [1] 6949
> Trying ::1...
> telnet: connect to address ::1: Connection refused
refused? on DROP?
my nc does show a timeout.

> Trying 127.0.0.1...
>      [NEW] tcp      6 120 SYN_SENT src=127.0.0.1 dst=127.0.0.1 sport=59734 dport=23 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=23 dport=59734
>
> ...seconds later...
> # conntrack -L | grep =23
> conntrack v0.9.14 (conntrack-tools): 12 flow entries have been shown.
> tcp      6 97 SYN_SENT src=127.0.0.1 dst=127.0.0.1 sport=59734 dport=23 packets=1 bytes=60 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=23 dport=59734 packets=0 bytes=0 mark=0 secmark=0 use=2
>
> 2 minutes it is.
>
oh, well exactly what I did.
maybe my conntrack tools version is too old.
I don't care atm.
Software is full of bugs.
Anyway /me out of this l33t list.

thanks a bunch for nothing.


Mart