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@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx 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 -- 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
