additional conntrack feature

additional conntrack feature

[Donovan]

Hi,

We are writing Proof Of Concept (POC) code to export (send) enhanced 
NetFlow based on conntrack events. We've added some new minimal 
functionality to the kernel socket and netfilter-conntrack code. This 
provides new information in the events as can be viewed by the conntrack 
program.

We would like to send NetFlow based on the conntrack events and were 
wondering where to place such functionality. We would like such NetFlow 
to be sent by a service or daemon and we would like for this 
functionality to become open source. We have some questions:

- Would it be acceptable to enhance conntrack-tools to send this NetFlow?
- Like for instance placing it in the conntrackd daemon?
- Or would it be OK to provide a new program alongside conntrack and 
conntrackd or the conntrack-tools to do this?

Getting the kernel changes committed is one matter but they are 
pointless without a user-space program to make use of the conntrack 
events and send the NetFlow which is our final aim. We did also think of 
potentially adding such code to the existing flow-tools suite 
(http://www.splintered.net/sw/flow-tools/docs/flow-tools.html)  but it 
feels odd that such flow-tool code will rely on conntrack events.

Thanks
Donovan

Re: additional conntrack feature

[Pablo Neira Ayuso]

On Thu, Apr 17, 2014 at 05:25:45PM -0400, Donovan wrote:
> Hi,
> 
> We are writing Proof Of Concept (POC) code to export (send) enhanced
> NetFlow based on conntrack events.

I guess you refer to IPFIX? We got some recent patches to get it
working in ulogd2.

> We've added some new minimal functionality to the kernel socket and
> netfilter-conntrack code.  This provides new information in the
> events as can be viewed by the conntrack program.
>
> We would like to send NetFlow based on the conntrack events and were
> wondering where to place such functionality. We would like such
> NetFlow to be sent by a service or daemon and we would like for this
> functionality to become open source. We have some questions:

> - Would it be acceptable to enhance conntrack-tools to send this NetFlow?
> - Like for instance placing it in the conntrackd daemon?
> - Or would it be OK to provide a new program alongside conntrack and
> conntrackd or the conntrack-tools to do this?

ulogd2 is the logging netfilter stub, so it's the right framework for
logging extensions IMO.