On Thu, Mar 21, 2013 at 2:53 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > Packets that are invalid do not destroy the conntrack entry. The TCP > tracker explicitly destroys the entry by calling nf_ct_kill function > in some situations (RST seen / tracking is out-of-sync). > Well, it means that nf_conntrack_put doesn't kill the conntrack as I thought. I still can't understand how the nfct from skb works. What is that "use" value that makes nf_conntrack_put() call nf_conntrack_destroy() when it equals zero? Well, I suppose it's not that important for me. At least I have my answer, thank you :) -- nimai On Thu, Mar 21, 2013 at 2:53 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > Hi Nicolas, > > On Thu, Mar 21, 2013 at 01:57:33AM +0100, Nicolas Maître wrote: >> Hi, >> >> I've developed a connection tracking module which I'd like to use for >> detecting packets that may be dropped with an iptables rule. >> That is, the connection tracker can detect that a packet is not valid >> in the context of the tracked connection. So, I'd like the >> administrator to be able to add a rule that would allow to drop/reject >> that packet. >> A possible use case is to block packets from an attacker (assumed as >> such as the packet is not conform considering the current state of the >> connection). >> >> As far as I understand it, the connection tracker usually handle this >> by returning a negative/null value (-NF_ACCEPT, NF_DROP, ...) which >> marks the packet invalid, so that it is possible to use the >> xt_conntrack extension to match it. >> >> I've looked at the TCP connection tracker. If I understand well, the >> current behavior is that if we've got an INVALID packet, it kills the >> conntrack, then create it again if we see an ACK later on. Am I right? > > Packets that are invalid do not destroy the conntrack entry. The TCP > tracker explicitly destroys the entry by calling nf_ct_kill function > in some situations (RST seen / tracking is out-of-sync). > -- Nicolas -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
