From navdeepsuri13 at gmail.com Sat Aug 1 06:37:47 2009 From: navdeepsuri13 at gmail.com (Navdeep Singh) Date: Sat, 1 Aug 2009 19:07:47 +0530 Subject: [Bro] Record problem... Message-ID: Hi I am new to bro but really interested working in bro. I have already started the work. I am encountering a problem now. It is about records. Let me explain wid the help of example: type con: record { orig_h: addr; orig_p: port; resp_h: addr; resp_p: port; }; type con2: record { orig_h: addr; orig_p: port; resp_h: addr; resp_p: port; num_notices: count &optional; }; function fun() { local id: con; local id2: con2; id2 = id; } This is giving segmentation fault , the statement id2=id. But in documentation of bro , they have said this is absolutely right. Please explain this. Regards Navdeep -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090801/8dab0c32/attachment.html From robin at icir.org Mon Aug 3 09:02:42 2009 From: robin at icir.org (Robin Sommer) Date: Mon, 3 Aug 2009 09:02:42 -0700 Subject: [Bro] Record problem... In-Reply-To: References: Message-ID: <20090803160242.GB43845@icir.org> On Sat, Aug 01, 2009 at 19:07 +0530, you wrote: > local id: con; > local id2: con2; > id2 = id; No, this assignment doesn't work because the two records have different types; that's not defined. Bro shouldn't crash however but better report an error at parse time. Could you file a bug report with the Bro tracker for that? Thanks. > documentation of bro , they have said this is absolutely right. Please That surprises me. Can you point to the location where the docs say such an assignment is ok? Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From kosinovsky1 at llnl.gov Mon Aug 3 17:50:12 2009 From: kosinovsky1 at llnl.gov (Greg Kosinovsky) Date: Mon, 03 Aug 2009 17:50:12 -0700 Subject: [Bro] http analyzer Message-ID: <80955b$22k19o@smtp.llnl.gov> Hi. I am trying to run bro with http.bro policy file against a pcap file. I get an empty http.log file. However, conn.log contains plenty of http records. All I am trying to get is a summary of http transactions (as summerized in the "http analyzer" section of the manual). Am I using the wrong policy file? The conn.log content is as follows, Thank you: 1248823461.379857 0.000522 134.9.214.98 198.128.246.10 https 59371 443 tcp 0 0 SF X 1248823461.380007 0.001128 134.9.214.98 74.125.19.103 http 59373 80 tcp 0 0 SF X 1248823461.380081 0.001055 134.9.214.98 74.125.19.103 http 59374 80 tcp 0 0 SF X 1248823461.380165 0.001008 134.9.214.98 74.125.19.139 http 59375 80 tcp 0 0 SF X 1248823470.597261 18.050017 134.9.214.98 198.128.246.160 https 59380 443 tcp 1075 39610 SF X 1248823470.597119 18.050392 134.9.214.98 198.128.246.160 https 59379 443 tcp 1075 36721 SF X 1248823457.013757 68.607945 134.9.214.30 255.255.255.255 ntp 1230 123 udp 240 ? S0 X [5/0] 1248823458.148163 68.386845 134.9.216.231 255.255.255.255 ntp 1230 123 udp 240 ? S0 X [5/0] 1248823469.374292 51.287737 134.9.214.232 255.255.255.255 ntp 1230 123 udp 192 ? S0 X [4/0] 1248823465.334545 ? 134.9.214.98 198.128.246.160 http 59377 80 tcp ? ? S1 X 1248823521.726360 ? 134.9.214.98 208.117.252.89 http 59395 80 tcp ? ? S1 X 1248823492.193498 15.026019 134.9.214.98 198.128.249.4 http 59383 80 tcp 1085 61616 S3 X 1248823492.193864 15.025624 134.9.214.98 198.128.249.4 http 59384 80 tcp 1034 8008 S3 X 1248823501.794443 ? 134.9.214.98 74.125.19.100 http 59387 80 tcp ? ? S1 X 1248823498.532173 ? 134.9.214.98 74.125.19.103 http 59385 80 tcp ? ? S1 X 1248823504.582292 ? 134.9.214.98 216.34.181.60 http 59392 80 tcp ? ? S1 X 1248823498.617937 ? 134.9.214.98 74.125.19.139 http 59386 80 tcp ? ? S1 X 1248823504.575446 ? 134.9.214.98 209.87.252.214 http 59391 80 tcp ? ? S1 X 1248823504.574710 ? 134.9.214.98 209.87.252.214 http 59389 80 tcp ? ? S1 X 1248823504.575088 ? 134.9.214.98 209.87.252.214 http 59390 80 tcp ? ? S1 X 1248823528.360665 0.000069 134.9.214.98 128.115.3.5 other 59368 3268 tcp 0 0 SF X 1248823492.186376 15.032956 134.9.214.98 198.128.249.4 http 59382 80 tcp 1398 19752 S3 X 1248823504.390518 ? 134.9.214.98 209.87.252.214 http 59388 80 tcp ? ? S1 X 1248823512.268070 ? 134.9.214.98 138.23.169.15 http 59393 80 tcp ? ? S1 X 1248823521.660641 ? 134.9.214.98 74.125.19.138 http 59394 80 tcp ? ? S1 X 1248823465.442010 ? 134.9.214.98 198.128.246.160 https 59378 443 tcp ? ? S1 X 1248823491.675365 15.613805 134.9.214.98 198.128.249.4 http 59381 80 tcp 2093 19369 S3 X -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090803/1635428f/attachment.html From navdeepsuri13 at gmail.com Mon Aug 3 23:14:02 2009 From: navdeepsuri13 at gmail.com (Navdeep Singh) Date: Tue, 4 Aug 2009 11:44:02 +0530 Subject: [Bro] Record problem... In-Reply-To: References: Message-ID: Hi Robin Thanks for your help. I have got my mistake and what I wanted to do is done but now I come to you point that local id: con; local id2: con2; id2 = id; is not right but it is "WORKING". Actaully read the following line is documentaion in reference manual under *Record Assignment*: In order to produce a *deep* copy, use the clone operator copy(). For more details, see Expressions. *You can also assign to a record another record that has fields with the same names and types, even if they come in a different order*. So I have noticed that even if *record types are different* but the *filed names* and *types* inside these records are *same* then also *we can assign *them to each other. copy paste the following and see the output: type con: record { orig_h: addr; }; type con2: record { orig_h: addr; }; function fun() { local id: con; local id2: con2; id=id2; } fun(); Regards Navdeep On Sat, Aug 1, 2009 at 7:07 PM, Navdeep Singh wrote: > Hi > I am new to bro but really interested working in bro. I have already > started the work. I am encountering a problem now. > It is about records. Let me explain wid the help of example: > > type con: record > { > orig_h: addr; > orig_p: port; > resp_h: addr; > resp_p: port; > }; > > type con2: record > { > > orig_h: addr; > orig_p: port; > resp_h: addr; > resp_p: port; > num_notices: count &optional; > }; > > function fun() > { > local id: con; > local id2: con2; > id2 = id; > } > > This is giving segmentation fault , the statement id2=id. But in > documentation of bro , they have said this is absolutely right. Please > explain this. > > > Regards > Navdeep -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090804/f0037030/attachment.html From robin at icir.org Tue Aug 4 11:25:17 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 4 Aug 2009 11:25:17 -0700 Subject: [Bro] http analyzer In-Reply-To: <80955b$22k19o@smtp.llnl.gov> References: <80955b$22k19o@smtp.llnl.gov> Message-ID: <20090804182517.GC86467@icir.org> On Mon, Aug 03, 2009 at 17:50 -0700, you wrote: > I am trying to run bro with http.bro policy file against a pcap file. You need http-request and http-reply (and potentially some more of the other http-*). The HTTP analysis is split across a set of scripts and while http.bro implements parts of that, it itself does not activate the analysis. 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 Tue Aug 4 11:50:58 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 4 Aug 2009 11:50:58 -0700 Subject: [Bro] Record problem... In-Reply-To: References: Message-ID: <20090804185058.GF86467@icir.org> On Tue, Aug 04, 2009 at 11:44 +0530, you wrote: > So I have noticed that even if *record types are different* but the *filed > names* and *types* inside these records are *same* then also *we can assign > *them to each other. Wow! In all my years with Bro, I have totally missed this little gem. :-) Thanks for pointing it out. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From navdeepsuri13 at gmail.com Wed Aug 5 22:22:30 2009 From: navdeepsuri13 at gmail.com (Navdeep Singh) Date: Thu, 6 Aug 2009 10:52:30 +0530 Subject: [Bro] default function not get called in Table ... Message-ID: Hi everyone I have a got a problem. I want to call a function called world but it is throwing the following error: line 1: error: unknown identifier world, at or near "world" global a: table[count] of string &default = world; a[1] = "navdeep"; a[2] = "singh"; print a[2]; function world(): string { print "hello world"; } Please resolve the problem. Regards Navdeep -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090806/295ea137/attachment.html From hall.692 at osu.edu Thu Aug 6 04:39:58 2009 From: hall.692 at osu.edu (Seth Hall) Date: Thu, 6 Aug 2009 07:39:58 -0400 Subject: [Bro] default function not get called in Table ... In-Reply-To: References: Message-ID: On Aug 6, 2009, at 1:22 AM, Navdeep Singh wrote: > Hi everyone > > I have a got a problem. I want to call a function called world but > it is throwing the following error: > > line 1: error: unknown identifier world, at or near "world" The main problem you're running into here is that you're defining the world function after you're trying to use it. When you use functions as default values, there is an argument passed to the function that is the value of the index and you forgot to return the string value from the world function. Lastly, when you call most code it needs to be inside of an event handler, but you can wrap the code inside of a bro_init event handler which executes once Bro has completed it's initialization. I'll include a fixed version of your test script. function world(i: count): string { return fmt("hello world - index is %d", i); } global a: table[count] of string &default=world; event bro_init() { a[1] = "navdeep"; a[2] = "singh"; print a[2]; print a[3]; } ----script output---- $ ./src/bro test5 singh hello world - index is 3 .Seth --- Seth Hall Network Security - Office of the CIO The Ohio State University Phone: 614-292-9721 From aashish at uiuc.edu Mon Aug 10 15:06:12 2009 From: aashish at uiuc.edu (Aashish Sharma) Date: Mon, 10 Aug 2009 17:06:12 -0500 Subject: [Bro] Bro crashing- Val::CONST_ACCESSOR Message-ID: <20090810220612.GB19668@uiuc.edu> Hello Bro Team: I am encountering the following error which is crashing bro ( Version 1.4): 1249941643.081538 (127.0.0.2): bad tag in Val::CONST_ACCESSOR (types/string) I can provide you more information as required. Any thoughts? Thanks Aashish Sharma From robin at icir.org Mon Aug 10 15:45:32 2009 From: robin at icir.org (Robin Sommer) Date: Mon, 10 Aug 2009 15:45:32 -0700 Subject: [Bro] Bro crashing- Val::CONST_ACCESSOR In-Reply-To: <20090810220612.GB19668@uiuc.edu> References: <20090810220612.GB19668@uiuc.edu> Message-ID: <20090810224532.GC74046@icir.org> On Mon, Aug 10, 2009 at 17:06 -0500, Aashish Sharma wrote: > 1249941643.081538 (127.0.0.2): bad tag in Val::CONST_ACCESSOR (types/string) That usually indicates some kind of type mismatch in a Bro script. Ideal would be a small trace triggering the problem ... Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From sychan at lbl.gov Wed Aug 12 11:47:06 2009 From: sychan at lbl.gov (Stephen Chan) Date: Wed, 12 Aug 2009 11:47:06 -0700 Subject: [Bro] Requesting event_notice ad event_alarm events over broccoli Message-ID: <4A830E2A.6020202@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to collect event_notice and event_alarm events from a bro 1.4 instance via broccoli and seeing some odd behavior, and was wondering if its something others have seen (and figured out). What happens is the client connects, and requests those events, and the server logs the connection and the request for events. Everything looks fine, except that nothing comes through, and the bro child/communicatons process starts to bloat up rapidly. Eventually the process becomes huge and seg faults, leaving the parent bro processing humming along happily. The entire time, not a single event arrives at the client. It almost looks as if the events are sent over to the child process where they queue up for delivery, yet nothing goes through. I saw that there is the suppress_notice_action flag which is set to F, but the description sounds like it suppressed events arriving from a remotero. I am able to use the same client, and collect connection_finished events, with no sign of the bro child process bloating up and dying, so it seems to be something related to the event_notice and event_alarm events. The NoticeAction and notice_info types passed for those events are more complex than the connection_finished params, would the optional fields and enumerated types in NoticeAction and notice_info cause problems for marshalling and sending? Thanks, Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqDDioACgkQcVd2YI1BWAiMrgCeNSeMQ0H0fPurC+iy4yY3+O1r MbEAn3+i9gBi5m2iJzyoNwlcKIOJgZlW =uNHe -----END PGP SIGNATURE----- From christian at whoop.org Thu Aug 13 07:19:54 2009 From: christian at whoop.org (Christian Kreibich) Date: Thu, 13 Aug 2009 07:19:54 -0700 Subject: [Bro] Requesting event_notice ad event_alarm events over broccoli In-Reply-To: <4A830E2A.6020202@lbl.gov> References: <4A830E2A.6020202@lbl.gov> Message-ID: <1250173194.4497.22.camel@localhost.localdomain> Hi Steve, Thanks for the feedback. Could you provide a bit more detail about the setup? In particular, what codebase are you using, and what are the connection flags on the Broccoli side? -- Cheers, Christian From robin at icir.org Thu Aug 13 10:21:46 2009 From: robin at icir.org (Robin Sommer) Date: Thu, 13 Aug 2009 10:21:46 -0700 Subject: [Bro] Requesting event_notice ad event_alarm events over broccoli In-Reply-To: <4A830E2A.6020202@lbl.gov> References: <4A830E2A.6020202@lbl.gov> Message-ID: <20090813172146.GC28773@icir.org> On Wed, Aug 12, 2009 at 11:47 -0700, you wrote: > I'm trying to collect event_notice and event_alarm events from a (I suppose you mean notice_action and notice_alarm?) > humming along happily. The entire time, not a single event arrives at > the client. That's weird. I don't have an immediate idea why you see that; the cluster is sending notice_action events and that's working fine. > saw that there is the suppress_notice_action flag which is set to F, Right, that option shouldn't have any impact on this > would the optional fields and enumerated types in NoticeAction and > notice_info cause problems for marshalling and sending? They shouldn't. Generally, all script-level variables can be transmitted. If not it's a bug ... : There are two things which could help tracking this down: if you could find like a minimal configuration/setup which demonstrates the problem, that'd be great (always a bit tricky when communication is involved...). And you could compile with --enable-debug and then run with "-B comm", that will log some stuff into debug.log which might help (that file quickly gets huge though). Robin P.S.: Which Bro version are you using? -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From sychan at lbl.gov Thu Aug 13 10:25:10 2009 From: sychan at lbl.gov (Stephen Chan) Date: Thu, 13 Aug 2009 10:25:10 -0700 Subject: [Bro] Requesting event_notice ad event_alarm events over broccoli In-Reply-To: <1250173194.4497.22.camel@localhost.localdomain> References: <4A830E2A.6020202@lbl.gov> <1250173194.4497.22.camel@localhost.localdomain> Message-ID: <4A844C76.8000502@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian, We're using Bro 1.4 on both client and server sides. Our 1.4 source tree looks like it was generated on March 18, 2009, so I would expect that it was current as of that date (Scott can confirm). Here's the code for acquiring the connection handle: if (! (bc = bro_conn_new((struct in_addr*) host->h_addr_list[0], htons(conf.port), BRO_CFLAG_DONTCACHE))) { fprintf(stderr,"Could not obtain connection handle to %s:%d\n", conf.hostname, conf.port); exit(1); } So the only flag is the BRO_CFLAG_DONTCACHE I'm using the compact argument style handler, and converting the incoming parameters into perl variables and handing them off to a perl function for processing. I don't think the c->perl interface is an issue because the client never seems to receive the events. Steve Christian Kreibich wrote: > Hi Steve, > > Thanks for the feedback. Could you provide a bit more detail about > the setup? In particular, what codebase are you using, and what are > the connection flags on the Broccoli side? > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqETHYACgkQcVd2YI1BWAiVBACcCysU7ffL6k8nDXQGzovglVXy qe4Anj+lB+dW2aXMxVqxj7CzgU54HS+H =4kWX -----END PGP SIGNATURE----- From sychan at lbl.gov Thu Aug 13 10:51:24 2009 From: sychan at lbl.gov (Stephen Chan) Date: Thu, 13 Aug 2009 10:51:24 -0700 Subject: [Bro] Requesting event_notice ad event_alarm events over broccoli In-Reply-To: <20090813172146.GC28773@icir.org> References: <4A830E2A.6020202@lbl.gov> <20090813172146.GC28773@icir.org> Message-ID: <4A84529C.1090702@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robin Sommer wrote: > On Wed, Aug 12, 2009 at 11:47 -0700, you wrote: > >> I'm trying to collect event_notice and event_alarm events from a > > (I suppose you mean notice_action and notice_alarm?) > Yes, that's what I meant to write, even if I didn't! :-) > > There are two things which could help tracking this down: if you > could find like a minimal configuration/setup which demonstrates > the problem, that'd be great (always a bit tricky when > communication is involved...). And you could compile with > --enable-debug and then run with "-B comm", that will log some > stuff into debug.log which might help (that file quickly gets huge > though). > I will try to get this today. I expected that the notice_action stuff was being used for the bro cluster, so I'm thinking it is just something dumb and/or obvious that I'm missing. > > P.S.: Which Bro version are you using? > Its version 1.4 as of 3/18/09. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqEUpwACgkQcVd2YI1BWAjw+wCgkOPyF/qozD+LPMkDgE6Q8/5s LzEAniSRZXcGuEO4hrdDowBqFMW6bdbY =zH60 -----END PGP SIGNATURE----- From robin at icir.org Thu Aug 13 11:04:26 2009 From: robin at icir.org (Robin Sommer) Date: Thu, 13 Aug 2009 11:04:26 -0700 Subject: [Bro] Requesting event_notice ad event_alarm events over broccoli In-Reply-To: <4A84529C.1090702@lbl.gov> References: <4A830E2A.6020202@lbl.gov> <20090813172146.GC28773@icir.org> <4A84529C.1090702@lbl.gov> Message-ID: <20090813180426.GH28773@icir.org> On Thu, Aug 13, 2009 at 10:51 -0700, Stephen Chan wrote: > I will try to get this today. I expected that the notice_action > stuff was being used for the bro cluster, so I'm thinking it is just > something dumb and/or obvious that I'm missing. Actually, I'm realizing that I mentally skipped the "Broccoli" part of your original mail; I had a pure Bro-to-Bro setting in mind when I replied, and that's what the cluster is using (the cluster doesn't use Broccoli for sending the notice_* events). So, if the problem would be on the Broccoli side, that could explain why we haven't seen it so far. 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 Thu Aug 13 14:32:37 2009 From: robin at icir.org (Robin Sommer) Date: Thu, 13 Aug 2009 14:32:37 -0700 Subject: [Bro] Save the date: Another Bro Workshop In-Reply-To: <20090727173041.GE85031@icir.org> References: <20090727173041.GE85031@icir.org> Message-ID: <20090813213237.GB41439@icir.org> The workshop registration is now open at http://www.regonline.com/BroWrkshp_10_09 Robin On Mon, Jul 27, 2009 at 10:30 -0700, I wrote: > > Bro Workshop 2009, the 2nd. > =========================== > > The Bro team and the Lawrence Berkeley National Lab are pleased to > announce a further "Bro Workshop", a 2.5-day Bro training event that > will take place in Berkeley, CA, on October 13-15, 2009. > > The workshop is primarily targeted at site security personnel > wishing to learn more about how Bro works, how to use its scripting > language and how to generally customize the system based on a site's > local policy. > > Similar to previous workshops, the agenda will be an informal mix of > tutorial-style presentations and hands-on lab sessions. No prior > knowledge about using Bro is assumed though attendees should be > familiar with Unix shell usage as well as with typical networking > tools like tcpdump and Wireshark. > > All participants are expected to bring a Unix-based (Linux, Mac OS X, > FreeBSD) laptop with a working Bro configuration. We will provide > sample trace files to work with. > > This workshop will again be hosted by the Lawrence Berkeley National > Lab, and it will be located at the Hotel Durant in Berkeley. We will > soon provide a web site with more detailed registration and location > information. To facilitate a productive lab environment, the number > of attendees will be limited to 30 people. A registration fee of > $125 will be charged. > > We also expect to have time for 2-3 case-study presentations from > people using Bro in their environments. If you have something you > would like to talk about, please send me a mail. > > Looking forward to a great workshop, > > 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 Fri Aug 21 16:20:43 2009 From: robin at icir.org (Robin Sommer) Date: Fri, 21 Aug 2009 16:20:43 -0700 Subject: [Bro] Bro 1.5 sneak preview In-Reply-To: <200907081843.n68IheEo014439@envoy.icir.org> References: <200907081843.n68IheEo014439@envoy.icir.org> Message-ID: <20090821232043.GL8795@icir.org> We are gearing up for a Bro 1.5 release and would like to solicit some testing of the current codebase to weed out any potentially remaining issues ahead of time. This applies in particular to a new installation/configuration/maintenance framework called "BroControl", which will ship as part of Bro 1.5, replacing the old BroLite system that has already been deprecated for a while now. BroControl allows for easy operation of a Bro setup, both for standard single-system installations as well as in cluster setups. It includes functionality for configuration, log archival, mail notifications, dynamic updates, and general monitoring. We'd much appreciate if folks could give our current development version of Bro 1.5 and BroControl a try. In particular, trying BroControl in both standalone and cluster operation on different operating systems would be very helpful. So far, FreeBSD has seen most testing, MacOS quite a bit, Linux only a little bit. To get a copy of the current code base, use SVN: svn checkout http://svn.icir.org/bro/trunk/bro You need to run "./autogen.sh" after the checkout before proceeding with the normal ./configure. The default installation process should work as usual. For using BroControl, see its documentation at http://svn.icir.org/bro/trunk/bro/aux/broctl/README.html If you find any problems, or something important missing, please file a ticket with the Bro issue tracker at http://tracker.icir.org/bro When filing a ticket regarding BroControl, please make sure to set the ticket's component to "BroControl". For folks running a previous version of the "cluster shell" from my work-branch: BroControl is more or less a rebranding of the shell and supersedes all previous versions. See below for update instructions. Finally, if you give this version try, please drop me a quick mail even if things are going smoothly for you so that we can keep track the testing this version has seen. Thanks a lot in advance, Robin --------- Update instruction --------------------------------------------- For those folks already running a cluster installation using my work branch updating to trunk with broctl should be easy. Just follow these steps: 1. Backup the following files: - All *.cfg files found in $prefix/etc - The current set of logs in $prefix/logs - Your site policies if they are installed somewhere under $prefix 2. Delete $prefix on all nodes (or at least anything Bro related in there). 3. Follow the installation instructions in http://svn.icir.org/bro/trunk/bro/aux/broctl/README.html Skip the steps involving any of the *.cfg files. Make sure to update the cron entry to use "broctl" instead of "cluster". 4. Copy the saved files back into place: - Copy all *.cfg back into $prefix/etc. Rename "cluster.cfg" to "broctl.cfg". - Copy the logs back into $prefix/logs. - Copy your site policies back. The new default location for them is $prefix/share/bro/policy/local. Copy them there or to whatever path your broctl.cfg specifies. 6. Run "broctl install", then "broctl check" to make sure everythign works as expected. Generally, everything should be working as before. The main differences to the old cluster shell are (1) the executable is now called "broctl" instead of "cluster"; and (2) "broctl install" does no longer copy any files from the Bro distribution directory into the installation; you need to rerun "make install-broctl" if anything inside the Bro distribution has changed (like after an "svn update"). -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org