zeek-dev December 2016

zeek-dev@lists.zeek.org

10 discussions

[Bro-Dev] input-framework file locations

by Aashish Sharma

I have been thinking and trying different things but for now, it appears that if we are to share policies around, there is no easy way to be able to distribute input-files along with policy files. Basically, right now I use redef Scan::whitelist_ip_file = "/usr/local/bro/feeds/ip-whitelist.scan" ; and then expect everyone to edit path as their setup demands it and place accompanying sample file in the directory or create one for themselves - this all introduces errors as well as slows down deployment. Is there a way I can use relative paths instead of absolute paths for input-framework digestion. At present a new-heuristics dir can have __load__.bro with all policies but input-framework won't read files relative to that directory or where it is placed. redef Scan::whitelist_ip_file = "../feeds/ip-whitelist.scan" ; Something similar to __load__.bro model Also, one question I have is should all input-files go to a 'standard' feeds/input dir in bro or be scattered around along with their accompanied bro policies (ie in individual directories ) Something to think about as with more and more reliance on input-framework i think there is a need for 'standardization' on where to put input-files and how to easily find and read them. Aashish

4 years, 5 months

[Bro-Dev] [Proposal] Language extensions for better Broker support

by Robin Sommer

Bro's current Broker framework has a few pretty inelegant API parts because Bro's scripting language doesn't support some of its operations well currently. I've put some thoughts together on potential language extensions to improve the situation and come to a nicer Broker framework API: https://www.bro.org/development/projects/broker-lang-ext.html Feedback welcome, this is just a first draft. Robin -- Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin

5 years

[Bro-Dev] broctl archive copy vs move

by Aashish Sharma

So if we have compresscmd unset then archive-log script does a copy: archive-log: nice cp $file_name "$dest" Any reason why it doesn't do move instead ? I propose changing cp to mv Aashish

5 years, 1 month

[Bro-Dev] discussion about "violation-confirmation"

by francois.pennaneach＠free.fr

Hi, In BIT-313 "DPD: ProtocolConfirmation, ProtocolViolation revamp", there is a link to a discussion about "violation-confirmation". Unfortunately, I could not access this paper (broken link ?) As the ticket also says "ask bro-dev@... if you want access to the above website", I'm asking :-) Could I get a link to or a copy of the "violation-confirmation" discussion ? Thank you. François

5 years, 1 month

[Bro-Dev] bro-pkg upgrade and over-writing of files

by Aashish Sharma

Hello, I have a package where I provide a sample configuration file for people to redef according to their needs and specifics. Now everytime when they upgrade the package, I risk over writing their modified config file. SO I decided to call the config file scan-config.bro.orig but then I am running into issues of which one to load and how to determine the presence of an already existing scan-config.bro in __load__.bro The idea of asking uses to redef outside package directory might be cumbersome for unfamiliar users. Any thoughts ? Aashish

5 years, 1 month

[Bro-Dev] Package manager meta data

by Robin Sommer

Playing with Bro packages and bundles, there's one thing where I ended up a bit confused and that's the meta data. We have two places right now that store meta data about a package: there's the central set stored with the package source (bro-pkg.index), and then there's the set coming with the package itself (bro-pkg.meta). However, I'm a bit lost what goes where, and which information should remain accessible once things are bundled up. Seems bro-pkg.meta generally has "description" and "tags" at least. However, that information seems lost once I bundle a package up and don't have access to the index repository anymore. There doesn't seem to be an expectation that bro-pkg.meta would have similar information, so there's nothing there to fill the gap. Then, bro-pkg.meta has a "version" field (the docs show that as the one field to put in there). I believe that version isn't really used anywhere other than showing it as part of the meta data output in "info". In Python it also maps to PackageInfo.metadata_version. But then there's also PackageStatus.current_version, which is from git (although I'm not sure how I would actually set that; is it just any tag?). Once packages go through bundle/unbundle I cannot run "info" when I'm offline, and hence I don't get some of the information anymore (same from Python with PackageInfo I believe) Ideally, what I'd like to have is a single interface (speaking in Python API terms) for a package that gives me all the meta-data consistently, pulling it out from where's it's stored and maintaining it when bundling. For things like "description", "tags", it could pull them out of bro-pkg.index by default, and maybe override them from bro-pkg.meta if they are defined there (so that one can set them even if there's no package source to begin with). And bundles would then carry the information through, probably inside their manifest. For version information, bro-pkg could start with the git branch/tag but override it with values from bro-pkg.index and bro-pkg.meta if defined there. That way people could choose how to do their versioning. The API would just offer a single version() doing the right thing, and "bro-pkg info" would show that. Does this make sense? I'm not quite sure about the reasons for the current structure, I'm mostly thinking from the perspective of information about the package I'd like to have access to easily, and where it's coming from. Robin -- Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin

5 years, 1 month

[Bro-Dev] Marking commits for 2.5.1

by Robin Sommer

In BIT-1763, Johanna asks for a way to mark commits for a point release (assuming we do one). Let's do this: set the "fix version" of the ticket to include 2.5.1 and add the commit hash for the fix to the notes. Then we can later search for these and cherry-pick. (We'll still close the ticket once fixed in master to avoid confusion.) Robin -- Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin

5 years, 1 month

[Bro-Dev] proxies and tree data structures

by Aashish Sharma

I have noticed that at times my proxies are spending way too much CPU (100% for extended duration) in tree operations which include inserts and tree_balance_after_insert. Anyone has any pointers to what might be going on proxies ? Aashish

5 years, 1 month

[Bro-Dev] missing worker2manager and manager2worker events

by Aashish Sharma

I have noticed that sometimes (more often than not), not all workers see a manager2worker event or likewise not all workers report a worker2manager event on manager - missing as high as 10% of the events and as little as 1% of such events are 'missing' ie don't show up. This is puzzling since I am not sure why/where bottleneck is or what might cause the disappreance. Is there a way to assure that these events are movig data as expected ? Thanks, Aashish

5 years, 1 month

[Bro-Dev] Updating NEWS for 2.5

by Robin Sommer

Could folks take a look at NEWS and see what's missing? Couple of things I think we should add at least: - Document the cluster framework's new logger node, with an example how to use it. - Document the recent intel framework updates. - Add BroControl news/changes. Any takers for these? Robin -- Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin

5 years, 1 month

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev December 2016