Re: [Bro-Dev] consistency checking for attributes

[Michał Purzyński]

Yeah, error out and let there be no surprises.

On Wed, Oct 31, 2018 at 11:17 AM Vern Paxson  wrote:

> > To be honest I'm not even sure if the behavior
> > is defined right now, i.e. if the later value will overwrite the first
> one.
>
> I don't think it's defined.  Looking at the code, the later one will
> indeed overwrite the first one.
>
> > Do you want to error out when two  are found or overwrite the
> > first with the second one?
>
> My thinking is that listing them together should be an error.  I don't
> see why it would be legitimate for this to occur, and it seems like a
> mistake that could be made if there's a lengthy list of attributes.
>
> Vern
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] consistency checking for attributes

[Michał Purzyński]

Sounds good and I like it. To be honest I'm not even sure if the behavior
is defined right now, i.e. if the later value will overwrite the first one.

Do you want to error out when two  are found or overwrite the
first with the second one?


On Mon, Oct 29, 2018 at 11:56 AM Vern Paxson  wrote:

> Attributes currently receive essentially no consistency checking.
> For example, executing this script:
>
> global a: count
>  = 10
>  = 9
> 
> 
> _func = function(d: double, t: time): count { return
> 3; };
> print a;
>
> simply results in:
>
> error in /Users/vern/tmp/attr-type-check.bro, line 7: value used but not
> set (a)
>
> I'm planning to add basic consistency checking, which will look for
> (1) attributes that are repeated (which doesn't appear to be meaningful for
> any of them) and (2) attributes that don't make sense in a given context,
> like the ones listed above.
>
> I'm thinking of implementing this as an internal table of meta-attributes,
> i.e., each attribute type, like ATTR_OPTIONAL, will have its own attributes
> like whether it requires a record context, only makes sense for aggregates,
> etc.  Here are the ones that come to mind, based on looking at the
> attributes
> at https://www.bro.org/sphinx/script-reference/attributes.html with
> examples
> in parens:
>
> applies to global variable  ()
> to global type  ()
> to event handler()
> to record field ()
> to indexed type ()
> to global indexed type  (_func)
> to type with expirable entries  (_func)
> to a file   (_interval)
>
> Any feedback?
>
> Vern
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] DHCP event removal

[Michał Purzyński]

No idea what’s in master. It should be trivial if you don’t remove the dhcp 
analyzer completely.

> On Jun 16, 2018, at 6:07 AM, Vlad Grigorescu  wrote:
> 
> Yep, already working on it. :-)
> 
>> On Sat, Jun 16, 2018 at 6:26 AM, Seth Hall  wrote:
>> 
>> On 15 Jun 2018, at 17:22, Azoff, Justin S wrote:
>> 
>> > The fix is a little trickier, you can't handle both events because the 
>> > DHCP::Msg type no longer exists and you need to wrap the old event 
>> > with
>> >
>> > @ifdef (DHCP::Msg)
>> > @endif
>> 
>> Ugh, I didn't consider that.  Bro has re-reached the point where 
>> touching any number of things can set off an avalanche of problems like 
>> this.
>> 
>> Anyone on this thread up for submitting a patch which makes Bro cope 
>> with the changes automatically?  You can then even mark the old events 
>> as deprecated. :)
>> 
>>   .Seth
>> 
>> --
>> Seth Hall * Corelight, Inc * www.corelight.com
>> ___
>> bro-dev mailing list
>> bro-dev@bro.org
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> 
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] DHCP event removal

[Michał Purzyński]

Hey, I use the dhcp analyzer because i cannot count on our dhcp logs. Not just 
that, I do some detection around it.

