Re: Synflood filtering and Conntrack

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Jan Engelhardt a écrit :
> On Thursday 2010-07-29 14:34, Pascal Hambourg wrote:
>>>> 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.
>>
>> That's because it is a locally generated connection, so the conntrack
>> confirm takes place after POSTROUTING. Even though the packet is dropped
>> in INPUT after it is looped back, the conntrack entry is already
>> confirmed. Now try again with the DROP rule in OUTPUT, or from a remote
>> host.
> 
> But the ct entry must undoubtly exist to be able to match -m conntrack 
> --ctstate NEW. Perhaps it's just that conntrack(8) won't show it?

I don't know how things work internally [1], but from the outside it
seems to me that the conntrack entry exists only until the packet is
dropped, i.e. very briefly.

[1] I can read C, but that does not mean I can understand the thousands
of lines of the kernel source code.