Ladies and Gentlemen (esp. Robin),
I've been doing some performance profiling on Bro. In the course of my work, I
noticed its main event loop is single-threaded. I went back to the original
1998 USENIX paper on Bro, and found the following in the "Implementation
Issues" section:
"Since event handling lies at the heart of the system, it is natural to consider a
multi-threaded design, with one thread per active event handler. We have so
far resisted this approach, because of concerns that it could lead to subtle race
conditions in Bro scripts...We may yet adopt a multi-threaded design. A more
likely possibility is evolving Bro towards a distributed design, in which loosely-
coupled, multiple Bro's on separate processors monitor the same network link.
Each Bro would watch a different type of traffic (e.g., HTTP or NFS) and
communicate only at a high level, to convey current threat information."
A review of more recent literature suggests interest in exploiting the inherent
parallelism of event handling (e.g. the NIDS cluster paper from RAID '07, and
the Sarnoff '07 work) -- I'm wondering what the ICSI folks' position is on
threads vs. clustering.
Best,
David A.
--
David R. Albrecht
Graduate Research Assistant, Hatswitch Group
U. Illinois Urbana-Champaign
(312) 445-0883
dalbrech(a)illinois.edu
I'm having trouble feeding events to bro v1.4 using broclient. I built
broclient using the source in aux/broccoli/contrib, and configured bro
to listen for remote connections. This setup will sometime crash with
the run-time error messages like this:
> 1234849021.842185 run-time error: peer 10000 does not exist
> 1234849021.842185 /usr/local/bro/share/bro/notice.bro, line 261 (n$src_peer): internal error: field value missing
I dug a little in the source, and it seems like n$src_peer should be set
automatically by get_event_peer(), and internal function in the event
engine. Before digging deeper in the bro source, I thought I'd ask if
anyone has seen this before, or if I'm doing something obviously wrong.
Here's the relevant bro code that causes the error:
> ## Track ssh logins using info from syslog
> @load listen-clear
> @load remote
>
> redef listen_if_clear = 127.0.0.1;
> redef Remote::destinations += {
> ["syslog"] = [$host = 127.0.0.1, $events = /.*/, $connect=F],
> };
>
> redef enum Notice += { NewSSHConn };
> global ssh_conns: set[string, addr, string, string] &persistent;
>
> redef notice_policy += {
> # Email when a user logs in from a new client or using
> # a different authenticator
> [$pred(n: notice_info) =
> {
> return n$note == NewSSHConn;
> },
> $result = NOTICE_EMAIL,
> $priority = 1],
> };
>
> event ssh_login(server:string, authtype:string, user:string, client:addr) {
> if ( [server, client, user, authtype] !in ssh_conns ) {
> add ssh_conns[server, client, user, authtype];
> NOTICE([$note=NewSSHConn, $src=client,
> $msg=fmt("New SSH connection %s->%s:%s@%s",
> client, user, authtype, server)]);
> };
> };
I can trigger the error with the following command:
> echo "ssh_login string=server string=authtype string=user addr=1.2.3.4" | /usr/local/bro/bin/broclient
Bro Usergroup,
I'm in the midst of finishing up a book for Addison Wesley revolving around current Intrusion Detection avenues. One of the chapters was submitted by a Technical Contributor who works closely with Snort (i.e. for Sourcefire). After speaking with Robin Sommers and Vern Paxson the author's assessments of Bro are off and the chapter needs some TLC.
Unfortunately as my deadline (March 7) is drawing closer I'm having to focus my attention on other chapters. But being so close to the deadline I'm unable to cut the chapter altogether.
Is there any Bro enthusiasts that would consider lending a helping hand? You will be compensated for your time (as I understand time is money...), as well as be praised in the Acknowledgement section of the Preface!
Please contact me if your interested.
Thanks,
Ryan