> On Jun 15, 2018, at 2:38 PM, Vlad Grigorescu  wrote:
> 
> Yeah, I've mainly seen it used for shellshock. On top of that, I saw some 
> scripts in GitHub that used it from:
> 
> - Michal: 
> https://github.com/michalpurzynski/bro-gramming/blob/master/dhcpr.bro
> - Matthias: https://github.com/bro/bro-scripts/blob/master/roam.bro
> - Grant Stavely: 
> https://github.com/evernote/bro-scripts/blob/master/bolo/scripts/main.bro
> - Anthony: https://github.com/anthonykasza/users/blob/master/users.bro
> 
> (There were a few others, like IVRE, but they've already updated).
> 
> Even if it's not widely used, I think it'd be a nicer user experience if we 
> were to ship a script that handled dhcp_message, and raised the old events. 
> We could mark the old events as deprecated, and remove them in the next 
> version. That way, people have at least one cycle to upgrade.
> 
> Hopefully, as we see more published Bro packages, we have a better idea of 
> which events are/aren't being used.
> 
>   --Vlad
> 
>> On Fri, Jun 15, 2018 at 9:22 PM, Azoff, Justin S  wrote:
>> > On Jun 15, 2018, at 5:18 PM, Seth Hall  wrote:
>> > 
>> >  On the 
>> > upside, you can handle both the old events and the new and they 
>> > shouldn't impact each other (if you want to make a script work on 
>> > multiple releases).
>> 
>> I ran into this on a script I got from somewhere, bash-cve-2014-6271.bro
>> 
>> The fix is a little trickier, you can't handle both events because the 
>> DHCP::Msg type no longer exists and you need to wrap the old event with
>> 
>> @ifdef (DHCP::Msg)
>> @endif
>> 
>> So for that script I ended up with
>> 
>> @ifdef (DHCP::Msg)
>> event dhcp_message(c: connection, is_orig: bool, msg: DHCP::Msg, options: 
>> DHCP::Options)
>> {
>> if ( options?$host_name && shellshock in options$host_name )
>> NOTICE([$note=Bash::DHCP_hostname_Attack,
>> $conn=c,
>> $msg=fmt("%s may have attempted to exploit 
>> CVE-2014-6271, bash environment variable attack, via dhcp hostname against 
>> %s submitting \"hostname\"=\"%s\"",c$id$orig_h, c$id$resp_h, 
>> options$host_name),
>> $identifier=c$uid]);
>> }
>> @else
>> event dhcp_offer(c: connection, msg: dhcp_msg, mask: addr, router: 
>> dhcp_router_list, lease: interval, serv_addr: addr, host_name: string)
>> {
>> if ( shellshock in host_name )
>> NOTICE([$note=Bash::DHCP_hostname_Attack,
>> $conn=c,
>> $msg=fmt("%s may have attempted to exploit 
>> CVE-2014-6271, bash environment variable attack, via dhcp hostname against 
>> %s submitting \"hostname\"=\"%s\"",c$id$orig_h, c$id$resp_h, host_name),
>> $identifier=c$uid]);
>> }
>> @endif
>> 
>> 
>> 
>> — 
>> Justin Azoff
>> 
>> 
>> 
>> ___
>> bro-dev mailing list
>> bro-dev@bro.org
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> 
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] $history extensions - zero windows, logarithmic counts

[Michał Purzyński]

I really like those ideas, especially the logarithmic count.

How much would it cost to have an event fired when those thresholds are crossed?

> On Jun 15, 2018, at 10:41 AM, Vern Paxson  wrote:
> 
> I'm working on two enhancements to the $history tracking for connections
> that thought I'd tee them up for comments.
> 
> (1) A new history element, 'W'/'w', which means that a TCP receiver
>advertised a zero window, indicating that the corresponding process
>was unable to keep up with the incoming data.  (This element is omitted
>in cases where zero windows aren't problematic: initial SYNs, and after
>FINs or RSTs.)
> 
> (2) A notion of "logarithmic counts" for history events: for certain
>events ('C' = checksum, 'T' = retransmission, and 'W' = zero window)
>the count is repeated on the 10th/100th/1000th/etc. occurrence.  So a
>history value of 'ttt' means that the responder sent somewhere between
>100 and 999 retransmissions.  This is useful because for large
>connections, a single checksum error, retransmission, or zero window
>is much less significant for analyzing performance issues than a whole
>bunch of these.
> 
> Comments?
> 
>Vern
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] bro-devel package?

[Michał Purzyński]

Well that’s s great question!

Right now my spec for building plugins downloads entire bro tree and does some 
cmake plugin to avoid waiting for the tree to build.



> On May 24, 2018, at 9:50 PM, Vlad Grigorescu  wrote:
> 
> There are a couple of cases where I think it'd be useful to have a bro-devel 
> package -- a package that I can install on a system, and then be able to 
> build plugins against Bro. (This is the same model as other *-devel packages, 
> such as openssl, libpcap, etc.)
> 
> Right now, if I compile Bro from source, run make install, I can't build a 
> package with what's in /usr/local -- Bro needs the entire source tree, since 
> the required headers are not present in /usr/local.
> 
> I'm curious how people are dealing with this issue, and if anyone has 
> thoughts on whether this would be useful, and if so, what it would take to 
> build such a package.
> 
> Thanks,
> 
>   --Vlad
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Michał Purzyński]

Big thumbs up. 

On May 15, 2018, at 5:34 PM, Johanna Amann  wrote:

>> What do people think? Any support, or concerns?
> 
> I am in favor. The only thing I would miss are the immediate change 
> notifications by email - I really like those...
> 
> Johanna
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] bro-pkg -> bropkg

[Michał Purzyński]

Bropkg is easier to type indeed. And then let's change the brocut.

