Synflood filtering and Conntrack

Synflood filtering and Conntrack

[Dennis J.]

Hi,
today I ran into a problem where several IPs where syn-flooding one of our 
webservers. The first issue was that the conntrack table was filled up on 
the firewall and I had to put a NOTRACK rule into the raw table to get that 
"fixed". Once we got a better picture of the situation we blocked the 
offending IPs and things wend back to normal on the web server.

My question is how do I handle this case in a more scalable fashion in the 
future. I found the following rules on the net and they seem to do what is 
needed (namely blocking IPs that create an excessive number of syn 
connections):

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

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?

Regards,
   Dennis

Re: Synflood filtering and Conntrack

[Mart Frauenlob]

On 28.07.2010 00:50, dennisml@conversis.de wrote:
> Hi,
> today I ran into a problem where several IPs where syn-flooding one of
> our webservers. The first issue was that the conntrack table was filled
> up on the firewall and I had to put a NOTRACK rule into the raw table to
> get that "fixed". Once we got a better picture of the situation we
> blocked the offending IPs and things wend back to normal on the web server.
>
> My question is how do I handle this case in a more scalable fashion in
> the future. I found the following rules on the net and they seem to do
> what is needed (namely blocking IPs that create an excessive number of
> syn connections):
>
> 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
>
> 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?

afaik, the (according) ct entries are destroyed on DROP.

asking the other way round:
what should it remember? - bad packet dropped, awaiting next invalid?

best regards

Mart

Re: Synflood filtering and Conntrack

[Jan Engelhardt]

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 ...

>> 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?
>
> afaik, the (according) ct entries are destroyed on DROP.

They are not destroyed on DROP, and you can easily check that.
(And stop trimming Cc.)


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.)

Re: Synflood filtering and Conntrack

[Pascal Hambourg]

Hello,

Jan Engelhardt a écrit :
> On Wednesday 2010-07-28 07:24, Mart Frauenlob wrote:
>> 
>> afaik, the (according) ct entries are destroyed on DROP.
> 
> They are not destroyed on DROP, and you can easily check that.

Right, the DROP target has no direct effect on conntrack. When a packet
belonging to an already existing (confirmed) connection is dropped, the
conntrack entry is not destroyed. But IIUC when the first packet that
would create a new connection (and a new conntrack entry) is dropped for
any reason before it reaches the conntrack confirm in the LOCAL_IN or
POST_ROUTING hooks (after INPUT or POSTROUTING chains), the conntrack
entry is destroyed, isn't it ? I guess that is what Mart meant.

Re: Synflood filtering and Conntrack

[Jan Engelhardt]

On Wednesday 2010-07-28 15:30, Pascal Hambourg wrote:
>Jan Engelhardt a écrit :
>> On Wednesday 2010-07-28 07:24, Mart Frauenlob wrote:
>>> 
>>> afaik, the (according) ct entries are destroyed on DROP.
>> 
>> They are not destroyed on DROP, and you can easily check that.
>
>Right, the DROP target has no direct effect on conntrack. When a
>packet belonging to an already existing (confirmed) connection is
>dropped, the conntrack entry is not destroyed. But IIUC when the
>first packet that would create a new connection (and a new conntrack
>entry) is dropped for any reason before it reaches the conntrack
>confirm

Think. -m conntrack --ctstate NEW would not work if the ct only
sprung into existence once it is confirmed.
The ct is created about before you enter the mangle-PREROUTING chain.

Re: Synflood filtering and Conntrack

[Pascal Hambourg]

Jan Engelhardt a écrit :
> On Wednesday 2010-07-28 15:30, Pascal Hambourg wrote:
>>
>> Right, the DROP target has no direct effect on conntrack. When a
>> packet belonging to an already existing (confirmed) connection is
>> dropped, the conntrack entry is not destroyed. But IIUC when the
>> first packet that would create a new connection (and a new conntrack
>> entry) is dropped for any reason before it reaches the conntrack
>> confirm in the LOCAL_IN or POST_ROUTING
>> hooks (after INPUT or POSTROUTING chains), the conntrack
>> entry is destroyed, isn't it ?

