hdemir, If you're tracking incoming connections using conntrack, you are really defeating the whole purpose of syncookies (i.e. handling incoming SYN in a stateless way). You can set up a iptables firewall which is either totally stateless, or at least does not use state for the open TCP ports which can be SYN flooded. However, even if you do that, you're probably not out of the woods. Even taking ip_conntrack state out of the equation, I still haven't been able to get linux SYN Cookies to scale very well; it still fails around 100-150,000 pps. -SteveK On May 4, 2013, at 5:39 PM, hdemir@xxxxxxxxxxx wrote: > Hi Alex, > > I have a that problem also.I solved with CPU Affinity and disabled all the > power properties of the hardware (s1, s2, s3). But with the syn attack the > problem is that conntrack number increasing too fast. I have a max value > of 10 million and it fills up about less than 10 min. > > ı also wonder about how to stop ddos of conntrack max value. Perhaps > somebody shoul implement conntrack without syn, syn-ack. I think Junioer > has this feature. Like having syncoockies in conntrack. > > > Regards. > > hdemir. > >> Hello Netfilter, >> >> Ive been receiving lately two types of syn floods on an Intel Xeon >> 2.4ghz + 4GB machine exclusively dedicated for this and the findings >> have me very confused: >> I have syn cookies enabled and checked to be working as per syslog. >> This machine has a 10gigabit uplink so I know that networking isnt a >> bottleneck here (bandwith or router hardware based). >> >> SCENARIO 1: the first attack was: 105mbits @ 330,000 pps and it brought >> the machine to 100% CPU usage and over 50% packetloss Load average 12. >> At that time it had a simple iptables script that that had less then 5 >> blacklists of port 80 ips and then a ACCEPT On port 80, nothing fancy. I >> disabled iptables and load average went down immediately to 8 but there >> was still high packet loss so basically we where DoSed efficiently. >> >> SCENARIO 2: After that the attacker sent only a 30mbit synflood @ 70,000 >> pps .. Now i had less packet loss, and interestingly with iptables >> enabled it would create almost immediate packetloss. At this time I >> tried to explore installing conntrack-tools information about the state >> table. conntrack said that with iptables enabled and syncookies the >> maximum entries where 1300 ONLY... and a CPU usage reported by HTOP of >> 40% on SI. After that I decided to drop iptables all together and >> immediately port 80 started flowing with normal traffic (we have less >> than 1mbit clean traffic) . No packetloss was present, because iptables >> was disabled conntrack did not report any entries and netstat-na |wc -l >> reported less than 300. >> >> Questions: >> >> a.) Can anybody suggest why there is so much CPU overhead when iptables >> is turned on and dealing with such PPS? Is this normal? Usually what CPU >> usage does a syn flood cookie enabled take? >> >> b.) Is there a chance that the attacker exausted something else iam not >> seeing? >> >> >> Thanks for the help guys >> >> Alex >> >> -- >> To unsubscribe from this list: send the line "unsubscribe netfilter" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
