From johanna at corelight.com  Wed Oct  2 09:48:16 2019
From: johanna at corelight.com (Johanna Amann)
Date: Wed, 02 Oct 2019 09:48:16 -0700
Subject: [Zeek-Dev] Test binary packages for Zeek 3.0.0 and nightly
Message-ID: <A6A8D61B-5187-458E-8909-0B39AD461F70@corelight.com>

Hi everyone,

As many of you might know, we ship binary packages for Zeek using the 
OpenSuse build service. With Zeek 3.0, we are also changing the 
namespace and name of all Zeek packages on the OpenSuse build service. 
The new namespace is ?Security:Zeek?, and the packages are called 
zeek and zeek-nightly.

Binary packages for Zeek 3.0.0 are now available. While the packages 
should work fine they currently have seen a relatively minimal amount of 
testing - and I am happy about any feedback.

Packages are currently available for CentOs 7; Debian 9 & 10; Fedora 29 
& 30; Raspbian 9 & 10; SLE 12 SP4; SLE 15 & 15 SP1; openSUSE Leap 15.1; 
openSUSE Tumbleweed; Ubuntu 14.04, 18.04, 18.10, 19.04. CentOs 8 
packages will be added within the next few weeks; if you are missing any 
other distribution let me know.

Instructions how to add install the packages are available at 
https://software.opensuse.org//download.html?project=security%3Azeek&package=zeek. 
The source files that are used to generate the packages are available at 
https://build.opensuse.org/package/show/security:zeek/zeek.

Zeek nightly builds are also available again; instructions on how to add 
the packages to different systems are available at 
https://software.opensuse.org//download.html?project=security%3Azeek&package=zeek-nightly 
and the source files are available at 
https://build.opensuse.org/package/show/security:zeek/zeek-nightly. 
Nightly packages are currently still building - it might take up to a 
few hours until they are available for all supported distributions.

Packages under the old namespace will no longer be updated and will be 
completely removed in the near future.

Thank you,
  Johanna


From joblake at amazon.com  Wed Oct  2 16:15:54 2019
From: joblake at amazon.com (Johnson, Blake)
Date: Wed, 2 Oct 2019 23:15:54 +0000
Subject: [Zeek-Dev] Additional Industrial Control Systems Protocols
In-Reply-To: <CAJhOzurdJ7nZAyOtZ662GZUyq5yjnO=wH3508+t-4bvFiJnG=g@mail.gmail.com>
References: <e98271e453f5423ea4240eb48b3fa2f1@EX13D22UWC002.ant.amazon.com>
	<CAJhOzurdJ7nZAyOtZ662GZUyq5yjnO=wH3508+t-4bvFiJnG=g@mail.gmail.com>
Message-ID: <5ef2bd3346e245bd96730f70ac09507a@EX13D22UWC002.ant.amazon.com>

Thanks Amber for following up with us on this.

Tri and I had a chance to talk to Amber today and we've agreed to pursue a release of these protocols on the Zeek package manager rather than directly in to Zeek upstream. I have a few last hoops to jump through internally to arrange this through the Amazon GitHub organization.

My goal is to have this out publically in advance of ZeekWeek next Wednesday.

Blake

From: Amber Graner <akgraner at corelight.com> 
Sent: Monday, September 30, 2019 5:46 PM
To: Johnson, Blake <joblake at amazon.com>
Cc: zeek-dev at zeek.org
Subject: Re: [Zeek-Dev] Additional Industrial Control Systems Protocols

Hi Blake,

Thank you so much for reaching out to the list.? YES, please open these through our package manager.? We would be delighted, but more importantly, the community of Zeek users will be.?

Thank you and your team for extending the capabilities of Zeek.

I'll be reaching out off-list to set up some time to meet with you and your colleagues at ZeekWeek.?

Please let me know if you have any questions.

~Amber


On Mon, Sep 30, 2019 at 3:50 PM Johnson, Blake <mailto:joblake at amazon.com> wrote:
Hi Team -

As part of our work on the Customer Fulfillment Technology Security team at Amazon.com we've developed a set of protocol parsers for industrial control systems devices that we use in our production Zeek deployment. At this stage we're approved to release several of them as open source and would like to understand both if the Zeek team would be interested in taking these as contributions to upstream and, if you are, how best to coordinate the process of merging the contributions in. The five plugins we're approved to share now are:

* BACnet
* Ethernet/IP & Common Industrial Protocol (one plugin)
* Profinet
* S7comm
* MS-TDS Tabular Data Stream Protocol (not strictly ICS but used by some SCADA historians)

If the team is interested in this upstream we can submit as pull requests on GitHub, for example as one pull request per plugin, or via another workflow. If they're not a fit for upstream we can pursue an independent release. I'm really excited to make this available to the community either way!? The two main authors, my colleague Tri and myself, will be at ZeekWeek here in Seattle next month to discuss these and a few others we have coming down the pipe.

Let us know what works,

Blake Johnson
Security Engineer
Control Systems Security
Amazon.com

_______________________________________________
zeek-dev mailing list
mailto:zeek-dev at zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev



