Hello All,
Is there a way to add Bro server hostname field into all the Bro log types? We have 5 Bro servers capturing traffic on different network nodes, we are trying to add each server/sensor hostname into all the log types so analyst can identify where the logs are coming from.
v/r
Jawad Rajput
Just wanted to draw more attention/feedback to a proof-of-concept
patch I just made:
https://github.com/zeek/zeek/pull/262
Basically lets us do this:
global my_event: event(a: count, b: string);
event my_event(b: string)
{ print "my_event", b; }
Which is good because:
* user doesn't care about parameter 'a', so they shouldn't have to list it
* it makes it easier for to deprecate/change event parameters
I didn't see any drawbacks to this change, but maybe I missed
something, let me know.
- Jon
Hi everybody,
I am new to zeek/bro. For an internship which will complete a
master course I have been attending, I will work with zeek and
specifically with the CIFS/SMB analyzer. After looking at the
documentation and the code, it seems to me that the this analyzer (as
available in zeek github master branch) was written in BinPac language
and only the most used protocol commands are implemented. I could
possibly work on extending the current implementation of the protocol.
Do you have any thoughts/suggestions about this? Is anyone already doing
(or planning to do) it?
Best wishes,
Mauro
A few months ago at (what was then called) BroCon, in the Community Session
I put up a list of newly contributed packages along with my best guess as
to authorship / whom to credit for the contribution. A couple of contributors
came up to me afterwards to discuss adjusting how they were credited; and,
more generally, the notion of adding an explicit "credits" field to the
info associated with a package.
This could look like:
[package]
credit = Originally written by A. Sacker <ace(a)sacker.com>. JSON
support added by W00ter (Acme Corporation).
As suggested by the example, the field would be free-form. Here, the
original author decided to include their email address, and the additional
contributor their company affiliation.
We wouldn't have any apriori rules about who can update the "credit" field,
but rather rely on the community to do that reasonably (and I imagine go
back to the original contributor if a dispute arose).
How does that sound?
Vern