From mccreary at ucar.edu Mon Feb 16 22:34:00 2009 From: mccreary at ucar.edu (Sean McCreary) Date: Tue, 17 Feb 2009 06:34:00 +0000 Subject: [Bro] broclient and NOTICE() Message-ID: <499A5A58.1010104@ucar.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 From robin at icir.org Tue Feb 17 13:37:03 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 17 Feb 2009 13:37:03 -0800 Subject: [Bro] broclient and NOTICE() In-Reply-To: <499A5A58.1010104@ucar.edu> References: <499A5A58.1010104@ucar.edu> Message-ID: <20090217213703.GI861@icir.org> On Tue, Feb 17, 2009 at 06:34 +0000, you wrote: > > 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 Thanks for reporting this, there's already a ticket for it: http://tracker.icir.org/bro/ticket/65 I've just added a patch to the ticket, which I hope will fix the crash. It will however still report the run-time error. The underlying problem is that the function get_event_peer() tries to get information about the peer it received the event from, the connection to that peer however has already terminated so that the information isn't there anymore. That's a race-condition which is generally hard to avoid as Bro's event processing is decoupled from when an event is raised/received. One way to work-around such race conditions is sending explicit ack events that only terminate a connection once received, making sure that all important events have already been processed. bro-client however can't do that. Let me know if the patch works for you (it's against trunk but should also work with 1.4). Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From trostycp at hotmail.com Wed Feb 18 15:14:09 2009 From: trostycp at hotmail.com (Ryan Trost) Date: Wed, 18 Feb 2009 18:14:09 -0500 Subject: [Bro] A plead for help on a chapter re: Snort and Bro Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090218/4a423a26/attachment.html From mccreary at ucar.edu Wed Feb 18 17:21:56 2009 From: mccreary at ucar.edu (Sean McCreary) Date: Wed, 18 Feb 2009 18:21:56 -0700 Subject: [Bro] broclient and NOTICE() In-Reply-To: <20090217213703.GI861@icir.org> References: <499A5A58.1010104@ucar.edu> <20090217213703.GI861@icir.org> Message-ID: <499CB434.5020309@ucar.edu> Robin Sommer wrote: > On Tue, Feb 17, 2009 at 06:34 +0000, you wrote: > >>> 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 > > Thanks for reporting this, there's already a ticket for it: > http://tracker.icir.org/bro/ticket/65 > > I've just added a patch to the ticket, which I hope will fix the > crash. It will however still report the run-time error. The > underlying problem is that the function get_event_peer() tries to > get information about the peer it received the event from, the > connection to that peer however has already terminated so that the > information isn't there anymore. That's a race-condition which is > generally hard to avoid as Bro's event processing is decoupled from > when an event is raised/received. > > One way to work-around such race conditions is sending explicit ack > events that only terminate a connection once received, making sure > that all important events have already been processed. bro-client > however can't do that. > > Let me know if the patch works for you (it's against trunk but > should also work with 1.4). > > Robin Thanks for the patch! I applied it against bro.bif in v1.4, and it works as expected. When the connection has already terminated it reports the run-time error, but bro no longer crashes. From robin at icir.org Thu Feb 19 11:38:10 2009 From: robin at icir.org (Robin Sommer) Date: Thu, 19 Feb 2009 11:38:10 -0800 Subject: [Bro] broclient and NOTICE() In-Reply-To: <499CB434.5020309@ucar.edu> References: <499A5A58.1010104@ucar.edu> <20090217213703.GI861@icir.org> <499CB434.5020309@ucar.edu> Message-ID: <20090219193810.GG11993@icir.org> On Wed, Feb 18, 2009 at 18:21 -0700, you wrote: > Thanks for the patch! I applied it against bro.bif in v1.4, and it Thanks for testing, I've schedulued it for integration into the next relase. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From dalbrech at illinois.edu Wed Feb 25 12:26:59 2009 From: dalbrech at illinois.edu (dalbrech at illinois.edu) Date: Wed, 25 Feb 2009 14:26:59 -0600 (CST) Subject: [Bro] A more parallel Bro Message-ID: <20090225142659.BXZ56102@expms4.cites.uiuc.edu> 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 at illinois.edu From robin at icir.org Wed Feb 25 14:54:45 2009 From: robin at icir.org (Robin Sommer) Date: Wed, 25 Feb 2009 14:54:45 -0800 Subject: [Bro] A more parallel Bro In-Reply-To: <20090225142659.BXZ56102@expms4.cites.uiuc.edu> References: <20090225142659.BXZ56102@expms4.cites.uiuc.edu> Message-ID: <20090225225445.GA69669@icir.org> On Wed, Feb 25, 2009 at 14:26 -0600, dalbrech at illinois.edu wrote: > I've been doing some performance profiling on Bro. Interesting! Do you have any results you could share? > I'm wondering what the ICSI folks' position is on threads vs. clustering. In short: we consider them orthogonal and are pursuing both. :-) To elaborate a bit: The cluster is the approach that can provide significantly increased performance right now; ignoring a few implementation glitches we still need to sort out, it's working and ready to use[1]. The cluster is also an approach that will work long-term: there will always be limits to what a single box can do (multi-core or not) and the cluster offers the capability to go beyond that. That said, we are in parallel (no pun intended :) working on a multi-threaded Bro implementation. While we have already made quite a bit of progress on that, that will however still take a bit to get into any kind of usable state; we need to restructure Bro internally quite a bit to exploit its concurrency potential. Once finished though, we expect Bro's performance to scale pretty well with the number of available cores (not considering other aspects of the hardware which might turn into bottlenecks at some point). The Sarnoff paper has some of the basic ideas for the multi-threaded Bro, and there'll be an extended journal version of that coming out soon with more details on the parallel execution model (let me know if you'd to like to get a draft). Does that answer your question? If you have any particular thoughts on either clustering or the multi-threaded Bro, I'd be happy to hear them. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Wed Feb 25 15:57:45 2009 From: robin at icir.org (Robin Sommer) Date: Wed, 25 Feb 2009 15:57:45 -0800 Subject: [Bro] A more parallel Bro In-Reply-To: <20090225225445.GA69669@icir.org> References: <20090225142659.BXZ56102@expms4.cites.uiuc.edu> <20090225225445.GA69669@icir.org> Message-ID: <20090225235745.GC69669@icir.org> On Wed, Feb 25, 2009 at 14:54 -0800, I wrote: > ready to use[1] (There's actually no footnote there. :-) Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org