> Think. -m conntrack --ctstate NEW would not work if the ct only
> sprung into existence once it is confirmed.
> The ct is created about before you enter the mangle-PREROUTING chain.

Did I wrote otherwise ?
I wrote that the new conntrack entry created by a packet is destroyed if
if that packet does not reach contrack confirm, so I believe it implies
that it was created first. You can't destroy something that does not
exist, right ?

1. Packet is seen by conntrack in PRE_ROUTING/LOCAL_OUT -> create
conntrack entry.
2. Packet is seen again by conntrack in LOCAL_IN/POST_ROUTING -> confirm
conntrack entry, otherwise delete it.

Am I correct ?

Re: Synflood filtering and Conntrack

[Mart Frauenlob]

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

Re: Synflood filtering and Conntrack

[Jan Engelhardt]

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...

>>>> 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
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.

Re: Synflood filtering and Conntrack

[Mart Frauenlob]

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

Re: Synflood filtering and Conntrack

[Pascal Hambourg]

Mart Frauenlob a écrit :
> On 29.07.2010 13:21, Jan Engelhardt wrote:
>>
>> # 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.

That's the IPv6 connection attempt. The Telnet server does not appear to
listen on  IPv6, so the connection is refused.

>> 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.

> oh, well exactly what I did.

Probably not exactly.

Re: Synflood filtering and Conntrack

[Jan Engelhardt]

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?

Re: Synflood filtering and Conntrack

[Pascal Hambourg]

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.

Re: Synflood filtering and Conntrack

[Jozsef Kadlecsik]

On Thu, 29 Jul 2010, Jan Engelhardt wrote:

> 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. 

I don't see why it looks soo complicated: of course, a ct entry is created 
by conntrack whenever a new connection is detected. And of course the 
entry is destroyed if the packet, which triggered to create the new entry,
is dropped by a rule. Why should the conntrack entry be kept, if the 
connection is not allowed by the rules?

The new ct entries are kept in the unconfirmed list and only added to the 
conntrack hash iff the entry will be confirmed, that is the entry-creating 
packet won't be dropped by a rule.

> Perhaps it's just that conntrack(8) won't show it?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Synflood filtering and Conntrack

[Gáspár Lajos]

2010-07-29 17:50 keltezéssel, Jozsef Kadlecsik írta:
> I don't see why it looks soo complicated: of course, a ct entry is 
> created
> by conntrack whenever a new connection is detected. And of course the
> entry is destroyed if the packet, which triggered to create the new entry,
> is dropped by a rule. Why should the conntrack entry be kept, if the
> connection is not allowed by the rules?
>
>    
Correct me if I am wrong.

You can only destroy the entry (CONNECTION) if the PACKET which 
"created" the entry is DROPped.
But you can NOT destroy the entry (just wait for timeout) if:
- the DROPped packet is not the first (SYN),
- there is no LOCAL reply,
- packets are FORWARDed.

I think that 99% of the conntrack entries are kept this way until timeout.

It it is true then there is no "standard" real help against a SYN flood. 
(CHAOSTABLES?)


Swifty

Re: Synflood filtering and Conntrack

[Jozsef Kadlecsik]

On Thu, 29 Jul 2010, G?sp?r Lajos wrote:

> 2010-07-29 17:50 keltez?ssel, Jozsef Kadlecsik ?rta:
> > I don't see why it looks soo complicated: of course, a ct entry is created
> > by conntrack whenever a new connection is detected. And of course the
> > entry is destroyed if the packet, which triggered to create the new entry,
> > is dropped by a rule. Why should the conntrack entry be kept, if the
> > connection is not allowed by the rules?
> > 
> >    
> Correct me if I am wrong.
> 
> You can only destroy the entry (CONNECTION) if the PACKET which "created" the
> entry is DROPped.
>
> But you can NOT destroy the entry (just wait for timeout) if:
> - the DROPped packet is not the first (SYN),
> - there is no LOCAL reply,
> - packets are FORWARDed.

