From robin at icir.org Mon May 1 07:57:57 2017 From: robin at icir.org (Robin Sommer) Date: Mon, 1 May 2017 07:57:57 -0700 Subject: [Bro-Dev] can I send an opaque of bloomfilter over Cluster::manager2worker_event ? In-Reply-To: <20170429005548.GT10784@mac-822.local> References: <20170429005548.GT10784@mac-822.local> Message-ID: <20170501145757.GC48987@icir.org> On Fri, Apr 28, 2017 at 17:55 -0700, you wrote: > 1493427133.170419 Reporter::ERROR incompatible hashers in BasicBloomFilter merge (empty) - > Not sure if the error is because an opaque of bloomfilter cannot be > sent over worker2manager_events and manager2worker_events or if I am > doing something not quite right. Bloom filters should work over communication. What's the code for the two sides? The error messages sound like these are filters of different types. Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From johanna at icir.org Mon May 1 08:20:19 2017 From: johanna at icir.org (Johanna Amann) Date: Mon, 01 May 2017 08:20:19 -0700 Subject: [Bro-Dev] can I send an opaque of bloomfilter over Cluster::manager2worker_event ? In-Reply-To: <20170501145757.GC48987@icir.org> References: <20170429005548.GT10784@mac-822.local> <20170501145757.GC48987@icir.org> Message-ID: >> 1493427133.170419 Reporter::ERROR incompatible hashers in >> BasicBloomFilter merge (empty) - > >> Not sure if the error is because an opaque of bloomfilter cannot be >> sent over worker2manager_events and manager2worker_events or if I am >> doing something not quite right. > > Bloom filters should work over communication. What's the code for the > two sides? The error messages sound like these are filters of > different types. Actually - I am not sure if we ever implemented consistent hashing over the cluster; if I remember it correctly, the bloom filters need to use the same seed for the hash-functions in all cluster nodes to be mergeable. That might be the reason for this to fail (and the error message also seems to indicate this). Johanna From robin at icir.org Mon May 1 08:39:03 2017 From: robin at icir.org (Robin Sommer) Date: Mon, 1 May 2017 08:39:03 -0700 Subject: [Bro-Dev] can I send an opaque of bloomfilter over Cluster::manager2worker_event ? In-Reply-To: References: <20170429005548.GT10784@mac-822.local> <20170501145757.GC48987@icir.org> Message-ID: <20170501153903.GK48987@icir.org> On Mon, May 01, 2017 at 08:20 -0700, you wrote: > Actually - I am not sure if we ever implemented consistent hashing over the > cluster; Ah, good point, we did implement that, but it needs to be configured: ## Seed for hashes computed internally for probabilistic data structures. Using ## the same value here will make the hashes compatible between independent Bro q## instances. If left unset, Bro will use a temporary local seed. const global_hash_seed: string = "" &redef; Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From asharma at lbl.gov Mon May 1 11:41:30 2017 From: asharma at lbl.gov (Aashish Sharma) Date: Mon, 1 May 2017 11:41:30 -0700 Subject: [Bro-Dev] can I send an opaque of bloomfilter over Cluster::manager2worker_event ? In-Reply-To: <20170501153903.GK48987@icir.org> References: <20170429005548.GT10784@mac-822.local> <20170501145757.GC48987@icir.org> <20170501153903.GK48987@icir.org> Message-ID: <20170501184128.GD54952@mac-822.local> > const global_hash_seed: string = "" &redef; Yes, with setting of global_hash_seed, bloomfilter movement across workers is working fine and as expected, I see from initial tests. While we are on this thread, is the following good or there is a better way to copy/merge bloomfilter once its sent to workers: @if (( Cluster::is_enabled() && Cluster::local_node_type() != Cluster::MANAGER ) || !Cluster::is_enabled()) event Blacklist::m_w_add_bloom(val: opaque of bloomfilter) { blacklistbloom=bloomfilter_merge(val, val); } @endif I figured merging same bloom to itself won't make a difference, I primarily want to copy it to blacklistbloom. Aashish On Mon, May 01, 2017 at 08:39:03AM -0700, Robin Sommer wrote: > > > On Mon, May 01, 2017 at 08:20 -0700, you wrote: > > > Actually - I am not sure if we ever implemented consistent hashing over the > > cluster; > > Ah, good point, we did implement that, but it needs to be configured: > > ## Seed for hashes computed internally for probabilistic data structures. Using > ## the same value here will make the hashes compatible between independent Bro > q## instances. If left unset, Bro will use a temporary local seed. > const global_hash_seed: string = "" &redef; > > Robin > > -- > Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From seth at corelight.com Mon May 1 12:24:13 2017 From: seth at corelight.com (Seth Hall) Date: Mon, 1 May 2017 15:24:13 -0400 Subject: [Bro-Dev] can I send an opaque of bloomfilter over Cluster::manager2worker_event ? In-Reply-To: <20170501184128.GD54952@mac-822.local> References: <20170429005548.GT10784@mac-822.local> <20170501145757.GC48987@icir.org> <20170501153903.GK48987@icir.org> <20170501184128.GD54952@mac-822.local> Message-ID: <8B2DF611-6FD8-47D0-B286-585D82CA52F5@corelight.com> > On May 1, 2017, at 2:41 PM, Aashish Sharma wrote: > > >> const global_hash_seed: string = "" &redef; > > Yes, with setting of global_hash_seed, bloomfilter movement across workers is working fine and as expected, I see from initial tests. Speaking of this, I think we still need to have broctl autogenerate a file with this configured to a random value when it starts up (if that file doesn't already exist). That way everyones cluster will end up with a random value that stays consistent across restarts. .Seth -- Seth Hall * Corelight, Inc * seth at corelight.com * www.corelight.com From vallentin at icir.org Mon May 1 14:05:18 2017 From: vallentin at icir.org (Matthias Vallentin) Date: Mon, 1 May 2017 14:05:18 -0700 Subject: [Bro-Dev] can I send an opaque of bloomfilter over Cluster::manager2worker_event ? In-Reply-To: <20170501184128.GD54952@mac-822.local> References: <20170429005548.GT10784@mac-822.local> <20170501145757.GC48987@icir.org> <20170501153903.GK48987@icir.org> <20170501184128.GD54952@mac-822.local> Message-ID: <20170501210518.GU67639@shogun.local> > I figured merging same bloom to itself won't make a difference, I > primarily want to copy it to blacklistbloom. That's correct behavioar. A bloomfilter merge is idempotent when executed in reflexive fashion (because it boils down to a bitwise OR of a bitvector with itself). Matthias From jdopheid at illinois.edu Wed May 3 09:07:26 2017 From: jdopheid at illinois.edu (Dopheide, Jeannette M) Date: Wed, 3 May 2017 16:07:26 +0000 Subject: [Bro-Dev] The Bro Project is looking for developers In-Reply-To: References: Message-ID: <02C758EC-03BD-4978-934F-AECE1C7E2BB3@illinois.edu> The Bro Project is looking for an exceptional engineer to join our core team of Bro developers. If you are interested in helping us advance Bro, please consider applying! We are looking for candidates who have demonstrated experience leading projects, excellent programming skills in C/C++ and Python, are comfortable at the Unix command line, and have solid knowledge of network technology. It is a plus if you have implemented network protocols before, been involved with large open-source projects, developed for distributed systems, or have a background in security operations. This is a full-time position with NCSA?s CyberSecurity and Networking Directorate in Urbana, IL. If you are interested, please send your application to info at bro.org (TXT or PDF format only please). Make sure to mention any relevant projects that you have worked on in the past, including your particular role. ------ Adam J. Slagell Director, Cybersecurity & Networking Division Chief Information Security Officer National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info "Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure." From mydevmail at gmx.de Mon May 8 05:55:25 2017 From: mydevmail at gmx.de (Dominique Krause Meier) Date: Mon, 8 May 2017 14:55:25 +0200 Subject: [Bro-Dev] Logging connections after specific daytime Message-ID: Hello, ? i'm currently tying to develop a script for a project scenario and i would like to know if there are some more efficient approaches and/or solutions for the current problem. The main task is defined as logging all connections and connection-attempts occuring after a certain daytime. At the moment i'm using the functions provided by the script located in base/protocols/conn/main.bro and the following events: - bro_init - bro_done - new_connection - connection_state_remove - content_gap //not sure about this one ? Now i got stuck with a few questions: 1. Are those events enough to track every connection being established after a certain daytime? Or do i need additional events? 2. Why does the ../conn/main.bro script fill the c$conn-attributes from Conn::Info (function set_conn()), if bro provides them automatically after an event is removed from memory? 3. If i do include other scripts (e.g. base/protocols/dns) why are the records still missing in a connection-object provided by the connection_state_remove()-event? I think it makes sense if there is a dns-event and the ssl-record is missing, but even if its a dns-event, there is still no dns-record with additional data about the connection. Am i missing something? Do i have to them by myself by using Bro-Functions? 4. Is it possible to determine how much data was transfered by a specific connection while it is still kept in memory? As an example: Connection was seen at a certain time and finished 10 seconds later. Is it possible to determine the send bytes or protocol 5 seconds after initiation? ? -- Dominique From jdopheid at illinois.edu Fri May 12 07:08:33 2017 From: jdopheid at illinois.edu (Dopheide, Jeannette M) Date: Fri, 12 May 2017 14:08:33 +0000 Subject: [Bro-Dev] The Bro Project is looking for developers Message-ID: <7D065D02-78F8-4EB5-9A1C-E3F129E1BE3B@illinois.edu> The Bro Project is looking for an exceptional engineer to join our core team of Bro developers. If you are interested in helping us advance Bro, please consider applying! We are looking for candidates who have demonstrated experience leading projects, excellent programming skills in C/C++ and Python, are comfortable at the Unix command line, and have solid knowledge of network technology. It is a plus if you have implemented network protocols before, been involved with large open-source projects, developed for distributed systems, or have a background in security operations. This is a full-time position with NCSA?s CyberSecurity and Networking Directorate in Urbana, IL. If you are interested, please send your application to info at bro.org (TXT or PDF format only please). Make sure to mention any relevant projects that you have worked on in the past, including your particular role. ------ Adam J. Slagell Director, Cybersecurity & Networking Division Chief Information Security Officer National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info From robin at icir.org Fri May 12 13:34:47 2017 From: robin at icir.org (Robin Sommer) Date: Fri, 12 May 2017 13:34:47 -0700 Subject: [Bro-Dev] 2.5.1 release? Message-ID: <20170512203447.GG2240@icir.org> Some of us have been talking about doing a 2.5.1 maintainance release. It has been suggested to divert from our normal route of picking just important fixes and instead go ahead and include what's currently in master, given that we actually don't have much new functionality in there yet at this time. I just went through the CHANGES since 2.5 and I can see snapshotting current master as 2.5.1 if folks here are fine with doing a broader release (which will need a bit more testing than just a bugfix update would). Any opinions? (Note I wouldn't want to exclude just individual commits currently in master from 2.5.1, as that gets messy quickly. I would say it's either all of master right now, or we pick selected commits for a narrow release as we did in the past). Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From seth at corelight.com Fri May 12 14:08:51 2017 From: seth at corelight.com (Seth Hall) Date: Fri, 12 May 2017 17:08:51 -0400 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: <20170512203447.GG2240@icir.org> References: <20170512203447.GG2240@icir.org> Message-ID: <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> > On May 12, 2017, at 4:34 PM, Robin Sommer wrote: > > I just went through the CHANGES since 2.5 and > I can see snapshotting current master as 2.5.1 if folks here are fine > with doing a broader release (which will need a bit more testing than > just a bugfix update would). Any opinions? I'd be fine with that. I think master is quite stable right now anyway. .Seth -- Seth Hall * Corelight, Inc * seth at corelight.com * www.corelight.com From slagell at illinois.edu Fri May 12 14:33:38 2017 From: slagell at illinois.edu (Slagell, Adam J) Date: Fri, 12 May 2017 21:33:38 +0000 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: On May 12, 2017, at 4:08 PM, Seth Hall > wrote: I'd be fine with that. I think master is quite stable right now anyway. Agreed. My understanding is that we still have some stochastic tests that fail for timing issues, but not if run manually on master. Is that correct? :Adam ------ Adam J. Slagell Director, Cybersecurity & Networking Division Chief Information Security Officer National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info "Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170512/80cf3eac/attachment.html From dnthayer at illinois.edu Fri May 12 14:56:14 2017 From: dnthayer at illinois.edu (Daniel Thayer) Date: Fri, 12 May 2017 16:56:14 -0500 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: <16e9f223-fea6-85de-ec32-8175eb24fbcf@illinois.edu> On 5/12/17 4:33 PM, Slagell, Adam J wrote: > > > My understanding is that we still have some stochastic tests that fail > for timing issues, but not if run manually on master. Is that correct? > > :Adam Correct. I haven't seen any failing tests recently that indicate a real problem in the software. From slagell at illinois.edu Fri May 12 18:48:53 2017 From: slagell at illinois.edu (Slagell, Adam J) Date: Sat, 13 May 2017 01:48:53 +0000 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> References: <20170512203447.GG2240@icir.org>, <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: > On May 12, 2017, at 4:09 PM, Seth Hall wrote: > > I'd be fine with that. I think master is quite stable right now anyway I'm pretty sure Vlad is in agreement, but traveling today. I think Justin as well, but I should let him speak for himself. From johanna at icir.org Fri May 12 19:29:45 2017 From: johanna at icir.org (Johanna Amann) Date: Fri, 12 May 2017 19:29:45 -0700 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: <20170513022942.5qrha6rfc55p3hii@Beezling.local> Looking over Changes, there is nothing that I am especially concerned about at a cursory glance. Johanna On Fri, May 12, 2017 at 05:08:51PM -0400, Seth Hall wrote: > > > On May 12, 2017, at 4:34 PM, Robin Sommer wrote: > > > > I just went through the CHANGES since 2.5 and > > I can see snapshotting current master as 2.5.1 if folks here are fine > > with doing a broader release (which will need a bit more testing than > > just a bugfix update would). Any opinions? > > I'd be fine with that. I think master is quite stable right now anyway. > > .Seth > > -- > Seth Hall * Corelight, Inc * seth at corelight.com * www.corelight.com > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From jazoff at illinois.edu Fri May 12 19:43:00 2017 From: jazoff at illinois.edu (Azoff, Justin S) Date: Sat, 13 May 2017 02:43:00 +0000 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: > On May 12, 2017, at 9:48 PM, Slagell, Adam J wrote: > > > >> On May 12, 2017, at 4:09 PM, Seth Hall wrote: >> >> I'd be fine with that. I think master is quite stable right now anyway > > > I'm pretty sure Vlad is in agreement, but traveling today. I think Justin as well, but I should let him speak for himself. Yes.. I think the only other thing is that the pointer to the broctl submodule hasn't been updated lately. There are bunch of fixes and a few new features in broctl master that would be nice to get out to people. I just realized since the submodule hasn't been updated the broctl changes likely aren't running anywhere yet, including our dev/test clusters. If the submodule pointer can be updated I can put master on our dev/test clusters and test everything out a bit more. -- - Justin Azoff From dnthayer at illinois.edu Fri May 12 20:42:25 2017 From: dnthayer at illinois.edu (Daniel Thayer) Date: Fri, 12 May 2017 22:42:25 -0500 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: <96f4bc5e-ad18-ea91-2b95-8b4877b9f644@illinois.edu> On 5/12/17 9:43 PM, Azoff, Justin S wrote: > >> On May 12, 2017, at 9:48 PM, Slagell, Adam J wrote: >> >> >> >>> On May 12, 2017, at 4:09 PM, Seth Hall wrote: >>> >>> I'd be fine with that. I think master is quite stable right now anyway >> >> >> I'm pretty sure Vlad is in agreement, but traveling today. I think Justin as well, but I should let him speak for himself. > > Yes.. I think the only other thing is that the pointer to the broctl submodule hasn't been updated lately. > > There are bunch of fixes and a few new features in broctl master that would be nice to get out to people. > > I just realized since the submodule hasn't been updated the broctl changes likely aren't running anywhere yet, including our dev/test clusters. If the submodule pointer can be updated I can put master on our dev/test clusters and test everything out a bit more. > > > The broctl pointer was updated recently (after that, we stopped seeing jenkins broctl test failures). From vlad at grigorescu.org Fri May 12 22:28:08 2017 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Sat, 13 May 2017 00:28:08 -0500 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: Correct, I agree. I just did another review of CHANGES, and didn't spot anything concerning. We'll look at upgrading our test cluster (and UIUC's test cluster) to master. On Fri, May 12, 2017 at 8:48 PM, Slagell, Adam J wrote: > > > > On May 12, 2017, at 4:09 PM, Seth Hall wrote: > > > > I'd be fine with that. I think master is quite stable right now anyway > > > I'm pretty sure Vlad is in agreement, but traveling today. I think Justin > as well, but I should let him speak for himself. > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170513/00bb709d/attachment.html From robin at icir.org Mon May 15 08:18:19 2017 From: robin at icir.org (Robin Sommer) Date: Mon, 15 May 2017 08:18:19 -0700 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> Message-ID: <20170515151819.GD22226@icir.org> On Sat, May 13, 2017 at 00:28 -0500, you wrote: > We'll look at upgrading our test cluster (and UIUC's test cluster) to > master. Sounds good, let us know how that is going. Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin From aaron at eppert.co Mon May 15 13:46:42 2017 From: aaron at eppert.co (Aaron Eppert) Date: Mon, 15 May 2017 16:46:42 -0400 Subject: [Bro-Dev] Protocol Analyzer Plugin Question Message-ID: Greetings, In working on authoring a new protocol analyzer plugin I have encountered the following issues: 1) When adding a new type to be passed to an event handler, thus handled upstream by a protocol analyzer script, types.bif only supports enums. In order to deal with this during build time, I have added custom rule and custom target to augment events.bif.bro before it is installed. Am I missing something here? Is there a more streamlined approach for doing this? 2) There seems to be an oddity with including an analyzer script along side the plugin. I can see, via loaded_scripts.log, that everything is being loaded properly. However, events are not being fired from the analyzer script loaded from the plugins directory. If I run bro on the command line with an accompanying PCAP, I can see all the appropriate debug I have put into the plugin, but no events fire in the analyzer script. If I run the same command line AND add a different analyzer script that handles the same events, they fire and can be verified via print. Most of the examples that exist aren't trying to do anything along these lines and, while I have the rest of the protocol defined well via BinPac, the last mile of making use of that work has been a bit uphill. Any insight into the two oddities above would be greatly appreciated. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170515/ce079abb/attachment.html From vlad at grigorescu.org Mon May 15 17:14:08 2017 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 15 May 2017 17:14:08 -0700 Subject: [Bro-Dev] Protocol Analyzer Plugin Question In-Reply-To: References: Message-ID: On Mon, May 15, 2017 at 1:46 PM, Aaron Eppert wrote: > Greetings, > > In working on authoring a new protocol analyzer plugin I have encountered > the following issues: > > 1) When adding a new type to be passed to an event handler, thus handled > upstream by a protocol analyzer script, types.bif only supports enums. In > order to deal with this during build time, I have added custom rule and > custom target to augment events.bif.bro before it is installed. > > Am I missing something here? Is there a more streamlined approach for > doing this? > Add it to init-bare.bro. e.g.: https://github.com/bro/bro/commit/ 11ec4903ee0cbd3cdb555c309f67ce399b23e37b#diff-64e7fba4a98f6581a47aa0053e9f03 c6 > 2) There seems to be an oddity with including an analyzer script along > side the plugin. I can see, via loaded_scripts.log, that everything is > being loaded properly. However, events are not being fired from the > analyzer script loaded from the plugins directory. If I run bro on the > command line with an accompanying PCAP, I can see all the appropriate debug > I have put into the plugin, but no events fire in the analyzer script. If I > run the same command line AND add a different analyzer script that handles > the same events, they fire and can be verified via print. > I'm not sure I fully understand. So, you have your analyzer, which is generating some events. Then you have a script to handle those events and generate some other events? And those script-generated events aren't actually being generated? --Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170515/554662bb/attachment.html From vlad at grigorescu.org Mon May 15 17:16:32 2017 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 15 May 2017 17:16:32 -0700 Subject: [Bro-Dev] Protocol Analyzer Plugin Question In-Reply-To: References: Message-ID: On Mon, May 15, 2017 at 5:14 PM, Vlad Grigorescu wrote: > > Add it to init-bare.bro. e.g.: https://github.com/bro/bro/com > mit/11ec4903ee0cbd3cdb555c309f67ce399b23e37b#diff-64e7fba4a9 > 8f6581a47aa0053e9f03c6 > Oops, reread what I sent and realized it wouldn't work, since this is a plugin. Sorry about that. I'll have to think about that a bit more. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170515/5670ab9f/attachment.html From jan.grashoefer at gmail.com Tue May 16 02:28:58 2017 From: jan.grashoefer at gmail.com (=?UTF-8?Q?Jan_Grash=c3=b6fer?=) Date: Tue, 16 May 2017 11:28:58 +0200 Subject: [Bro-Dev] Protocol Analyzer Plugin Question In-Reply-To: References: Message-ID: <56cbce45-0152-4ff5-0b94-09cb613c9a30@gmail.com> Hi, > 1) When adding a new type to be passed to an event handler, thus handled > upstream by a protocol analyzer script, types.bif only supports enums. In > order to deal with this during build time, I have added custom rule and > custom target to augment events.bif.bro before it is installed. > > Am I missing something here? Is there a more streamlined approach for doing > this? not sure whether this is of any help but I once added a new opaque type using a plugin. As far as I remember, there was no need to adapt anything to make that work. Jan From hosom at battelle.org Tue May 16 03:57:03 2017 From: hosom at battelle.org (Hosom, Stephen M) Date: Tue, 16 May 2017 10:57:03 +0000 Subject: [Bro-Dev] 2.5.1 release? In-Reply-To: <20170515151819.GD22226@icir.org> References: <20170512203447.GG2240@icir.org> <0D15B6F8-2D92-4C87-8147-89C8F950AA08@corelight.com> <20170515151819.GD22226@icir.org> Message-ID: Battelle's test cluster is currently on Master. I'll forward any issues that we have. -----Original Message----- From: bro-dev-bounces at bro.org [mailto:bro-dev-bounces at bro.org] On Behalf Of Robin Sommer Sent: Monday, May 15, 2017 11:18 AM To: Vlad Grigorescu Cc: bro-dev at bro.org Subject: Re: [Bro-Dev] 2.5.1 release? Message received from outside the Battelle network. Carefully examine it before you open any links or attachments. On Sat, May 13, 2017 at 00:28 -0500, you wrote: > We'll look at upgrading our test cluster (and UIUC's test cluster) to > master. Sounds good, let us know how that is going. Robin -- Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev at bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From j.e.rollinson at gmail.com Fri May 19 07:01:39 2017 From: j.e.rollinson at gmail.com (John Rollinson) Date: Fri, 19 May 2017 10:01:39 -0400 Subject: [Bro-Dev] KRB Analyzer Pre-Auth Data Message-ID: I am working on improving Bro's ability to detect Kerberos attacks (specifically certain instances of Skeleton Key attacks and encryption downgrades) which requires adjusting what information Bro passes up to the scripting layer. Generic breakdown on some of the attacks and detection methods can be found here ( https://www.blackhat.com/docs/eu-15/materials/eu-15-Beery-Watching-The-Watchdog-Protecting-Kerberos-Authentication-With-Network-Monitoring-wp.pdf ). Currently, Bro treats the ETYPE_INFO and ETYPE_INFO2 parts of the KRB Error packets the same and only extracts the password salts (if they exist). Because all of the pre-auth data gets stored into the KRB::Type_Value_Vector data structure, making all of the data in the ETYPE_INFO2 sections will likely require modifying the structure of how pre-auth data is stored and made accessible in scripts. Is anyone currently using information from "pa_data" in any scripts (especially the salt information from ETYPE_INFO2 fields)? I'd like to understand how other people are using this data currently so that I can make sure I don't break use cases in the process. Also, are there any recommendations for other parts of Bro's code to study as good examples of passing back highly variable data structures? -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170519/76f61197/attachment.html From jdopheid at illinois.edu Tue May 30 11:09:46 2017 From: jdopheid at illinois.edu (Dopheide, Jeannette M) Date: Tue, 30 May 2017 18:09:46 +0000 Subject: [Bro-Dev] Bro Package Manager Questionnaire Message-ID: The Bro team would like to encourage the development of Bro scripts and plugins by creating a website front-end for the Bro Package Manager, which additional functionality to be determined. We are seeking input from the Bro user community as to what features would be desirable. Please let us know what features you would like to see by filling out our questionnaire: https://goo.gl/forms/VyVH1aRIBB2qdZF53 ------ Jeannette Dopheide Training and Outreach Coordinator National Center for Supercomputing Applications University of Illinois at Urbana-Champaign