> On 15 Sep 2016, at 13:53, Siwek, Jon  wrote:
> 
> Either way seems fine to me also.  Maybe do a strawpoll and go w/ the 
> majority.  Other misc. thoughts:
> 
> Internally, I already used “bropkg” instead of “bro-pkg” for the name of the 
> Python package/API because Python discourages use of hyphens in 
> module/package names.  But using the Python API isn’t a common use case and 
> figure most devs can handle doing “import bropkg” even though the 
> command-line tool is named “bro-pkg”.
> 
> I don’t think there’s an argument to change it for the sake of aligning the 
> naming convention with “broctl” because there’s already "bro-cut”.  The 
> hyphenation between those tools is already inconsistent or at least unclear 
> why one deserves hyphenation and the other doesn’t.
> 
> If easier typing is the rationale, users do already have the option of 
> creating their own shell alias.  
> 
> Another idea is to keep the command line tool named “bro-pkg”, but also 
> install a symlink to it named “bropkg” for convenience.
> 
> - Jon
> 
>> On Sep 15, 2016, at 9:35 AM, Slagell, Adam J  wrote:
>> 
>> Someone did come up to me and ask about that during BroCon.
>> 
>> I am indifferent, just please let’s not open up the whole tool name naming 
>> conversation. I don’t think I can take that again. :-)
>> 
>>> On Sep 15, 2016, at 9:27 AM, Seth Hall  wrote:
>>> 
>>> What does everyone think about making a change to rename bro-pkg to bropkg? 
>>>  I think we're early enough that we could probably get away with it and it 
>>> fits with more with existing tools like broctl.  I find it difficult to 
>>> type the hyphen too for some reason.
>>> 
>>> Thoughts?
>>> 
>>> .Seth
>>> 
>>> --
>>> Seth Hall
>>> International Computer Science Institute
>>> (Bro) because everyone has a network
>>> http://www.bro.org/
>>> 
>>> 
>>> ___
>>> bro-dev mailing list
>>> bro-dev@bro.org
>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>> 
>> --
>> 
>> Adam J. Slagell
>> Chief Information Security Officer
>> Director, Cybersecurity Division
>> National Center for Supercomputing Applications
>> University of Illinois at Urbana-Champaign
>> www.slagell.info
>> 
>> "Under the Illinois Freedom of Information Act (FOIA), any written 
>> communication to or from University employees regarding University business 
>> is a public record and may be subject to public disclosure." 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> bro-dev mailing list
>> bro-dev@bro.org
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> 
> 
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Updating NEWS for 2.5

[Michał Purzyński]

That's why I said polish not publish ;-) Send feedback, have it included or 
rejected, all can be done before 2.5

> On 31 Aug 2016, at 15:23, Seth Hall <s...@icir.org> wrote:
> 
> 
>> On Aug 30, 2016, at 8:10 PM, Michał Purzyński <michalpurzyns...@gmail.com> 
>> wrote:
>> 
>> Feedback shared privately.
>> 
>> Come on, let's read it and polish it a bit. It's already very good!
> 
> Let's wait until the 2.5 release.  Seems like it might be a bit premature to 
> post it now since the 2.5 release hasn't happened yet. :)
> 
> Jan, would you mind if we posted this directly to the Bro blog? (obviously 
> with all credit given to you!)
> 
>  .Seth
> 
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
> 

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Updating NEWS for 2.5

[Michał Purzyński]

Feedback shared privately.

Come on, let's read it and polish it a bit. It's already very good!

On Thu, Aug 25, 2016 at 1:22 AM, Jan Grashöfer 
wrote:

> I have finished my draft for a blog post explaining the new intel
> framework features including some examples:
>
> https://gist.github.com/J-Gras/3ff4d5308a69e91fb61c65c12ecb818c
>
> Feedback welcome!
>
> Jan
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Updating NEWS for 2.5

[Michał Purzyński]

Since the changes are impressive, a blog post would be a great idea indeed. Bro 
is first (?) on the market (again!) to come up with something like this :)

Such post should describe all new Intel framework feature and give examples how 
to use them.

> On 09 Aug 2016, at 17:21, Robin Sommer  wrote:
> 
> Thanks, will add.
> 
> Robin
> 
> On Tue, Aug 09, 2016 at 16:23 +0200, you wrote:
> 
>>> Could folks take a look at NEWS and see what's missing?
>>> ...
>>>- Document the recent intel framework updates.
>> 
>> For the NEWS (all changes, feel free to cut down):
>> 
>> +++
>> - Bro's Intelligence Framework was refactored and new functionality
>>  has been added:
>> 
>>  - The intel framework now supports the new indicator type
>>Intel::SUBNET. As subnets are matched against seen addresses,
>>the field 'matched' was introduced to indicate which indicator
>>type(s) caused the hit.
>> 
>>  - The new function remove() allows to delete intelligence items.
>> 
>>  - The intel framework now supports expiration of intelligence items.
>>Expiration can be configured by using Intel::item_expiration and
>>can be handled by using the item_expired() hook. The new script
>>do_expire.bro removes expired items.
>> 
>>  - The new hook extend_match() allows extending the framework. The new
>>policy script whitelist.bro uses the hook to implement whitelisting.
>> 
>>  - Intel notices are now suppressible and mails for intel notices now
>>list the identified services as well as the intel source.
>> +++
>> 
>> Additionally I talked to Seth about documentation of the new features.
>> He suggested to write a blog post. I've already started but as I am
>> quite busy at the moment it will take some more time.
>> 
>> Best regards,
>> Jan
>> ___
>> bro-dev mailing list
>> bro-dev@bro.org
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> 
> 
> -- 
> Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev