* Drop a packet while keeping the conntrack alive
@ 2013-03-21 0:57 Nicolas Maître
2013-03-21 1:53 ` Pablo Neira Ayuso
2013-03-21 2:05 ` Jorge Dávila
0 siblings, 2 replies; 6+ messages in thread
From: Nicolas Maître @ 2013-03-21 0:57 UTC (permalink / raw)
To: Netfilter Developer Mailing List
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?
That is, it seems that by any way we invalidate a packet, it always
destroy the conntrack so that we haven't the connection state at our
disposal anymore. I would like to avoid that for the protocol I track.
Is there a way to do so? Am I missing something?
Thank you.
--
nimai
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Drop a packet while keeping the conntrack alive
2013-03-21 0:57 Drop a packet while keeping the conntrack alive Nicolas Maître
@ 2013-03-21 1:53 ` Pablo Neira Ayuso
2013-03-21 15:17 ` Nicolas Maître
2013-03-21 2:05 ` Jorge Dávila
1 sibling, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2013-03-21 1:53 UTC (permalink / raw)
To: Nicolas Maître; +Cc: Netfilter Developer Mailing List
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).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Drop a packet while keeping the conntrack alive
2013-03-21 0:57 Drop a packet while keeping the conntrack alive Nicolas Maître
2013-03-21 1:53 ` Pablo Neira Ayuso
@ 2013-03-21 2:05 ` Jorge Dávila
1 sibling, 0 replies; 6+ messages in thread
From: Jorge Dávila @ 2013-03-21 2:05 UTC (permalink / raw)
To: Nicolas Maître; +Cc: Netfilter Developer Mailing List
Hi list,
An example about ...
With the current user space tools
there are ways for tracking INVALID connections.
INVALID connections, IMHO, should be "active" if you create a firewall
with stateless packet filtering and of course, setting the "needed"
values for the kernel parameters.
Jorge Isaac
2013/3/20, Nicolas Maître <nimai@skynet.be>:
> 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?
>
> That is, it seems that by any way we invalidate a packet, it always
> destroy the conntrack so that we haven't the connection state at our
> disposal anymore. I would like to avoid that for the protocol I track.
> Is there a way to do so? Am I missing something?
>
>
>
> Thank you.
>
> --
> nimai
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jorge Isaac Dávila López
---
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Drop a packet while keeping the conntrack alive
2013-03-21 1:53 ` Pablo Neira Ayuso
@ 2013-03-21 15:17 ` Nicolas Maître
2013-03-21 16:07 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Maître @ 2013-03-21 15:17 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Netfilter Developer Mailing List
On Thu, Mar 21, 2013 at 2:53 AM, Pablo Neira Ayuso <pablo@netfilter.org> 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@netfilter.org> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Drop a packet while keeping the conntrack alive
2013-03-21 15:17 ` Nicolas Maître
@ 2013-03-21 16:07 ` Pablo Neira Ayuso
2013-03-21 16:16 ` Nicolas Maître
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2013-03-21 16:07 UTC (permalink / raw)
To: Nicolas Maître; +Cc: Netfilter Developer Mailing List
On Thu, Mar 21, 2013 at 04:17:47PM +0100, Nicolas Maître wrote:
> On Thu, Mar 21, 2013 at 2:53 AM, Pablo Neira Ayuso <pablo@netfilter.org> 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?
That "use" field in the nf_conn object is a refcounter. In SMP, you
may have several packets traveling through the stack referencing to
the same conntrack object. The refcount is initially set to 1 because
there is a timer that releases the conntrack if it expires.
You may also have a conntrack entries that are related to another
master conntrack (eg. FTP helper scenario: the control flow is the
master conntrack, and all data flows are related to it). In that case,
the refcount is also incremented depending on the amount of references
to it.
nf_conntrack_find_get increments the refcount, nf_ct_put decrements it
and it checks if it has become 0, in that case the nf_conn object is
released.
This article may help you to understand better how conntrack works:
https://www.usenix.org/publications/login/june-2006-volume-31-number-3/netfilters-connection-tracking-system
Regards.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Drop a packet while keeping the conntrack alive
2013-03-21 16:07 ` Pablo Neira Ayuso
@ 2013-03-21 16:16 ` Nicolas Maître
0 siblings, 0 replies; 6+ messages in thread
From: Nicolas Maître @ 2013-03-21 16:16 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Netfilter Developer Mailing List
On Thu, Mar 21, 2013 at 5:07 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> That "use" field in the nf_conn object is a refcounter. In SMP, you
> may have several packets traveling through the stack referencing to
> the same conntrack object. The refcount is initially set to 1 because
> there is a timer that releases the conntrack if it expires.
>
> You may also have a conntrack entries that are related to another
> master conntrack (eg. FTP helper scenario: the control flow is the
> master conntrack, and all data flows are related to it). In that case,
> the refcount is also incremented depending on the amount of references
> to it.
>
> nf_conntrack_find_get increments the refcount, nf_ct_put decrements it
> and it checks if it has become 0, in that case the nf_conn object is
> released.
Now that's clearer. Thank you very much!
--
Nicolas Maître
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-03-21 16:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-21 0:57 Drop a packet while keeping the conntrack alive Nicolas Maître
2013-03-21 1:53 ` Pablo Neira Ayuso
2013-03-21 15:17 ` Nicolas Maître
2013-03-21 16:07 ` Pablo Neira Ayuso
2013-03-21 16:16 ` Nicolas Maître
2013-03-21 2:05 ` Jorge Dávila
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.