-- 

Amber Graner
Director of Community
Corelight, Inc

828.582.9469
??

?* Ask me about how you can participate in the Zeek (formerly Bro) community.
?* Remember - ZEEK AND YOU SHALL FIND!!




From vlad at es.net  Mon Oct 14 08:24:20 2019
From: vlad at es.net (Vlad Grigorescu)
Date: Mon, 14 Oct 2019 15:24:20 +0000
Subject: [Zeek-Dev] Do we still need pysubnettree?
Message-ID: <CAPqbkwutU+0dCDpnO9QiZqTHHq3NR8WNo4BVsKHoFtyW4UYXhQ@mail.gmail.com>

>From what I can tell, trace-summary and zeekctl are the only things
that use pysubnettree. pytricia seems to have become the de-facto
module that's used for these structures in Python:
https://github.com/jsommers/pytricia

In fact, pytricia has a comparison section where it claim that it's
faster (albeit only slightly) than pysubnettree.

Does it still make sense to maintain pysubnettree? pytricia's
interface looks very similar. A quick glance at how we're using
pysubnettree makes me think that pytricia could just be a drop-in
replacement. Are there build/packaging considerations? It looks like
pytricia is LGPL licensed.

On the flip side, I don't see many recent updates on pytricia.
Although, it's straightforward enough, perhaps it doesn't need
updates?

Curious to hear thoughts.

  --Vlad

From robin at corelight.com  Tue Oct 15 01:18:04 2019
From: robin at corelight.com (Robin Sommer)
Date: Tue, 15 Oct 2019 01:18:04 -0700
Subject: [Zeek-Dev] Do we still need pysubnettree?
In-Reply-To: <CAPqbkwutU+0dCDpnO9QiZqTHHq3NR8WNo4BVsKHoFtyW4UYXhQ@mail.gmail.com>
References: <CAPqbkwutU+0dCDpnO9QiZqTHHq3NR8WNo4BVsKHoFtyW4UYXhQ@mail.gmail.com>
Message-ID: <20191015081804.GK37893@corelight.com>

On Mon, Oct 14, 2019 at 15:24 +0000, Vlad Grigorescu wrote:

> Does it still make sense to maintain pysubnettree?

No strong opinion either way from my side.

It looks like pytricia does indeed offer a very similar interface, and
being able to stop maintaining a custom dependency would certainly be
a plus. On the other hand, this might be a case of "if it's not
broken, don't fix it". pysubnettree hasn't required a lot of work
recently, and users would need to install a new dependency if we
switched.

I don't know what constraints LGPL imposes when applied to Python
modules.

Robin

-- 
Robin Sommer * Corelight, Inc. * robin at corelight.com * www.corelight.com

From asharma at lbl.gov  Thu Oct 17 16:01:46 2019
From: asharma at lbl.gov (Aashish Sharma)
Date: Thu, 17 Oct 2019 16:01:46 -0700
Subject: [Zeek-Dev] alternative to open_log_file ?
Message-ID: <20191017230145.GB80886@MacPro.local>

I just noticed (rather starting to notice :) open_log_file was depricated in
2.6 and is removed in 3.0.0

What would be suggested alternative for this ? 

Aashish 



From jsiwek at corelight.com  Thu Oct 17 21:12:33 2019
From: jsiwek at corelight.com (Jon Siwek)
Date: Thu, 17 Oct 2019 21:12:33 -0700
Subject: [Zeek-Dev] Adding C++ unit tests to Zeek
Message-ID: <CAMzgZ0+MTEg9xQwKLBph7eP5NC=jSEzDXiZY6Qsy=d-CH8wfXw@mail.gmail.com>

We're thinking to add lower level C++ unit tests into Zeek to more
easily cover code that's otherwise hard to test since you have to
reach it indirectly via a script-layer test in the existing
baseline-oriented test suite.

Let us know if there's any input on choice of unit test framework or
features/requirements that are desirable.  I started with my own
thoughts here:

https://github.com/zeek/zeek/issues/643

- Jon

From jsiwek at corelight.com  Thu Oct 17 21:21:53 2019
From: jsiwek at corelight.com (Jon Siwek)
Date: Thu, 17 Oct 2019 21:21:53 -0700
Subject: [Zeek-Dev] alternative to open_log_file ?
In-Reply-To: <20191017230145.GB80886@MacPro.local>
References: <20191017230145.GB80886@MacPro.local>
Message-ID: <CAMzgZ0K=oVzRmsyM1LA-vGBq3tsos5tZDUQ+OqbWT1w7-yHuxg@mail.gmail.com>

On Thu, Oct 17, 2019 at 4:08 PM Aashish Sharma <asharma at lbl.gov> wrote:
>
> I just noticed (rather starting to notice :) open_log_file was depricated in
> 2.6 and is removed in 3.0.0
>
> What would be suggested alternative for this ?

Either the logging framework or just use open() directly:
open_log_file() didn't do anything different than open() except for
adding the file extension to the filename (by default ".log", else
ZEEK_LOG_SUFFIX env. var.).

- Jon