Notification of new/destroyed connection

Notification of new/destroyed connection

[Chris Taylor]

Hello all,

Newbie warning!!  I was trying to fool around with netfilter and
nf_conntrack.  I'd like to write a netfilter module that takes action
when a new connection is opened or closed.

Initially I thought about taking the sk_buff and pass it to
nf_ct_get_tuple and then call nf_conntrack_find_get and if it returns
null then I it's a new connection.  But I can't find a way to use this
to see if a connection has been closed.

Then I saw the notification chains and I thought about makeing a
notification block and registering it with
nf_conntrack_register_notifier(struct notifier_block *nb).  I couldn't
find the initial listing of the anticiapted values for the events and
the void* p, but I saw examples in
net/netfilter/nf_conntrack_netlink.c So I then turned my attention to
include/linux/netfilter/nf_conntrack_common.h and saw the difference
b/n ip_conntrack_expect_events and ip_conntrack_events, namely that
ip_conntrack_expect_events only has IPEXP_NEW.

Am I correct to assume that if I need to do some setup in advance of a
connection establishment, then I should subscribe via the
nf_conntrack_register_expect_notifier and wait for a IPEXP_NEW event?
What happenes if I do the setup and the connection is never
established?  Will I get notified of that via the callback registered
with nf_conntrack_register_notifier with a IPCT_DESTROY event?

Am I better off doing this with nf_conntrack or ip_conntrack?  What's
the difference?

Am I headed in the correct direction?

Thanx in advance.

Respectfully,
Christopher Taylor

Re: Notification of new/destroyed connection

[Pablo Neira Ayuso]

Chris Taylor wrote:
> Then I saw the notification chains and I thought about makeing a
> notification block and registering it with
> nf_conntrack_register_notifier(struct notifier_block *nb).  I couldn't
> find the initial listing of the anticiapted values for the events and
> the void* p, but I saw examples in
> net/netfilter/nf_conntrack_netlink.c So I then turned my attention to
> include/linux/netfilter/nf_conntrack_common.h and saw the difference
> b/n ip_conntrack_expect_events and ip_conntrack_events, namely that
> ip_conntrack_expect_events only has IPEXP_NEW.

If you have to check for new and destroyed connections, just register a
module that listens to IPCT_NEW and IPCT_DESTROY events,
ip_conntrack_events in nf_conntrack_netlink is a good example. Forget
about ip_conntrack_expect_events since that functions handles
expectation events, AFAICS this is not what you want.

> Am I correct to assume that if I need to do some setup in advance of a
> connection establishment, then I should subscribe via the
> nf_conntrack_register_expect_notifier and wait for a IPEXP_NEW event?

No, this is for expectations. I suggest you to have a look at [1].

> What happenes if I do the setup and the connection is never
> established?  Will I get notified of that via the callback registered
> with nf_conntrack_register_notifier with a IPCT_DESTROY event?

Then the connection will expire after a certain timeout, no need to
worry about this scenario. You'll get IPCT_DESTROY anyway. You can tune
the timeout if you think that they are too long.

> Am I better off doing this with nf_conntrack or ip_conntrack?  What's
> the difference?

nf_conntrack is layer 3 independent, ip_conntrack is obsoleted and is
scheduled to be removed in 2.6.22 if my mind serves well. So go
nf_conntrack.

> Am I headed in the correct direction?

Basically yes.

[1] http://people.netfilter.org/pablo/docs/

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Notification of new/destroyed connection

[Kerry Ó Cuanacháin]

Following on from the discussion on CT lifecycle events, if one takes
a scenario whereby a newly created connection is subsequently
NF_DROP'd by a filter rule, is it exclusively a timer/timeout which
results in that same connection being destroyed?
Is there any event driven mechanism to inform conntrack that the
packet has been filtered?
Similarly, is there an way to identify the reason for IPCT_DESTROY
from the event raised?


Kind Regards


Kerry

Notification of new/destroyed connection

[Kerry Ó Cuanacháin]

Following on from the discussion on CT lifecycle events, if one takes
a scenario whereby a newly created connection is subsequently
NF_DROP'd by a filter rule, is it exclusively a timer/timeout which
results in that same connection being destroyed?
Is there any event driven mechanism to inform conntrack that the
packet has been filtered?
Similarly, is there an way to identify the reason for IPCT_DESTROY
from the event raised?


Kind Regards

Kerry