From jdopheid at illinois.edu Thu Jun 1 08:06:45 2017 From: jdopheid at illinois.edu (Dopheide, Jeannette M) Date: Thu, 1 Jun 2017 15:06:45 +0000 Subject: [Bro-Dev] Bro Package Manager Questionnaire Message-ID: <3AA97B44-DF4B-4CA7-82D8-1B929F0FCFFB@illinois.edu> Friendly reminder to fill out this questionnaire. Thanks to those who have responded so far! ------ Jeannette Dopheide Training and Outreach Coordinator National Center for Supercomputing Applications University of Illinois at Urbana-Champaign On 5/30/17, 1:09 PM, "bro-dev-bounces at bro.org on behalf of Dopheide, Jeannette M" wrote: 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 _______________________________________________ bro-dev mailing list bro-dev at bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From asharma at lbl.gov Thu Jun 1 10:12:11 2017 From: asharma at lbl.gov (Aashish Sharma) Date: Thu, 1 Jun 2017 10:12:11 -0700 Subject: [Bro-Dev] clusterization issue: logger node vs manager node or both ? Message-ID: <20170601171210.GB23524@mac-822.local> SO with the emergence of logging node, I am encoutering an issue with clusterization and was seeking feedback on whats a better way to do this. Presently I have been using: @if (( Cluster::is_enabled() && Cluster::local_node_type() == Cluster::MANAGER ) || ! Cluster::is_enabled()) @end if and events worker2manager_events and manager2worker_events. With logging node: I can surely do "Cluster::local_node_type() == Cluster::LOGGER" and then events logger2manager_events and logger2worker_events etc etc so on so forth. The issue I am facing is that to begin with I don't know if someone is only going to run manager only or if someone is going to run logger node as well, making the following clumsy: - @if (( Cluster::is_enabled() && Cluster::local_node_type() == Cluster::MANAGER ) || ! Cluster::is_enabled()) - if manager then use worker2manager and manager2worker events OR - @if (( Cluster::is_enabled() && Cluster::local_node_type() == Cluster::LOGGER) || ! Cluster::is_enabled()) - if logger then user logger events ? Any thoughts on how to handle existence or non-existence of logger node in a clusterization scheme ? Aashish From seth at corelight.com Thu Jun 1 11:10:47 2017 From: seth at corelight.com (Seth Hall) Date: Thu, 1 Jun 2017 14:10:47 -0400 Subject: [Bro-Dev] clusterization issue: logger node vs manager node or both ? In-Reply-To: <20170601171210.GB23524@mac-822.local> References: <20170601171210.GB23524@mac-822.local> Message-ID: On Thu, Jun 1, 2017 at 1:12 PM, Aashish Sharma wrote: > I can surely do "Cluster::local_node_type() == Cluster::LOGGER" and then events logger2manager_events and logger2worker_events etc etc so on so forth. I *strongly* recommend not running code on the logger. The whole point of the logger is that it doesn't have any script execution tasks to take care of and it's solely dedicated to logging. What's the problem you're trying to solve by running code there? .Seth -- Seth Hall * Corelight, Inc * seth at corelight.com * www.corelight.com From asharma at lbl.gov Thu Jun 1 11:38:08 2017 From: asharma at lbl.gov (Aashish Sharma) Date: Thu, 1 Jun 2017 11:38:08 -0700 Subject: [Bro-Dev] clusterization issue: logger node vs manager node or both ? In-Reply-To: References: <20170601171210.GB23524@mac-822.local> Message-ID: <20170601183807.GC45243@mac-822.local> > I *strongly* recommend not running code on the logger. The whole I agree and this makes sense. > What's the problem you're trying to solve by running code there? So I have a working clusterized bro package but it stops behaving as expected if I enable logger node. I am calling a worker2manager event inside "event log_smtp", that event' isn't kicking at all. When I disable logger, the event runs as expected. So this led me to wonder if somehow log_* events are running on logger and not on worker, which I doubted. Further causing concerns about how existence of LOGGER node can affect the entire clusterization architecture. Aashish On Thu, Jun 01, 2017 at 02:10:47PM -0400, Seth Hall wrote: > On Thu, Jun 1, 2017 at 1:12 PM, Aashish Sharma wrote: > > > I can surely do "Cluster::local_node_type() == Cluster::LOGGER" and then events logger2manager_events and logger2worker_events etc etc so on so forth. > > I *strongly* recommend not running code on the logger. The whole > point of the logger is that it doesn't have any script execution tasks > to take care of and it's solely dedicated to logging. What's the > problem you're trying to solve by running code there? > > .Seth > > -- > Seth Hall * Corelight, Inc * seth at corelight.com * www.corelight.com From jdopheid at illinois.edu Wed Jun 28 12:11:37 2017 From: jdopheid at illinois.edu (Dopheide, Jeannette M) Date: Wed, 28 Jun 2017 19:11:37 +0000 Subject: [Bro-Dev] Bro Package Manager: list of packages Message-ID: Attention Bro Community, While we?re in the process of developing a web site for the Bro Package Manager project, we?d like to share the packages we have collected so far. The package names and a short description are listed below: bro/0xxon/bro-postgresql - A PostgreSQL reader and writer for Bro. bro/0xxon/bro-sumstats-counttable - Two-dimensional buckets for sumstats (count occurences per $str). bro/corelight/bro-long-connections - Find and log long-lived connections into a "conn_long" log. bro/dopheide/bro_notice_correlation - Adds support for multi-notice correlation. bro/dopheide/venom (installed: master) - https://security.web.cern.ch/security/venom.shtml bro/hhzzk/dns-tunnels - Detect DNS Tunnels attack. bro/initconf/CVE-2017-5638_struts.git bro/initconf/phish-analysis.git bro/initconf/scan-NG bro/j-gras/add-json - Additional JSON-logging for Bro. bro/j-gras/bro-af_packet-plugin - This plugin provides native AF_Packet support for Bro. bro/j-gras/intel-extensions - Extensions for Bro's intelligence framework. bro/joesecurity/Joe-Sandbox-Bro - JoeSandbox-Bro extracts files from your internet connection and analyzes them automatically on Joe Sandbox. bro/jonzeolla/scan-sampling - Modified version of scan.bro to add destination IP sampling. bro/jsiwek/bro-test-package - An example Bro package for testing purposes. bro/jswaro/tcprs - TCP Retransmission and State Analyzer plugin for Bro. bro/ncsa/bro-interface-setup - A broctl plugin that helps you setup capture interfaces bro/pgaulon/bro-notice-slack - Bro Notices through Slack webhook bro/scebro/ldap-analyzer - LDAP write operations analyzer for Bro. bro/sethhall/bro-myricom - Packet source plugin that provides native Myricom SNF v3+v4 support. bro/sethhall/credit-card-exposure - Detect credit card numbers in HTTP and SMTP with Bro. bro/sethhall/domain-tld bro/sethhall/ssn-exposure - Detect US Social Security numbers in HTTP and SMTP with Bro. bro/srozb/dns_axfr - Find and notice DNS zone transfer attempts. bro/theflakes/bro-large_uploads - Raise notices on outgoing files over X bytes in size. To learn how to use the Package Manager, see our documentation here: http://bro-package-manager.readthedocs.io/en/stable/index.html ------ Jeannette Dopheide Training and Outreach Coordinator National Center for Supercomputing Applications University of Illinois at Urbana-Champaign From valerio.click at gmx.com Fri Jun 30 12:00:04 2017 From: valerio.click at gmx.com (Valerio) Date: Fri, 30 Jun 2017 21:00:04 +0200 Subject: [Bro-Dev] iosource: pcap_set_timeout vs pcap_set_immediate Message-ID: <8d606e1f-f72f-aa66-4189-6223badd4ca5@gmx.com> Hi all, looking at PcapSource::OpenLive() in iosource/pcap/Source.cc I was wondering whether it would be better to use pcap_set_immediate instead of "setting the smallest time-out possible" with pcap_set_timeout. Could it be that, especially in high-throughput environments, the introduced timeout in polling on the socket buffer may cause initial packet loss? best, Valerio