On Wednesday 2010-07-28 07:24, Mart Frauenlob wrote: > On 28.07.2010 00:50, dennisml@xxxxxxxxxxxx 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.) -- 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
