Bro vs NetFlow

I’ve been running Bro 2.1 as part of Security Onion on our Internet edge for quite a while now, and I’ve found that at least for security-related tasks I now almost always use Bro instead of NetFlow, in situations where I would have previously used NetFlow alone.

We are currently evaluating new NetFlow products, and I started wondering: do folks using Bro also use NetFlow as part of day-to-day operations, or are the NetFlow users generally on a separate network team that’s not using Bro at all? Has anyone completely replaced NetFlow with Bro?

I’m aware that Bro has a NetFlow v5 analyzer, but I don’t know much about it. Is anyone using that extensively? If so, how?

However, one of the reasons we’re looking at a new NetFlow product is for compatibility with various proprietary IPFIX export data, such as Cisco’s various exports based off their NBAR2 feature set. I remember Seth mentioning at FloCon that writing an IPFIX analyzer for Bro would be insanely complex, so I don’t have hopes of that happening anytime soon.

Jay Swan

Hi Jay,

We use both NetFlow and Bro.

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. 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. 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.

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

alec

We use both, they're very complementary. Detailed info from Bro, less so with netflow. We collect netflow from our core routers and border fibers (using argus and indexing them live into Splunk), bro is just border and a few key places internally. We're using snort also - why settle for less info when you can have more? :slight_smile:

--- Steve

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. :slight_smile:

  .Seth

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

Even at the NCSA, with our strong use of Bro, we record and utilize netflows. Part of it is because we have tools and infrastructure in place to quickly search NetFlows. Part of it is because all our routers give us NetFlows, giving us some views of internal traffic that Bro sensors will never see.

It really isn't an either-or case for us.

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.

I've been meaning to write some scripts for Bro to start doing netflow logging and analysis for a long time but I still haven't done it.

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

Yep, I think this is the major win with netflow. It's pervasive deployment certainly has a lot of benefits.

Hence, we're looking for a new (probably commercial) NetFlow product.

Yeah, Bro is definitely not in a position right now to fill that need for you.

  .Seth

Carnegie Mellon has. We used Netflow and Argus previously, but have replaced them with Bro. We do plan to deploy Time Machine[1] as well. While this isn't duplicating tools, having full PCAPs available complements Bro well.

  --Vlad Grigorescu
    Information Security Office
    Carnegie Mellon University

[1] - <http://www.bro.org/community/time-machine.html>