I am trying to add BRO the ability to ignore traffic from certain IP ranges
I have a DB with IP addresses (that chances once in a while) and I would
like to write a BRO script that will query the DB once in a while, grab
those IP addresses and drop new connections with these IP's.
1. Is it possible to query a DB from BRO scripts? is there any examples?
2. Assuming yes, should i implement this logic at the 'new_connection'
event? (I would like to drop connections from these IP's as soon as
I like that broctl will roll logs over every hour. My default
broctl.cfg file includes:
# Rotation interval in seconds for log files on manager/standalone node.
LogRotationInterval = 3600
I don't like getting an email from broctl every hour, though. Is
there a way to get a daily report, instead of an hourly report?
The Bro README  claims:
"BroControl sends four types of mails to the address given in MailTo:
1. When logs are rotated (per default once a day), a list of all
alarms during the last rotation interval is sent. This can be disabled
by setting MailAlarms=0."
But elsewhere in the README:
"LogRotationInterval (int, default 3600)
The frequency of log rotation in seconds for the manager/standalone node."
This is confusing to me -- maybe someone can help me understand. Are
they talking about two different things?
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,
I'm using the latest development build 2.0-907.
The deployment consists of six servers; one as a manager and the other five
as nodes. Each node runs 20 workers and 2 proxies. The manager is
FreeBSD; the workers are Linux with PF_RING transparent_mode=2.
After starting bro, the manger continually consumes memory until system
exhaustion (64GB). The CPU usage is high as well.
Another problem is over 50% of the workers consume 100% CPU. This is very
odd considering the low volume traffic between 400-1000 Mbps per node.
Where do you suggest I start debugging this ?
Bro 2 has been crashing for me regularly and frequently for several
months. [ http://bit.ly/JJQVVf ]
Although I configured Bro in a way that works for me, it would still
be nice to use it as it is intended to be used.
I studied a number of crash dumps, and have looked through the code.
I was seeing crashes with the Bro 2.0 release, but I am now using a
version of Bro 2.0 from the git repositories that I checked out on
April 30. I saw very similar crashes in both versions.
Line 78 in PktSrc.cc is consistently related to issues in the
backtraces I'm getting from bro core dumps. I really haven't written
much code with libpcap, so there's probably a good reason to use
pcap_next() there. I'm just wondering, why not use pcap_next_ex()
there and do a bit of error checking before passing packet data along?
The way it is right now, it looks like the code just trusts that
pcap_next() read a packet successfully and then hands it off.
I think that in my case, something is going wrong with the call to
pcap_next() -- it's returning a pointer that doesn't make any sense.
If there was a little error checking around pcap_next() by using
pcap_next_ex() instead, maybe that would prevent the crash I'm seeing.
On the other hand, maybe there is some code that does some error
checking on if the value returned by pcap_next() makes sense and I'm
just not finding it.
Can anyone help me understand the choice to use pcap_next() vs pcap_next_ext()?
I'm running a clustered Bro instance with workers capturing traffic on
three PF_RING enabled e1000e interfaces.
While looking in /proc/net/pf_ring/ I noticed that all of my Bro
workers belong to cluster id 21. Is it possible (or desirable) in Bro
to create a PF_RING cluster id per capture interface?
I read that PF_RING allows a maximum of eight workers per cluster id,
is this still true?
Those who are going to be attending the Bro Exchange in Boulder next week should be aware that this time of year daily afternoon thunderstorms may be expected. Also, the temperatures at night are starting to fall, and temps in the fifties will be expected. If you plan to go up into the mountains it may even get into the thirties at night, depending on how high you go up. At 10,000' you should expect overnight lows in the low forties to high thirties, with always a possibility of frost at that altitude.
Boulder will not be so extreme but it's possible for it to get quite chilly at night. So be warned!
Data Security Mgr, Boulder County IT
CISSP GSEC GCIH
Just a reminder that the Bro Exchange is coming up soon. There's still
time to register at
Make sure to check out the agenda, we have some pretty nice talks
The Bro Exchange 2012 will take place on August 7-8, 2012, at the
National Center for Atmospheric Research in Boulder, Colorado.
Looking forward to seeing many of you there,
Robin Sommer * Phone +1 (510) 722-6541 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
Can anyone please help me out with Bro's architecture- based on their
own knowledge, or documentation or books or references available for
I wish to understand the architecture at a high level of abstraction
and understand the various modules, their dependencies, what part of
the source code does what, where does the signature engine lie, where
is the anomaly engine, etc.
I am a grad student trying to get acquainted with Bro. I have tried using
it on a few datasets available (including the old DARPA ones). I am able to
get logs and notices and weirds, but I have doubts about Bro configuration:
1. How do the IP ranges specified in Site::local_nets and networks.cfg
affect Bro's monitoring? Do they have different use cases, or can they be
used interchangeably? Or do they have nothing to do with each other? (As of
now, my Site::local_nets and networks.cfg are identical.)
2. From my layman's understanding, given a PCAP, the larger the window of
time and the number of packets that a system looks at the more accurate its
detection could be, the tradeoff being that of memory/performance. (I guess
there won't be any packet dropping when reading PCAPs.) Is that true?
3. For someone who doesn't know much about the Bro language, are there any
generic configuration settings or tunables that might improve detection
rates? Like the maximum size up to which a packet is read, or the number of
packets that Bro simultaneously analyzes. (Snort has some parameters along
4. How does Bro handle packet defragmentation and stream reassembly? Is
there documentation for the internals, about the various components and
analyzers and how they analyze traffic? I am looking for a basic