Hello members of the mailing list.
What is the proper way to export alarms generated by bro for further
processing/import into another ids?
As far as I understand the docs, bro by default dumps generated alarms
to the file or can send them via email. Is there a way to extend bro to
enable e.g. storing alarms in a database? Or maybe there is a way to
subscribe to alarms from broccoli-enabled custom app (though as far as I
understand the docs, via broccoli one can only subscribe to bro's
events, not alerts or notices)?
The only way to achieve alarm export I see at the moment is to parse the
logfile, which is obviously an ugly cludge.
Thanks in advance for your answers.
PS. And could you please clarify what is the current status of IDMEF
support in bro?Hello.
If you’re using 1.5.x, you can export alarms via syslog like this:
redef enable_syslog = T;
Some of my installations use prelude’s LML to then pull the syslogged alerts in and mix them with the other NIDS/HIDS data.
If you’re using 2.x beta, Martin did a good writeup here on how to use rsyslog to syslog them to another server:
http://ossectools.blogspot.com/2011/09/bro-quickstart-cluster-edition.html
I’m glad you asked about the IDMEF support. I’ve been making some noise for that as well. 
-Lou
Thanks for your answer.
So is the syslog logging (either local or remote) the only alternative to logiles? No database nor ability to add custom log-processing hooks?
As for IDSMEF, I don’t personnaly like the format (bloated xml messages are a nightmare) but it seems this is the only option to handle alerts in a mixed IDS/IPS environment.
So is the syslog logging (either local or remote) the only alternative
to logiles? No database nor ability to add custom log-processing hooks?
No DB interface right now but the new 2.0 logging framework does allow
to plugin different logging backends. Currently, we only have the
ASCII writer that produces the *.log file you're seeing, but binary
output and DB writers are planned. In fact, there's already a patch in
the tracker adding CouchDB support:
http://tracker.bro-ids.org/bro/ticket/634
As for IDSMEF, I don't personnaly like the format (bloated xml messages
are a nightmare) but it seems this is the only option to handle alerts
in a mixed IDS/IPS environment.
Yeah, IDMEF is something we should add. Not totally clear to me yet
though how exactly that would look like on the implementation side.
Robin
No DB interface right now but the new 2.0 logging framework does allow
to plugin different logging backends. Currently, we only have the
ASCII writer that produces the *.log file you're seeing, but binary
output and DB writers are planned. In fact, there's already a patch in
the tracker adding CouchDB support:
Careful on the CouchDB stuff: the write performance is atrocious over
a sustained period. I couldn't get a single-node install to receive
more than a few hundred events per second. MongoDB will give you a
sustained few thousand writes per second, depending on how many
indexes you've created on the collection. Even writing JSON blobs to
any traditional database works surprisingly well for most uses,
especially if you have it write to a few key-value columns for quick
indexing.
In the near-term, as I talked about at the workshop, I'll be
announcing an official ELSA release early next week which will read
syslog and handle grepping, basic reporting, and alerting for you from
a web interface. (I didn't get to cover alerting in the talk, but
it's fully integrated as well. There's also a CLI interface I didn't
cover, so you can use it like bro-cut.