Bro for embedded use?

Hey everyone,

I’m currently looking at the effectiveness of using Bro in an embedded platform. We’re just going through the process of just getting everything (including all of the libraries) compiled into our build – and we’ve found that with all the dependencies the resultant package is pretty large!

Has anyone had any experience using Bro in an embedded system?

Because we haven’t got it running yet without crashing, we can’t assess the extra resource footprint required for Bro. In general (with limited scripts, not handling a large number of connections, sub 1Mbps throughput), what are the memory/cycle requirements for Bro? I realize that there are a large number of variables here so I’m not looking for an exact answer, more of a ball-park gut feeling one J

Thanks in advance,

Alex

Hi Alex,

We are running Bro on a couple of multicore embedded platforms (Cavium
and Tilera). These are resourceful platforms (with lots of light
cores, up to 64 cores) and lots of memory. So it may not be the best
example for you, but let me know.

Thanks,
Jordi

Hi:

About 5 years ago, I ported Bro 1.5 to run on a Linksys WRT54G router, which was used to monitor some lightly used 100mbps links. It was quite functional in 16M of RAM - I used the openwrt distro, and development toolchain, and had to write a number of stub routines, and/or hack on the code and makefiles to get it to compile.

If you want more info, i’ll see what I can dig up.

Bro has successfully run on Linksys boxes a few years ago.

Alex, can you describe the specifics of your platform a bit more?
Generally, I would say that Bro doesn't need a lot of resources if
traffic volume is low, though my interpretation of "not a lot" may
differ from yours. :slight_smile:

Robin

Robin, Jim & Jordi thank you for your responses, I agree size is in the eye
of the beholder as it were :slight_smile:

We are using an 800MHz processor with 256MB RAM & 512MB flash storage, and
running Linux kernel 2.6.39.1 (freescale powerpc-linux-gnu-4.2.187
toolchain), however we are doing more than just Bro work on the device so we
are looking to understand how much of our footprint Bro will consume.

We will be monitoring a 100mbps link but the throughput should be of the
order of 1-5Mbps at any one time, and will be using Bro to identify
anomalous traffic activity in a few specialized scenarios.

This sounds similar to Jim's router application so should be possible, but
at the moment with not too much hacking of the code its compiling at around
40MB, I'm hoping we can get this down further.

What do people think? Still possible? Any tips for what we should be looking
to in order to optimize for our device?

Thanks,

Alex

at the moment with not too much hacking of the code its compiling at around
40MB, I'm hoping we can get this down further.

Was that compiled without debugging symbols and for size optimization yet? The default compile flags determined in cmake/SetDefaultCompileFlags.cmake are likely going to set "-g -O2" and you might just want "-Os" once you've got something you think is ready for production use. The simple way I'm seeing to get that right now is to just hack that file directly and make sure it sets CMAKE_BUILD_TYPE to "MinSizeRel", or if that doesn't give the desired flags, set it to "None" and have CFLAGS/CXXFLAGS set before running ./configure.

    Jon

I noticed in a later thread that you mentioned you are running on a powerpc platform. Could we get a backtrace to see where Bro is crashing? My suspicion is that the crashes are due to this.

  .Seth

Robin,

I was wondering if you could help us out. We've been hitting our head
against the wall trying to get Bro doing what we need and we're running out
of time. We need to get a simple demo done by the end of the month that we
thought would be simple to do in Bro but is fast becoming a nightmare!

I know you guys are busy, but could you assist?

What we want to do is simple:
1. Track the amount of TCP traffic over the course of an hour and log it
2. If the amount of traffic over one hour goes above a certain amount then
raise an alarm - hopefully spawn a process to send an SNMP trap rather than
send an email
3. Record the netflow info of each connection in a log

It's that simple!

We probably sound like idiots, but for some reason we can't work out how to
do it. Anything you could do to point us on the right direction would be
great.

If we could possibly have a telecom as well, then we'd be ecstatic :slight_smile:

Much obliged, and I hope your Bro-Exchange went well

Alex

I'm probably way off base here, but since you mention netflow, why not use it?

Or use the conn.log