Yes, if the conntrack entry is confirmed, i.e the packet which created the 
entry isn't dropped by a rule, then you cannot easily get the entry 
destroyed: either you wait for the timeout, or you can destroy the entry 
manually by the conntrack tool, or by forging an acceptable RST segment 
(former is easier).
 
> I think that 99% of the conntrack entries are kept this way until timeout.
> 
> It it is true then there is no "standard" real help against a SYN flood.
> (CHAOSTABLES?)

You can use the standard limit matchings (limit, connlimit, hashlimit) to 
protect conntrack against SYN flooding. Of course, the already created 
entries remain there and will time out.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Synflood filtering and Conntrack

[Mart Frauenlob]

> On Thu, 29 Jul 2010, Jan Engelhardt wrote:

> They are not destroyed on DROP, and you can easily check that.

YOU could have easily check that - arrogant brick!!!

>>>>> 2 minutes it is.

[...]

> Think. -m conntrack --ctstate NEW would not work if the ct only
> sprung into existence once it is confirmed.

Think yourself.

[...]

> Oh we'll all die of earlier arthritis now...

arrogant bs

[...]

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

Now it's the others... of course.


 > On Thu, 29 Jul 2010, Jozsef Kadlecsik wrote:

> I don't see why it looks soo complicated: of course, a ct entry is created
> by conntrack whenever a new connection is detected. And of course the
> entry is destroyed if the packet, which triggered to create the new entry,
> is dropped by a rule. Why should the conntrack entry be kept, if the
> connection is not allowed by the rules?
>
> The new ct entries are kept in the unconfirmed list and only added to the
> conntrack hash iff the entry will be confirmed, that is the entry-creating
> packet won't be dropped by a rule.

roflmao

Jan: shame, shame, shame - shame on you!


Thanks Pascal, Josef

Re: Synflood filtering and Conntrack

[Pascal Hambourg]

Jozsef Kadlecsik a écrit :
> 
> I don't see why it looks soo complicated: of course, a ct entry is created 
> by conntrack whenever a new connection is detected. And of course the 
> entry is destroyed if the packet, which triggered to create the new entry,
> is dropped by a rule. Why should the conntrack entry be kept, if the 
> connection is not allowed by the rules?
> 
> The new ct entries are kept in the unconfirmed list and only added to the 
> conntrack hash iff the entry will be confirmed, that is the entry-creating 
> packet won't be dropped by a rule.

Thanks for this explanation. Just one more clarification, please : is
the conntrack entry destroyed also if the packet which triggered its
creation is dropped by something else than an iptables rule, such as
routing decision, TTL exceeded, conflict with an existing NAT mapping ?

Re: Synflood filtering and Conntrack

[Jozsef Kadlecsik]

On Fri, 30 Jul 2010, Pascal Hambourg wrote:

> Jozsef Kadlecsik a ?crit :
> > 
> > I don't see why it looks soo complicated: of course, a ct entry is created 
> > by conntrack whenever a new connection is detected. And of course the 
> > entry is destroyed if the packet, which triggered to create the new entry,
> > is dropped by a rule. Why should the conntrack entry be kept, if the 
> > connection is not allowed by the rules?
> > 
> > The new ct entries are kept in the unconfirmed list and only added to the 
> > conntrack hash iff the entry will be confirmed, that is the entry-creating 
> > packet won't be dropped by a rule.
> 
> Thanks for this explanation. Just one more clarification, please : is
> the conntrack entry destroyed also if the packet which triggered its
> creation is dropped by something else than an iptables rule, such as
> routing decision, TTL exceeded, conflict with an existing NAT mapping ?

Yes, if any other subsystem drop the packet, the conntrack entry is 
destroyed as well.

The first packet must pass through (forwarded or delivered to a local 
process), otherwise the ct entry is just created and then destroyed. 
Unfortunately, without a massive redesign of the whole system, we cannot 
get rid of this unfortunate create/destroy ct entry cycle.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary