[Bro] Bro vs NetFlow

[Swan, Jay]

I probably screwed up by titling the thread Bro *versus* NetFlow... I was mainly curious if anyone had managed to do away with NetFlow analysis through pervasive use of Bro. I didn't think that would likely be the case.

The best thing about our existing commercial NetFlow product is that it integrates into our existing commercial NMS system, so all the sysadmins and help desk people can see it if they want to. It has a lot of problems, however, with stuff like directionality, flow deduplication, and data summarization (it drops flow details to save space that are valuable for forensics).

I don't think I could get all the performance-related data I want just from Bro, at least at my current level of expertise. Forensically, I think Bro has almost everything I want, but putting sensors at every tiny location we have is logistically infeasible, but we already have IPFIX-exporting Cisco routers at all those locations. Hence, we're looking for a new (probably commercial) NetFlow product.

Jay

-----Original Message-----
From: Seth Hall [mailto:seth at icir.org] 
Sent: Monday, October 07, 2013 2:48 PM
To: Alec Waters
Cc: Swan, Jay; bro at bro.org
Subject: Re: [Bro] Bro vs NetFlow


On Oct 5, 2013, at 11:54 AM, Alec Waters <Alec.Waters at dataline.co.uk> wrote:

> Each has its pros and cons of course, but from my point of view NetFlow is a "truer" picture of flow activity because it's a 100% layer3 export - things like malformed TCP streams sometimes won't get logged by apps that take a layer4-or-higher view of the world.

That's not exactly true.  Netflow is unidirectional layer-4 (except for newer bidirectional ipfix extensions).

> It's also unidirectional - apps that that mung the A->B traffic together with the B->A traffic occasionally suffer from ambiguity of client/server identity, which makes report writing hard.

I've thought about this for a long time and I think the conclusion that I reached is that all you are doing in that model is placing the analysis and understanding of the connections onto analysts.  When I did a lot of Netflow analysis I was constantly working to figure out the flows that matched in each direction.  The only difference in Bro is that it's doing that combining for you which would seem to make sense to me since a lot of people aren't aware of the crazy complexity you can have in trying to interpret netflow.  

Granted, Bro (and all other packet sniffers) will be wrong sometimes but you will have typically have confusing netflow in those cases of failure too.

> Finally, NetFlow can be configured to prematurely export long-lived flows meaning that you can see how many bytes were transferred at different points in the flow, rather than just knowing that X bytes were transferred in total.

You could do this in Bro too.  It would be pretty easy to write a Bro script to do a netflow-style log for connections every X minutes.  I just chose to avoid this model in Bro by default because of the number of times broken flows tripped me up in the past.

>  In my experience, having a two or more tools doing the "same" job in different ways isn't the galactic waste it may appear to be J

After all of my curmudgeonly grumbling, I totally agree with this. :)

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/