* synflood +syncookies + conntrack strange behaviour
@ 2013-05-10 1:04 Alex Flex
2013-05-11 0:07 ` Alex Flex
2013-05-11 18:26 ` Pascal Hambourg
0 siblings, 2 replies; 6+ messages in thread
From: Alex Flex @ 2013-05-10 1:04 UTC (permalink / raw)
To: netfilter
Hello Netfilter,
Today I wanted to do some LAN tests with two machines, where i would use
one to syn flood the other.
Iam using a firewall with conntrack enabled. I noticed that while I made
the attack (50k pps @ 15mbitsfrom random IPs) I immediately saw the
conntrack max count reach 65535 which is my max value. Packets
immediately started being lost almost in full.
Questions:
a.) Shouldnt syn cookies (which is enabled) deal with the syn flood
without compromising my state table?
b.) Why if my state table is full am I not getting any table full error
message in dmesg or syslog? I tried setting max conntrack to something
lower (10,000)and even maxed out it didnt give any warning. In fact i
had to set it to 100 and only at that time I got the conntrack error
full message??
c.) I tried disabling iptables all together (thus no conntrack)and I
still saw 100% packetloss , iam sure iamnot hitting a cpu or link limit
because previously i hit a 100k pps 50mbits, and now iam doing half that
for testing and still using syncookies. Why would i still be lossing
packets?
Thanks for the help!
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: synflood +syncookies + conntrack strange behaviour
2013-05-10 1:04 synflood +syncookies + conntrack strange behaviour Alex Flex
@ 2013-05-11 0:07 ` Alex Flex
2013-05-11 2:21 ` Pablo Neira Ayuso
2013-05-11 18:26 ` Pascal Hambourg
1 sibling, 1 reply; 6+ messages in thread
From: Alex Flex @ 2013-05-11 0:07 UTC (permalink / raw)
To: netfilter
Hello netfilter,
Iam still wondering if the lack of error for the conntrack table full
may be a bug in the module? Any help is much appreciated.
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: synflood +syncookies + conntrack strange behaviour
2013-05-11 0:07 ` Alex Flex
@ 2013-05-11 2:21 ` Pablo Neira Ayuso
2013-05-11 18:05 ` Alex Flex
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2013-05-11 2:21 UTC (permalink / raw)
To: Alex Flex; +Cc: netfilter
On Fri, May 10, 2013 at 06:07:23PM -0600, Alex Flex wrote:
> Hello netfilter,
>
> Iam still wondering if the lack of error for the conntrack table
> full may be a bug in the module? Any help is much appreciated.
The early_drop code is evicting one of the entries from the table to
make room for some new flow:
http://lxr.linux.no/#linux+v3.9.1/net/netfilter/nf_conntrack_core.c#L606
Packets are dropped if the table is full *and* if no unassured flows
to evict are found.
Regards.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: synflood +syncookies + conntrack strange behaviour
2013-05-11 2:21 ` Pablo Neira Ayuso
@ 2013-05-11 18:05 ` Alex Flex
0 siblings, 0 replies; 6+ messages in thread
From: Alex Flex @ 2013-05-11 18:05 UTC (permalink / raw)
To: netfilter
Pablo,
Thank you for clearing that aspect! I now understand why not always do i
get an error...
However the following two points still have me confused..
a.) If I enable syn cookies, shouldnt it stop completely the SYN RECV
state connections in my netstat? Because i still do get them a lot. In
fact my tests reveal that with or without syn cookies the maximum
connections in SYN RECV always reach 256 and then no more connections
are allowed.
b.) I tried disabling iptables all together (thus no conntrack) and I
still saw 100% packetloss , iam sure iamnot hitting a cpu or link limit
because previously i hit a 100k pps 50mbits, and now iam doing half that
for testing and still using syncookies. Why would i still be lossing
packets?
Thanks
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: synflood +syncookies + conntrack strange behaviour
2013-05-10 1:04 synflood +syncookies + conntrack strange behaviour Alex Flex
2013-05-11 0:07 ` Alex Flex
@ 2013-05-11 18:26 ` Pascal Hambourg
2013-05-11 18:47 ` Alex Flex
1 sibling, 1 reply; 6+ messages in thread
From: Pascal Hambourg @ 2013-05-11 18:26 UTC (permalink / raw)
To: netfilter
Hello,
Alex Flex a écrit :
>
> a.) Shouldnt syn cookies (which is enabled) deal with the syn flood
> without compromising my state table?
No. Syncookies and conntrack are unrelated. Syncookies are in the TCP
stack while conntrack is in netfilter.
> c.) I tried disabling iptables all together (thus no conntrack)
Conntrack and iptables are two distinct parts of netfilter. You can have
iptables disabled and contrack enabled (not very useful though).
To disable conntrack you must not load, or unload, the conntrack kernel
modules, or use iptables' NOTRACK target on all traffic.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: synflood +syncookies + conntrack strange behaviour
2013-05-11 18:26 ` Pascal Hambourg
@ 2013-05-11 18:47 ` Alex Flex
0 siblings, 0 replies; 6+ messages in thread
From: Alex Flex @ 2013-05-11 18:47 UTC (permalink / raw)
To: netfilter
Pascal,
Thank you for your reply.
Ok, I made sure:
a.) conntrack is 100% disabled.
b.) iptables is enabled with a simple stateless ruleset.
c.) Syn cookies is enabled.
The issue is: In my testing Iam still being able to exaust *something*
because immediately when i hit a syn flood on port 80 (medium size) I
get imediate packet loss (as seen through ICMP, also i cannot ssh in the
machine and unable to reach port 80.
IF i disable syncookies then: I can ping the machine fine no packetloss
but I cannot reach port 80 (seems this port is the only one in packetloss)
Question: What resource can be exausted both when syncookies is enabled
and disabled for this to happen?
Thanks
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-11 18:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-10 1:04 synflood +syncookies + conntrack strange behaviour Alex Flex
2013-05-11 0:07 ` Alex Flex
2013-05-11 2:21 ` Pablo Neira Ayuso
2013-05-11 18:05 ` Alex Flex
2013-05-11 18:26 ` Pascal Hambourg
2013-05-11 18:47 ` Alex Flex
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox