zeek-dev August 2017

zeek-dev@lists.zeek.org

5 discussions

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/jsiwek/actor-system: Add Broker::publish_id function to replace send_id (096ec69)

by Azoff, Justin S

> On Aug 29, 2017, at 3:58 PM, Jonathan Siwek <jsiwek(a)ncsa.illinois.edu> wrote: > > A minor/unrelated detail of this change is that it also allows > 'pattern' values to be exchanged over broker messages. It currently > does this via Bro's serialization, but can likely be done via the > pattern's textual representation instead (need to look into it more). That's interesting.. Does that somehow get around the bro limitation that patterns can not be constructed at runtime? -- - Justin Azoff

4 years, 9 months

[Bro-Dev] Bro events hierarchy

by Rajeev Agrawal

Hi Little background of my question: I have access to Bro logs (conn,ftp,http, files etc.) and want to use them for machine learning. It will be really helpful to know the Bro logs relationship. I am looking for a list of all Bro events hierarchy. For example, HTTP session will generate a conn, http and files events. I just want to understand how these logs are created based on a particular event. TLS/SSL will generate conn, ssl, files and x509 events, Is there any such document available or is there any other way to figure this out? Thanks for your help Rajeev

4 years, 9 months

[Bro-Dev] send_id (Re: [Bro-Commits] [git/bro] topic/jsiwek/actor-system: Finish port of control framework to use broker. (8dddae1))

by Robin Sommer

Jon, replacing send_id() may indeed work better with an extension at the C++/Broker level. I'd like to avoid introducing new dependencies on Bro's serialization code, as I'm very much hoping that once the old communication code code goes we won't need that serialization layer anymore either (I know we're using it for opaque values over Broker too, but that's quite contained and should be easy to replace). Some thoughts here: - I'm thinking the best approach may be a new Bro-specific message for Broker, similar to the log-create/write messages. We can add that to the Bro shim in Broker. It'd send the name of the ID and the new value as a broker::data instance, and the receiving Bro updates the value as the message comes in. - There's one larger problem with replacing send_id() though: the old communication system has logic to send large values incrementally, so that send_id() won't block stuff. As Seth reminded me the SumStats framework is relying on that quite extensively for sending tables around. Incremental operation is something we don't have with Broker. I think that's ok, we can replace the few existing use cases of sending large values with something else. For SumStats that should probably be data stores. I don't remember if there even are further instances of this, my guess is no (I don't think we need to consider broctl's configuration updating here; those values are small and a non-incrememtnal send_id() is fine). - Another approach for broctl's updating could be switching to the upcoming configuration framework, which takes a different approach to dynamic reconfiguration. However, it's a bit out still until we can that switch completely, so for now providing a substitute for send_id() that can cover the simple uses cases looks like the best way to go. Robin On Fri, Aug 25, 2017 at 13:15 -0500, Jonathan Siwek wrote: > commit 8dddae17db9340f5261d11382aa9b67e965d5fef > Author: Jon Siwek <jsiwek(a)illinois.edu> > Date: Fri Aug 25 13:15:00 2017 -0500 > > Finish port of control framework to use broker. > > To replace usages of the send_id BIF, I had to make 3 new BIFs > > - serialize > - deserialize > - update_ID > > Using those, any Bro value can be explicitly converted to a string > of bytes, sent to a peer via a Broker event, unserialized to a Bro > val on the other side and then installed into a global identifier > via its name. > > I think this may be the most straightforward way to get this to > work for now, at least without changing significantly the Broker > internals or messaging format. It mostly boils down to not being > able to deserialize into a Bro value with the 'any' type, at least > not without also carrying Bro's actual type information somewhere > inside Broker's serialized message. > > And I think deserializing into 'any' would be needed because it's > not possible to e.g. explicitly enumerate all possible types in a Bro > script and have a particular event signature to use for any given one. > That's not possible because there's infinite ways you can create > composite types (tables, sets, vectors, etc). -- Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin

4 years, 10 months

[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, 10 months

[Bro-Dev] Check if table element exists

by Reinhard Gentz

Hi, I would like to check if a certain table element exists and then take corresponding action like the following: if (exists(mytable["my_dynamic_name"])) do something else do something else Can someone give me a hint? Reinhard

4 years, 10 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev August 2017