Contributed by jason on from the don't-forget-to-put-the-seat-down-when-you're-done dept.
Henning Brauer (henning@) has just committed a new pseudo-device to OpenBSD-current. The pflow(4) interface exports IP accounting data over UDP that is compatible with NetFlow version 5. Please continue to read Henning's commit message and a brief introduction to pflow(4) usage.
CVSROOT: /cvs Module name: src Changes by: henning@cvs.openbsd.org 2008/09/09 07:56:39 Modified files: sbin/ifconfig : ifconfig.c sbin/pfctl : parse.y pf_print_state.c pfctl_parser.c sys/conf : files sys/net : if_types.h pf.c pfvar.h sys/sys : sockio.h Added files: share/man/man4 : pflow.4 sys/net : if_pflow.c if_pflow.h Log message: welcome pflow(4), a netflow v5 compatible flow export interface. flows export data gathered from pf states. initial implementation by Joerg Goltermann, guidance and many changes by me. 'put it in' theo
In typical OpenBSD style, this new pseudo-device works seamlessly with the rest of the networking subsystem. It behaves similarly to other virtual networking devices in that you manage it with ifconfig(8) and can even use tcpdump(8) on the interface to monitor flow exports. Setting it up is very simple:
$ sudo ifconfig pflow0 create $ sudo ifconfig pflow0 flowsrc 10.0.0.200 flowdst 10.0.0.1:1234 $ ifconfig pflow0 pflow0: flags=41mtu 1464 pflow: sender: 10.0.0.200 receiver: 10.0.0.1:1234 groups: pflow
Flows are tracked using the state-tracking capabilities in pf(4). States that are marked with the pflow state-opts keyword will be exported by the pflow interface once the state is expired from the session table. Here is a sample pf filter rule that enables flow accounting for outbound ICMP traffic:
pass out inet proto icmp keep state (pflow)
Once the ruleset is loaded, pfctl(8) will report which states are being tracked for pflow exports:
$ sudo pfctl -vss | grep -B2 pflow | head -3 all tcp 10.0.0.200:38336 -> 38.68.100.209:22 ESTABLISHED:ESTABLISHED [3825225521 + 17376] wscale 0 [3569953586 + 16384] wscale 0 age 00:32:58, expires in 23:59:57, 888:894 pkts, 75601:180313 bytes, pflow
This is a very useful feature for IP accounting and can even be handy for network troubleshooting. It effectively replaces the userland pfflowd daemon (net/pfflowd) created by Damien Miller (djm@), although we would still need a collector to receive the exports. Fortunately, Damien also created flowd (net/flowd), a secure NetFlow collector, and the perfect complement to pflow(4).
As a self-described network geek, I'm thrilled by this new addition to OpenBSD. Joerg Goltermann created the initial implementation of this feature, while Henning refined it for the initial import. I expect additional enhancements to pflow(4) as it stabilizes in the tree from testing and daily use. Although this won't be included with OpenBSD 4.4, buying a pre-order would be a great way to show our appreciation for this type of work!
(Comments are closed)
By Anonymous Coward (89.104.121.248) on
Comments
By Anonymous Coward (60.53.30.214) on
1. check ingress traffic only,
2. check egress traffic only,
3. check traffic at specific interface, example a pf-capable FreeBSD router which have 3 interface, em0 (wan),em1 (lan), em2 (dmz), and only capture em2 traffic (which we're interested due to specific reason)?
Banzai OpenBSD. Just ordering 4.4 via Int Order with 1 t-shirt. ;)
-malaysia boleh-
Comments
By Anonymous Coward (60.53.30.214) on
Comments
By jason (jason) on http://www.dixongroup.net/
Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
NetFlow Dashboard
:)Comments
By Anonymous Coward (81.57.42.108) on
> Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
>
> NetFlow Dashboard
>
> :)
Cute!
Is this Dashboard distributed?
Comments
By jason (jason) on http://www.dixongroup.net/
> > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
> >
> > NetFlow Dashboard
> >
> > :)
>
> Cute!
> Is this Dashboard distributed?
It will be soon. I'm wedging it into the chroot with mod_perl, then will announce it officially with an OpenBSD port/package.
Comments
By Terrell Prude' Jr. (151.188.18.46) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
> > > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
> > >
> > > NetFlow Dashboard
> > >
> > > :)
> >
> > Cute!
> > Is this Dashboard distributed?
>
> It will be soon. I'm wedging it into the chroot with mod_perl, then will announce it officially with an OpenBSD port/package.
Will it be available in a traditional tarball as well? We use the Flow-Tools here at work (yes, on Linux, it was pulling teeth to get *that* allowed in our data center). Such a Dashboard would be great.
--TP
By Loop (203.194.27.78) on
> And because it is compatible with NetFlow version 5, is it possible to
> export it to any netflow collector such as Solarwinds Orion NetFlow
> Traffic Analyzer, or probably opensource tool like ntop?
>
>
> Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
>
> NetFlow Dashboard
>
> :)
That is dead sexeh!
WANT!!!!
By jason (jason) on http://www.dixongroup.net/
>
> 1. check ingress traffic only,
> 2. check egress traffic only,
> 3. check traffic at specific interface, example a pf-capable FreeBSD router which have 3 interface, em0 (wan),em1 (lan), em2 (dmz), and only capture em2 traffic (which we're interested due to specific reason)?
Sure, just use the "pflow" state-opt keyword only on those filter rules.
> Banzai OpenBSD. Just ordering 4.4 via Int Order with 1 t-shirt. ;)
:)
Comments
By Anonymous Coward (60.53.30.214) on
> >
> > 1. check ingress traffic only,
> > 2. check egress traffic only,
> > 3. check traffic at specific interface, example a pf-capable FreeBSD router which have 3 interface, em0 (wan),em1 (lan), em2 (dmz), and only capture em2 traffic (which we're interested due to specific reason)?
>
> Sure, just use the "pflow" state-opt keyword only on those filter rules.
>
> > Banzai OpenBSD. Just ordering 4.4 via Int Order with 1 t-shirt. ;)
>
> :)
>
> And because it is compatible with NetFlow version 5, is it possible to
> export it to any netflow collector such as Solarwinds Orion NetFlow
> Traffic Analyzer, or probably opensource tool like ntop?
>
>
> Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
>
> NetFlow Dashboard
>
> :)
Dear Mr Jason,
Thank you very much for above reply. I'm looking forward for pflow(4) manual to be updated and give it tries in my lab.
Have a nice day!
Comments
By Anonymous Coward (60.53.30.214) on
http://talks.dixongroup.net/nycbsdcon2006/
It is very nice, funny and interesting video that I've ever seen in BSD world. ;)
Comments
By jason (jason) on http://www.dixongroup.net/
>
> http://talks.dixongroup.net/nycbsdcon2006/
>
> It is very nice, funny and interesting video that I've ever seen in BSD world. ;)
Guilty as charged. :)
By Anonymous Coward (83.88.170.104) on
I often miss an alternative to "pass ..." and "block..." that doesn't change whether the packet will pass or not. It wold be also usefull for adding tags, logging and queueing.
Off cause there would be no flow if the packet ended up being blocked.
Maybee a "match" keyword. I know it would simplify my rulesets.
Comments
By henning (130.237.95.167) on
>
> I often miss an alternative to "pass ..." and "block..." that doesn't change whether the packet will pass or not. It wold be also usefull for adding tags, logging and queueing.
>
> Off cause there would be no flow if the packet ended up being blocked.
>
> Maybee a "match" keyword. I know it would simplify my rulesets.
that (with exactly that keyword) is on my virtual todo list for ages. 4 years at least. over time my idea on how it is supposed to work got clearer, and be warned: it is entirely nonobvious. well, ok, if you just do match it is easy, but to be really useful you have to think about when what applies. for example, logging only happens on the last matching rule, so a "match log" doesn't help you.
By Anonymous Coward (24.84.63.46) on
Comments
By jason (jason) on http://www.dixongroup.net/
First, it has full access to the PF state table. Since it only needs information about state deletion, it doesn't have all the overhead that pfflowd has (listening to all state updates). In addition, there are other things planned that will probably require access to the PF internals, but I'm just guessing.
Just because it *can* be done in userland doesn't always mean it must. I think this is a good use of in-kernel functionality. CARP *could* have been done in userland, but nobody is complaining about having that in the kernel. ;)
Comments
By mpf@ (88.217.158.50) on
>
> First, it has full access to the PF state table. Since it only needs
> information about state deletion, it doesn't have all the overhead that
> pfflowd has (listening to all state updates).
Actually, if you start pfflowd with a pcap filter like: "link[2]==0x03",
the kernel will only pass it state deletions (via pfsync).
By Frank DENIS (82.224.188.215) on http://00f.net
Actually some people use the userland version of CARP even on OpenBSD, because they need a custom setup (specific scripts to be spawned when ownership is taken, etc).
Comments
By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on
>
>
> Actually some people use the userland version of CARP even on OpenBSD, because they need a custom setup (specific scripts to be spawned when ownership is taken, etc).
You can have scripts spawned without needing UCARP.
By Wouter (2001:888:1b6b:b0e::6965:6b73) on
Comments
By jason (jason) on http://www.dixongroup.net/
[IANAL] I believe that refers to sampled NetFlow, which this isn't.
Comments
By ldso (208.5.80.104) ldso@sourceforge.net on http://marmot.dudeabides.net
>
> [IANAL] I believe that refers to sampled NetFlow, which this isn't.
I would like to hear more about this. So Ciscos and Junipers that we get flows from are sampled. But this isn't, because it shoots out flow data for every connection via pf? I'm interested in what kind of load it puts on various hardware. We are currently using the classic FreeBSD flow-tools solution.
But the fact that it is not sampled doesn't matter I guess, as long as your tools are net-flow v5 capable? I wonder how flow-tools might cope with this, as well as how well our Intel 1U boxes would perform.
Very cool work, good job :) I'll have to play with this when I get back from vacay.
By ates (78.25.11.204) ates@ipv6.dp.ua on
By coward1 (81.169.155.246) on
By joe (98.97.67.6) on
:(
By Anonymous Coward (130.237.95.124) on
By Jessicaparker (38.103.14.140) on