Re: [Bro-Dev] Plugin branch status

[Slagell, Adam J]

On May 17, 2013, at 10:02 PM, Seth Hall s...@icir.org wrote:

 On May 17, 2013, at 9:17 PM, Robin Sommer ro...@icir.org wrote:
 
 So, my question is if I should go ahead merging this into master for
 2.2.
 
 I say let's go for it in 2.1, except that your point about the documentation 
 is worth considering so it sounds like it's up to Jon. :)

I would lean towards go for it even if there is not enough time in the beta to 
address the broxygen issues. 
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] viability of stand-alone (not installed) Bro

[Slagell, Adam J]

I don't think that is intended behavior, but rather an unintended consequence 
of some of the work on the file analysis framework and shipping with our own 
magic DB. Perhaps Jon can elaborate more on what it would take to fix this?

On Jul 29, 2013, at 10:09 PM, Vern Paxson v...@icir.org wrote:

 For various reasons I sometimes like to run Bro out of the directory
 I used to build it, rather than installing it.  With a fresh git pull,
 when doing this I get:
 
% build/src/bro
internal error: can't load magic file /usr/local/bro/share/bro/magic: 
 could not find any valid magic files!
Abort
 
 Well harumph.
 
 However, the reason for this note (rather than a shiny-new-tracker ticket)
 is I'm wondering whether filing the ticket is a lost cause (i.e., the
 current philosophy is it's okay if things only work post make install) ... ?
 
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] Dot release?

[Slagell, Adam J]

I like that plan. I think there are some minor Maverick's issues too that 
Daniel found. So we might want to get those in there as well.

On Jan 30, 2014, at 10:50 AM, Robin Sommer ro...@icir.org wrote:

 Folks,
 
 making a 2.2.1 release has been coming up a few times and I'm thinking
 we should just snapshot current master for that. We've been fixing
 quite a number of things since 2.2, yet there aren't any larger new
 features yet (GRE tunnel decapsulation being the only one I can think
 of right now).
 
 I'd wait for two more things though:
 
- Merging, and some testing, of Jon's recent file analysis
framework API changes that make the file handle management more
efficient.
 
- Figuring out the exec and/or sumstats problems (it looks certain
at this point that exec isn't cleaning up fully; and sumstats may
have a larger than expected CPU impact, but that's not clear yet I
believe).
 
 Once 2.2.1 is out, I'd then next work on merging my dynamic plugin
 code, which is mostly ready but needs cleanup, review, documentation,
 testing.
 
 How does that sound? If good, now would also be the time to finalize
 any other minor fixes that people might want to see in 2.2.1.
 
 Robin
 
 -- 
 Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org
 ICSI/LBNL* Fax   +1 (510) 666-2956 * www.icir.org/robin
 ___
 bro-dev mailing list
 bro-dev@bro.org
 http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

--

Adam J. Slagell
Chief Information Security Officer
Assistant Director, Cybersecurity
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.ncsa.illinois.edu/~slagell/

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

Re: [Bro-Dev] [JIRA] (BIT-1215) bro-cut should be rewritten in C for speed and to not depend on gawk

[Slagell, Adam J]

We are going to make it configurable and default to like a 1000KB line. 
Otherwise, you add a check to see if you need to reallocate memory for every 
line processed, which seems inefficient for edge cases. Letting the user 
override the default is a good compromise though. 

 On Jul 10, 2014, at 4:30 PM, Robin Sommer (JIRA) 
 j...@bro-tracker.atlassian.net wrote:
 
 I haven't looked at the code yet but if there's hard line length
 limit in there, that's a problem. bro-cut shouldn't care how long
 lines are.

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

Re: [Bro-Dev] Geo Location Plugin

[Slagell, Adam J]

I think that is reasonable for some things.

On Oct 16, 2014, at 8:02 AM, Robin Sommer ro...@icir.org wrote:

 (unless we decide to
 build (some) plugins by default, which currently isn't happening).

--

Adam J. Slagell
Chief Information Security Officer
Assistant Director, Cybersecurity Directorate
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] Bro Project and the Software Freedom Conservancy

[Slagell, Adam J]

Some of you know that we have been talking with the Software Freedom 
Conservancy (SFC) about joining their non-profit foundation. In fact, current 
and past contributors have probably been directly contacted by the SFC already.

We have been looking at joining a foundation or starting one for some time for 
several reasons: to signify longevity for the project, clarify and manage 
intellectual property rights and licensing, accept donations for the project 
with low overhead, build community transparency and trust, and provide legal 
protection for contributors. The SFC provides all of these. They also leave the 
technical and artistic control of the project to the contributors and community.

As we negotiate a membership contract with the SFC, we would like to open this 
conversation up to the broader community of developers, users and other 
stakeholders. This includes not only thoughts on joining with SFC, but also on 
the contract (draft attached) with them and our plans to further open up the 
documentation, which we would like to license as Creative Commons Share-alike 
or Attribution.

So please let us know your thoughts. If possible, I’d like to wrap this 
discussion up by the end of this week as I’d like to have something to announce 
at BroCon.

Thanks,
Adam Slagell

--

Adam J. Slagell
Chief Information Security Officer
Assistant Director, Cybersecurity Directorate
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.infohttp://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-sponsorship-agreement-draft.odt
Description: Bro-sponsorship-agreement-draft.odt
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Brokerization of iSSHD

[Slagell, Adam J]

I’m checking to see if anyone is already working on converting the ssllogmux 
script used by iSSHD to use Broker? I don’t think the corresponding bro scripts 
will need to be updated unless they are using , right?

:Adam
--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 2, 2016, at 3:37 PM, Matthias Vallentin  wrote:
> 
>> So with that said, I propose bro-pkg, but will leave this open for
>> another day if there are strong opinions.
> 
> I like "bro-pkg," though I wonder whether it could be even shortened to
> "bpkg" or "bkg." 

It could be, and bpkg is what I original suggest, but I thought you and Justin 
liked bro-org better.

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 2, 2016, at 10:56 AM, Siwek, Jon <jsi...@illinois.edu> wrote:
> 
>> 
>> On Jun 1, 2016, at 5:30 PM, Slagell, Adam J <slag...@illinois.edu> wrote:
>> 
>> These are variants of #1, which I now substitute with bro-pkg
> 
> Related to “pkg” or “package” naming: if that terminology gets used, what 
> would be done about the classic/existing usage of the term “package” within 
> Bro?
> 
> “Package” is currently used to refer to any collection of Bro scripts within 
> a common directory.  Just scripts, nothing else.  Meaning a “package”, as it 
> exists now, isn’t something that the new "package manager” would know how to 
> deal with.
> 
> I don’t think it’s a good idea to let the term be overloaded in the 
> documentation and possibly internal naming conventions in Bro code.  Not that 
> it can’t be changed, but just wondering if it’s already been decided that 
> making those changes would not be a big deal.

It looks like that term is just used here for “Script packages” and on all the 
auto generated subpages. We can just rename that as I don’t it is not a widely 
used term. I do want to do that before 2.5 if we do it, though.

So with that said, I propose bro-pkg, but will leave this open for another day 
if there are strong opinions.

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 4, 2016, at 1:09 PM, Robin Sommer  wrote:
> 
> The primary way we've used "plugin" so far is as a compiled,
> binary extension.

I'm not sure we all have or that the project has used it consistently in that 
way. It is new enough to Bro I'm not bothered if we shift it slightly. To me, 
the important part of a the definition of a plugin for most software is that it 
is an externally contributed, self/contained add-on which extends 
functionality. Binary or compiled don't seem very important to the definition. 

Module, extension, package, bundle, add-on, plugin, bag, etc.; whatever we pick 
long term users will acclimate. I am more concerned new users or creating 
confusion in our documentation. 
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 2, 2016, at 4:40 PM, Jan Grashöfer  wrote:
> 
> The point here was that bro-pkg would align to bro-cut. Although I still
> like brow, I would prefer bro-pkg or bropkg to bpkg and bkg. While
> b(p)kg could be anything bro-pkg is clearly bro-related.

Agreed. And if people really need to save a few characters, that’s what aliases 
are for. :-)

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 3, 2016, at 1:59 PM, Siwek, Jon <jsi...@illinois.edu> wrote:
> 
>> 
>> On Jun 2, 2016, at 3:13 PM, Slagell, Adam J <slag...@illinois.edu> wrote:
>> 
>> It looks like that term is just used here for “Script packages” and on all 
>> the auto generated subpages. We can just rename that as I don’t it is not a 
>> widely used term. I do want to do that before 2.5 if we do it, though.
>> 
>> So with that said, I propose bro-pkg, but will leave this open for another 
>> day if there are strong opinions.
> 
> Collections of bro scripts in a directory containing an __load__.bro file 
> were named “packages” because that is pretty much the same way Python 
> structures the things it calls “packages”.  So, now that I think about it, 
> it’s actually more odd to rename them because that structural similarity is 
> not going away.
> 
> Maybe I value consistency too much, but I don’t see how any of the proposals 
> so far are improvements to the current situation.  I’m going to make a final 
> argument for just sticking with the original names of things:
> 
> 1) Keep calling “Bro Script Packages” as “packages”.  They look just like 
> Python packages after all.
> 
> 2) Keep calling “Bro Plugins” as “plugins”.  No one explicitly asked to 
> rename plugins or give them an alternate name, but that is what is happening 
> here whether people realized it or not.  Why are we trying to create a 
> synonym for something that is already called a “plugin” ?  Won’t it be more 
> confusing if it turns out that a “package” may also be called a “plugin” ?  
> And confusing that a “package" (also called a “plugin”) shares little 
> similarity with a Python package, but it contains within it something that 
> does look like a Python package, yet is named something else?
> 
> 3) CBAN becomes something like “Bro Plugin Manager” because it is dealing 
> with plugins, not packages.  In fact, “plugin" is probably more descriptive 
> about what is going on. In general, a plugin just means any form of extending 
> a software’s functionality without having to directly modify that software.  
> That could mean shared libraries, scripts, etc.  This is exactly what is 
> going on here and I don’t see how we can get any more clear or consistent 
> than the existing names.

So what would you do, call it the tool bro-bpm, the project “Bro Plugin 
Manager” (BPM), and the objects being managed plugins? 

Alternatively, what I earlier proposed is that we call directories of related 
scripts bundles, plugins are called plugins, a plugin+metadata that fits them 
within our package manager a package, and the whole system the Bro Package 
Manager (BPM) with the tool named bro-pkg.

I am fine if we want to hash out these last two options a bit longer, but 
please no more to the mix.

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 5, 2016, at 10:55 AM, Robin Sommer  wrote:
> 
>> To me, the important part of a the definition of a plugin for most
>> software is that it is an externally contributed, self/contained
>> add-on which extends functionality.
> 
> Agree in principle, but "extending functionality" with a plugin is
> different that just writing a new Bro script. A "plugin" typically
> plugs into a set of hooks that a software provides to extend things it
> doesn't provide out of the box; once loaded, that new functionality
> then becomes a core feature just as if it had been built in in the
> first place. I don't see, e.g., writing a script-level detector for
> new vulnerability XYZ like that. If a wrote new Python module
> implementing, say, BASE65 encoding, I wouldn't be adding a "plugin" to
> Python either.

I think we are working from two different mental models. You are thinking of 
Bro mostly from the programming language perspective and analogies with Python. 
I am thinking of it as a tool or piece of software. It’s both, but I am not 
bothered by incongruencies to Python. 

Regardless, it seems that you and Jon have irreconcilable differences that 
eliminate plugin or package. And as the PI and implementer, I give high weight 
to both of your opinions. Would either of you object to extensions?

So while I *really* hate to do this, I will throw out bro-bee and Bro 
Extensions for Everyone.

--

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

Re: [Bro-Dev] New proposal (Re: CBAN naming)

[Slagell, Adam J]

> On Jun 6, 2016, at 9:46 PM, Robin Sommer  wrote:
> 
>> 
>> That all looks consistent except part (2) ends up pointing people
>> toward existing docs/examples that reference “package” but with a
>> different meaning.  I'd need a decision to be made about how/whether
>> to change that.
> 
> Ok, then let's rename "package" in the current docs. I propose
> "module" as the replacement: it's not quite right regarding the
> language's module concept but close enough I would say.

Or “bundle", which has even less baggage, but I think module is fine.

> 
>> naming the project/client/containers
> 
> My vote: Bro Package Manager, bro-pkgs, package. 

Only difference is I don’t think the client needs the plural. I would simply go 
to bro-pkg.

--

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 25, 2016, at 12:12 AM, Robin Sommer  wrote:
> 
> Overall, I agree that we can always add more restrictions later if it
> turns out necessary. It's not that we'll have 1000s of Bro modules in
> there within the first two weeks (as long as we prevent somebody
> spamming us

So this has become an involved thread. Do we need a call, or do you think you 
can pull out enough to get started Jon?
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 25, 2016, at 11:25 AM, Siwek, Jon <jsi...@illinois.edu> wrote:
> 
>> 
>> On May 25, 2016, at 9:49 AM, Slagell, Adam J <slag...@illinois.edu> wrote:
>> 
>> So this has become an involved thread. Do we need a call, or do you think 
>> you can pull out enough to get started Jon?
> 
> Yes I can reorganize all latest ideas into an alternate design document. 

That’s all I meant. Thanks.

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

Think the current name is fine, but if you change it I think it helps if it 
relates to things people know. So names like bpkg, bro-ports, or bro-brew would 
give the immediate analogy through the name.


> On May 27, 2016, at 12:00 PM, Matthias Vallentin  wrote:
> 
> To find the new name for our CBAN project, it probably make sense to
> brainstorm separately from the existing technical thread. I'd say let's
> collect some candidates and then create survey to vote on them.
> 
> Here are some ideas from the existing thread:
> 
>- brow
>- broil
>- broom
>- bpk
>- berk
>- bob
>- bip
> 
> Looking forward to hear your ideas.
> 
>Matthias
> ___
> 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] Something to think about as we build Bro Package Manager

[Slagell, Adam J]

http://arstechnica.com/security/2016/06/college-student-schools-govs-and-mils-on-perils-of-arbitrary-code-execution/

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 4, 2016, at 10:45 AM, Siwek, Jon  wrote:
> 
> My last understanding is that we’re starting out w/ metadata being entirely 
> optional and seeing how it goes.  This also makes it more convenient for 
> people to use the tool to manage plugins they have no intention of publishing 
> and so don’t care to bother w/ metadata.

I still strongly disagree with ALL metadata being optional, unless it is 
automatically cleaned up if they never “finish” putting in required data.

However, that does not have a large impact on the name. I think we are now 
arguing between two reasonable proposals, and I am fine giving preference to 
the plugin naming because it does require the least amount of changes in 
current naming conventions.

I will leave it open this weekend for members of the project leadership to jump 
in if they want, but otherwise let’s go with Bro Plugin Manager (BPM) and 
bro-bpm.

--

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 26, 2016, at 10:46 AM, Robin Sommer  wrote:
> 
> - Terminology 1: agree that we should find a better name for CBAN.

BroForge?

> 
> - Terminology 2: Using "plugin" as the entity name for everything is
>  confusing I think, as right now I think most people understand it as
>  something that gets compiled; nobody calls a script a plugin (unless
>  it's a plugin for a specific script-framework; but that's even more
>  confusing then :). The best alternative names I can come up with are
>  "module" or "package", which are also overloaded already, but at
>  least more generic. Other suggestions?
> 

But we are wrapping everything in the Bro plugin architecture, right? I guess I 
I don’t think of plugins as necessarily binary, but maybe we shift nomenclature 
completely and start calling plugins packages across our documentation. But if 
we refer to the same thing as a plugin sometimes and a package other times, I 
think it gets even more confusing.

> - We could create a public mailing list for CBAN for all discussions
>  of individual plugins/modules, including in particular for decisions
>  to remove something. Would be good to keep this all open and
>  transparent.


I like the idea of a CBAN list.

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On Jun 2, 2016, at 10:56 AM, Siwek, Jon  wrote:
> 
> Related to “pkg” or “package” naming: if that terminology gets used, what 
> would be done about the classic/existing usage of the term “package” within 
> Bro?
> 
> “Package” is currently used to refer to any collection of Bro scripts within 
> a common directory.  Just scripts, nothing else.  Meaning a “package”, as it 
> exists now, isn’t something that the new "package manager” would know how to 
> deal with.
> 
> I don’t think it’s a good idea to let the term be overloaded in the 
> documentation and possibly internal naming conventions in Bro code.  Not that 
> it can’t be changed, but just wondering if it’s already been decided that 
> making those changes would not be a big deal.

Good question. Let me look into how hard it would be to change that.

--

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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

I have gone over a bunch of these threads and want to bring this back towards 
consensus, or at least consilience. Let’s pick from the following 5 options, 
and then we can decide if these are bundles, ports, packages, plugins, 
extensions, modules, or bags.

Key criteria are clarity and simplicity. Does it give an intuitive sense of 
what it is without adding confusion? No name or analogy will be perfect, but 
let’s not let the perfect be the enemy of the good.


And the nominees are:

1. bpkg
2. brow
3. bagger
4. bro-ports
5. bro-brew


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

Re: [Bro-Dev] CBAN naming

[Slagell, Adam J]

> On May 31, 2016, at 12:54 PM, Matthias Vallentin  wrote:
> 
>> 
>> I favor “bagger” or “bagboy” along with “bags”.  
> 
> I did not get the "bagger" and "bagboy" variations until I googled it,
> probably because I'm not a native speaker. However, I like the grocery
> bag association, that one stuck immediately. We could have a shopping
> "cart" as well, to represent a collection of bags. The grocery store
> theme works really well, in my opinion. 

Can we call an orphaned package or homeless one a “bag lady"?

--

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

Re: [Bro-Dev] Bro plugins + broctl plugins?

[Slagell, Adam J]

https://bro-tracker.atlassian.net/browse/BIT-1551

> On Jun 23, 2016, at 11:48 AM, Seth Hall  wrote:
> 
> Has any movement been made on the ability to add broctl plugins into bro 
> plugins?  I know we talked about it a few times, and it's sort of becoming 
> necessary are more packet source plugins are showing up in the bro-plugins 
> repository.
> 
> .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

Re: [Bro-Dev] [JIRA] (BIT-1571) Connection summaries w/ IPv6 have poor readabiity

[Slagell, Adam J]

Or don’t count it in the port statistics, but still count it in the protocol 
stats. So you would see a ton of protocol #1

But I think I like your suggestion better because it separates things like 
53/tcp and 53/udp.

On Apr 26, 2016, at 9:04 AM, Vlad Grigorescu 
> wrote:

I'm not sure I agree without additional context. ICMP exfil is a known 
technique. Wouldn't you want to know if all of a sudden, you started seeing 
gigs of ICMP? Or is there some other limitation that would make detecting this 
problematic?

What I would recommend instead is simply adding the protocols to the ports. So, 
instead of "top ports: 53, 80, 443, 8" you would see: "top ports: 53/udp, 
80/tcp, 443/tcp, 8/icmp"

Would this be sufficient to solve the ICMP/port number confusion?

On Tue, Apr 26, 2016 at 8:07 AM, Adam Slagell (JIRA) 
> wrote:

[ 
https://bro-tracker.atlassian.net/browse/BIT-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25900#comment-25900
 ]

Adam Slagell commented on BIT-1571:
---

Talking with Seth, he agrees that it probably just makes more sense to leave 
ICMP out of the connection summaries.

> Connection summaries w/ IPv6 have poor readabiity
> -
>
> Key: BIT-1571
> URL: 
> https://bro-tracker.atlassian.net/browse/BIT-1571
> Project: Bro Issue Tracker
>  Issue Type: Improvement
>  Components: BroControl
>Affects Versions: 2.4
>Reporter: Adam Slagell
>Assignee: Daniel Thayer
>Priority: Low
> Fix For: 2,5
>
> Attachments: [Bro] Connection summary from 15_53_27-16_00_00.txt
>
>
> The variable length of IPv6 and being mixed with IPv4 causes alignment issues 
> with the white space in the connection summary emails.



--
This message was sent by Atlassian JIRA
(v1000.5.0#72002)
___
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

--

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 24, 2016, at 4:46 PM, Matthias Vallentin  wrote:
> 
> If I understold it correctly, I don't think that the central CBAN
> repository will accumulate clutter. The automatic checks will help
> simply age out repos that do not comply with the minimal standards. It's
> up to the devs to comply if the want to be integrated.

I think that’s fine, but that isn’t what I thought Robin was saying. I thought 
he did not want minimal standards.

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 23, 2016, at 5:40 PM, Robin Sommer  wrote:
> 
>> 
>> When a contributor submits a new script, there would be some mandatory
>> checks that would need to pass for the script to be included:
> 
> The "mandatory" is where I disagree. I believe there's just to much
> involved with any initial vetting, even if conceptually simply, that
> it will create a bottleneck.

I guess there is a balance here. If we do no mandatory checks and you could 
submit something that isn’t even a Bro plugin, the repository could become 
cluttered with junk. Do we really want things that don’t even “compile”? I 
guess we can wait and see for some of these decisions, meaning start with 
optional and decide to make them mandatory if it becomes a problem. 

However, where we can’t do that is with the metadata we collect. If we don’t 
require what we think is important metadata in the beginning, then we will have 
a gap if we decide it was important all along. So there I would err towards 
overcorrecting in the beginning, and make things optional in the future if it 
turns out not to be important.

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 24, 2016, at 11:21 AM, Siwek, Jon  wrote:
> 
> I think all those points make things easy on contributors, minimize direct 
> involvement of the Bro Team in sorting out problems related to particular 
> plugins, and provide a useful way for users to discover and maintain Bro 
> plugins.  There’s more potential for users to encounter broken/bad plugins, 
> but maybe that also encourages stronger community involvement w/ users more 
> likely to try and help get problems resolved.

I don’t feel like we have converged on agreement regarding the balance of 
mandatory vs. optional checks.

I think we need to define some basic metadata as a requirement for 
interoperability and discovery. Otherwise, what do we really end up providing 
above and beyond GitHub. 

Other quality checks can be optional, as long as we can change that in the 
future. I still think we should do do some basic checks to avoid completely 
broken stuff. It might mean more work for us in making sure we have good 
feedback and documentation.

In general we all want to avoid human interaction becoming a bottleneck to 
submissions.

I propose that we keep mandatory checks minimal, but not non-existent, and then 
we reevaluate when we have real data about how well this works. But I would 
really like more feedback from the community. Maybe I am an outlier here?

--

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 24, 2016, at 12:07 PM, Siwek, Jon <jsi...@illinois.edu> wrote:
> 
>> 
>> On May 23, 2016, at 6:30 PM, Slagell, Adam J <slag...@illinois.edu> wrote:
>> 
>> I guess there is a balance here. If we do no mandatory checks and you could 
>> submit something that isn’t even a Bro plugin, the repository could become 
>> cluttered with junk. Do we really want things that don’t even “compile”?
> 
> The clutter could still be removed by an out-of-band process.  e.g. there’s 
> no initial check for whether a submission actually works, but after X days of 
> a nightly process finding it is broken, it gets auto-removed.

That is a good point. I am more concerned about accumulating clutter.

--

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

Re: [Bro-Dev] CBAN design proposal

[Slagell, Adam J]

> On May 21, 2016, at 5:44 PM, Robin Sommer  wrote:
> 
> As I read through the design doc, I started questioning our plan of
> curating CBAN content. I know that's what we've been intending to do,
> but is that really the best approach? I don't know of script
> repositories for other languages that enforce quality control on
> submissions beyond checking technical conventions like certain meta
> data being there.

I think there is a broad spectrum from no interaction to vetting and pulling 
into the main repository. It is about finding the right balance. 

I agree with minimal restrictions that block submissions. There needs to be 
some basic quality control and standardization there. For example, do you have 
all the right pieces. 

I do think there is another level of non blocking checks and quality control we 
can provide. For example, we can do checks for exec calls and give warnings to 
users. I think Puppet Forge has a nice model here. We won't block a submission, 
but these checks encourage better development and help new users trust 
submissions. That said, I think these must be automated. They can't block on a 
human reviewing them. 

Finally, I think we need a way to let the whole community endorse scripts or 
script authors. 
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Detecting protocols without full analyzers

[Slagell, Adam J]

Some of the core developers of Bro have been having this discussion internally, 
and I’d like to bring it to the broader community.

It has been recognized that there are a lot of protocols for which we don’t 
have full analyzers that some would still like to detect in our conn.logs via 
simple signatures. A full analyzer is much harder to write and to do well. This 
creates a barrier to entry. Further, some protocols would not benefit much from 
deeper analysis because of encryption or other issues. However, it is still 
desirable to notice that such protocols and applications are used on your 
network.

I don’t think anyone disagreed that this could be useful, but the question 
would be how to do it in a maintainable way and where to put it. For example, 
would this be another field in the conn.log? Would this be turned on in Bro by 
default, would it be in the policy directory and not base, or would it be a 
separate plugin people could download if they want.

I’m not going to repeat all the arguments for or against different positions 
here; I’ll let people do that for themselves. I just want to start the 
conversation within the broader community.

:Adam

--

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

Re: [Bro-Dev] Detecting protocols without full analyzers

[Slagell, Adam J]

> On May 9, 2016, at 11:20 AM, Robin Sommer  wrote:
> 
> Actually I would propose something else: we recently added minimal
> analyzers for IMAP and XMPP that parse just the beginning of a
> session---just enough to confirm the protocol and, in these cases,
> also use of SSL. That's an approach that I think could work more
> generally as well: even if a full analyzer isn't feasible, doing just
> the standard DPD confirmation for a protocol should usually be pretty
> straight-forward.

Is this what Justin did for RDP, because I don’t think that was much effort, 
was it Justin?

:Adam

--

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

Re: [Bro-Dev] package manager progress

[Slagell, Adam J]

Hhhm, is it naming conventions that people have a problem with or the 
implication of policing? These can be separated. I don’t see a downside to 
promoting conventions. 

It also seems that some of the reason (e.g., that we have metadata is based on 
an assumption that we will have good metadata). But I recall a lot of 
resistance to requiring basic metadata.

I believe this merits a little more discussion and would like to nudge behavior 
if possible, though not compel it. We could do this by simply providing a 
skeleton taxonomy into which people could always just through things in “misc” 
or some equivalent.

> On Jul 27, 2016, at 12:57 PM, Robin Sommer  wrote:
> 
> Make it four. :) I'm with Seth, too, better not to enforce any naming
> scheme because the boundaries are unclear. Also, note that a single
> binary Bro plugin can provide multiple quite different things (say, a
> reader and an analyzer and a packet source all at the same time, if
> one so desires :).
> 
> Also agree with Johanna: the username is part of the package name if I
> follow correctly, so there's disambiguation there.
> 
> I have some more feeback on the package manager and Jon's questions
> starting this thread, will send soon.
> 
> Robin
> 
> On Wed, Jul 27, 2016 at 09:15 -0700, you wrote:
> 
>> And to add a me three to this - I am also with him on this one. On top 
>> of things - I might misremember this, but didn't we plan package names 
>> to include the github user name at one point of time? So a package name 
>> would be user/redis, for example, and there also could be user2/redis?
>> 
>> Johanna
>> 
>> On 27 Jul 2016, at 9:05, Matthias Vallentin wrote:
>> 
 I actually don't like this that much because some of these can cross
 boundaries and do all sorts of different things in a single plugin.
 It makes more sense to me to leave the naming open.
>>> 
>>> I'm with Seth on this one. The reason why I think we should keep the
>>> naming open is that it's the job of the meta data tags to take care of
>>> the grouping. If someone writes a redis package, then they should 
>>> apply
>>> the redis package. Encoding this meta data into the package name is
>>> quite limited, however.
>>> 
>>>Matthias
>>> ___
>>> 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
>> 
> 
> 
> -- 
> 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

Re: [Bro-Dev] package manager progress

[Slagell, Adam J]

> On Aug 5, 2016, at 12:52 PM, Robin Sommer  wrote:
> 
>> 
>> Hhhm, is it naming conventions that people have a problem with or the 
>> implication of policing?
> 
> The problem is that the suggested naming convention wouldn't work:
> it's not clear how somebody would name their plugin if it provided
> more than one specific piece of functionality.

I would expect that any package repository has that same issue, there is no 
perfect taxonomy.

If we are going to rely on metadata, which I agree can be better as you can tag 
a package with multiple categories, we should probably have some basic 
requirements for this type of metadata. Do you agree?

:Adam

--

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

Re: [Bro-Dev] package manager progress

[Slagell, Adam J]

> On Aug 5, 2016, at 6:37 PM, Siwek, Jon <jsi...@illinois.edu> wrote:
> 
> 
>> On Aug 5, 2016, at 1:29 PM, Slagell, Adam J <slag...@illinois.edu> wrote:
>> 
>> If we are going to rely on metadata, which I agree can be better as you can 
>> tag a package with multiple categories, we should probably have some basic 
>> requirements for this type of metadata.
> 
> At a minimum, it’s useful to provide a list of “suggested keywords” that 
> people can choose from when tagging their packages so there’s at least a 
> common terminology to search within.
> 
> Do you mean to require something more than that?  E.g. “packages submitted to 
> the ‘bro’ package source MUST NOT use keywords outside the pre-approved list” 
> ?  Or “packages submitted to the ‘bro’ package source MUST contain at least 
> one keyword tag” ?
> 
I was thinking of requiring at least one keyword. 

> - Jon

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

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

[Slagell, Adam J]

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

Re: [Bro-Dev] Updating NEWS for 2.5

[Slagell, Adam J]

Thanks. Let’s space out our blogs a little bit (We posted one yesterday on 
bro-pkg) and save this one for after the 2.5 release.

> On Oct 4, 2016, at 4:09 PM, Jan Grashöfer  wrote:
> 
> Meanwhile I have added Michal's suggestions and he reviewed again:
> https://gist.github.com/J-Gras/3ff4d5308a69e91fb61c65c12ecb818c
> Feel free to publish :)
> 
> Jan
> ___
> 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."










signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

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

[Slagell, Adam J]

Let's hold off if we might be renaming Bro

On Sep 16, 2016, at 4:17 PM, Matthias Vallentin  wrote:

>> Bropkg is easier to type indeed. And then let's change the brocut.
> 
> Yeah, all bro* utils should be consistent. If we change bro-pkg, then
> bro-cut must undergo the same changes.
> 
> Personally, I never had trouble typing "bro-pkg" though. Can we do a
> Twitter poll to figure out what our users prefer?
> 
>Matthias
> ___
> 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] Blog post for bro-pkg

[Slagell, Adam J]

Jon,

Would you be up for writing a blog post introducing the Bro Package Manager and 
showing some examples of its use? We probably also want to state that these are 
unvetted contributions from the community.

:Adam



--

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

Re: [Bro-Dev] OpenFlow Analyzer

[Slagell, Adam J]

Have you looked at the netcontrol framework in Bro, developed by Johanna?

> On Oct 17, 2016, at 2:24 PM, Hui Lin (Hugo)  wrote:
> 
> Hi 
> 
> My understanding is that Bro has some northbound API to openflow switches or 
> controllers. I am wondering whether any development branch has analyzer of 
> openflow controllers. Just try to see whether I can use Bro to analyze some 
> controller-to-switch traffics. 
> 
> Best,
> 
> Hui
> 
> 
> -- 
> Hui Lin
> Ph.D. Candidate (http://hlin33.web.engr.illinois.edu/ 
> ) 
> DEPEND (http://depend.csl.illinois.edu/ )
> ECE, Uni. of Illinois at Urbana-Champaign 
> 
> ___
> 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." 










smime.p7s
Description: S/MIME cryptographic signature
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] OpenFlow Analyzer

[Slagell, Adam J]

I get you now. I am not aware of an open flow protocol analyzer in Bro.

> On Oct 17, 2016, at 2:45 PM, Hui Lin (Hugo) <hli...@illinois.edu> wrote:
> 
> Actually, netcontrol is what I thought of as northbound APIs. I actually just 
> wonder whether Bro has analyzer for openflow protocol or not (some refer them 
> as southbound traffics). It not, I probably need to use wireshark to output 
> the pcap and analyze them manually. 
> 
> On Mon, Oct 17, 2016 at 2:37 PM, Slagell, Adam J <slag...@illinois.edu 
> <mailto:slag...@illinois.edu>> wrote:
> Have you looked at the netcontrol framework in Bro, developed by Johanna?
> 
>> On Oct 17, 2016, at 2:24 PM, Hui Lin (Hugo) <hli...@illinois.edu 
>> <mailto:hli...@illinois.edu>> wrote:
>> 
>> Hi 
>> 
>> My understanding is that Bro has some northbound API to openflow switches or 
>> controllers. I am wondering whether any development branch has analyzer of 
>> openflow controllers. Just try to see whether I can use Bro to analyze some 
>> controller-to-switch traffics. 
>> 
>> Best,
>> 
>> Hui
>> 
>> 
>> -- 
>> Hui Lin
>> Ph.D. Candidate (http://hlin33.web.engr.illinois.edu/ 
>> <http://hlin33.web.engr.illinois.edu/>) 
>> DEPEND (http://depend.csl.illinois.edu/ <http://depend.csl.illinois.edu/>)
>> ECE, Uni. of Illinois at Urbana-Champaign 
>> 
>> ___
>> bro-dev mailing list
>> bro-dev@bro.org <mailto:bro-dev@bro.org>
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.icsi.berkeley.edu_mailman_listinfo_bro-2Ddev=DQMFaQ=8hUWFZcy2Z-Za5rBPlktOQ=gMEsgy9kNQo7aTfyIJsOSuw4Z57hfQyz6uV2H4S9PvE=6uypPBIs5nv0peW6XK_o8f3Tu4OHNbnBILH4E2KzmI0=S1oVBNplwXmgrFjCjOVpo2f7jqaRkA83lof6A3C0K3c=>
> 
> --
> 
> Adam J. Slagell
> Chief Information Security Officer
> Director, Cybersecurity Division
> National Center for Supercomputing Applications
> University of Illinois at Urbana-Champaign
> www.slagell.info 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.slagell.info=DQMFaQ=8hUWFZcy2Z-Za5rBPlktOQ=gMEsgy9kNQo7aTfyIJsOSuw4Z57hfQyz6uV2H4S9PvE=6uypPBIs5nv0peW6XK_o8f3Tu4OHNbnBILH4E2KzmI0=si3U_XSgz2LTo9UrJ_nkxfh3RIFE1cVuMrTHK3PX6Sk=>
> 
> "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." 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Hui Lin
> Ph.D. Candidate (http://hlin33.web.engr.illinois.edu/ 
> <http://hlin33.web.engr.illinois.edu/>) 
> DEPEND (http://depend.csl.illinois.edu/ <http://depend.csl.illinois.edu/>)
> ECE, Uni. of Illinois at Urbana-Champaign 
> 

--

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." 










smime.p7s
Description: S/MIME cryptographic signature
___
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

[Slagell, Adam J]

On Dec 1, 2016, at 4:32 AM, Jan Grashöfer  wrote:

>> Thanks. Let’s space out our blogs a little bit (We posted one yesterday on 
>> bro-pkg) and save this one for after the 2.5 release.
> 
> As 2.5 has been released and there have already been some questions on
> the mailing list, it would be good to publish the blog post.
> 
> Jan
Agreed. Please work with Jeannette to post it. 

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

Re: [Bro-Dev] early performance comparisons of CAF-based run loop

[Slagell, Adam J]

That might be useful. I would like Robin’s thoughts, too.

On Apr 12, 2017, at 9:05 PM, Siwek, Jon 
> wrote:

In the near-term, I can make a totally separate code branch that simply 
replaces select() with epoll.  Then, if Justin were to test it and find it 
alleviates performance pains on the manager, it could potentially get merged 
into bro/master ahead of the any of the pending broker/caf/runloop projects 
since it should be a trivial and safe change to do.  Let me know.

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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

Re: [Bro-Dev] 2.5.1 release?

[Slagell, Adam J]

> On May 12, 2017, at 4:09 PM, Seth Hall  wrote:
> 
> I'd be fine with that.  I think master is quite stable right now anyway


I'm pretty sure Vlad is in agreement, but traveling today. I think Justin as 
well, but I should let him speak for himself. 
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] 2.5.1 release?

[Slagell, Adam J]

On May 12, 2017, at 4:08 PM, Seth Hall 
> wrote:

I'd be fine with that.  I think master is quite stable right now anyway.

Agreed.

My understanding is that we still have some stochastic tests that fail for 
timing issues, but not if run manually on master. Is that correct?

:Adam

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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

Re: [Bro-Dev] bro-pkg dependencies ?

[Slagell, Adam J]

At list recursively finding all of those dependencies is on the roadmap. Terry 
has that on his queue.

> On Sep 8, 2017, at 12:29 PM, Aashish Sharma  wrote:
> 
> Can we specify dependent packages in bro-pkg and would bro-pkg go and resolve
> (install) those dependencies by itself ?
> 
> Also, can we make the bro-pkg dump some output (notes) before? or after? pkg
> installation - something like see this file for details etc ?
> 
> Aashish 
> ___
> 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] Bro working well on Mac OS High Sierra, just a couple test failures

[Slagell, Adam J]

I had no problems after the upgrade to High Sierra on my “production” box, and 
I had no troubles compiling Bro 2.5.1 on my laptop.

I did, however, get a two errors in the test suite.

core.truncation ... failed
  % 'btest-diff output' failed unexpectedly (exit code 1)
  % cat .diag
  == File ===
  #separator \x09
  #set_separator,
  #empty_field  (empty)
  #unset_field  -
  #path weird
  #open 2017-10-04-18-48-40
  #fields   ts  uid id.orig_h   id.orig_p   id.resp_h   
id.resp_p   nameaddlnotice  peer
  #typestimestring  addrportaddrportstring  string  
boolstring
  1334160095.895421 -   -   -   -   -   truncated_IP
bro
  #close2017-10-04-18-48-40
  #separator \x09
  #set_separator,
  #empty_field  (empty)
  #unset_field  -
  #path weird
  #open 2017-10-04-18-48-41
  #fields   ts  uid id.orig_h   id.orig_p   id.resp_h   
id.resp_p   nameaddlnotice  peer
  #typestimestring  addrportaddrportstring  string  
boolstring
  1334156241.519125 -   -   -   -   -   truncated_IP
bro
  #close2017-10-04-18-48-41
  #separator \x09
  #set_separator,
  #empty_field  (empty)
  #unset_field  -
  #path weird
  #open 2017-10-04-18-48-41
  #fields   ts  uid id.orig_h   id.orig_p   id.resp_h   
id.resp_p   nameaddlnotice  peer
  #typestimestring  addrportaddrportstring  string  
boolstring
  1334094648.590126 -   -   -   -   -   truncated_IP
bro
  #close2017-10-04-18-48-41
  #separator \x09
  #set_separator,
  #empty_field  (empty)
  #unset_field  -
  #path weird
  #open 2017-10-04-18-48-43
  #fields   ts  uid id.orig_h   id.orig_p   id.resp_h   
id.resp_p   nameaddlnotice  peer
  #typestimestring  addrportaddrportstring  string  
boolstring
  1338328954.078361 -   -   -   -   -   
internally_truncated_header -   F   bro
  #close2017-10-04-18-48-43
  #separator \x09
  #set_separator,
  #empty_field  (empty)
  #unset_field  -
  #path weird
  #open 2017-10-04-18-48-43
  #fields   ts  uid id.orig_h   id.orig_p   id.resp_h   
id.resp_p   nameaddlnotice  peer
  #typestimestring  addrportaddrportstring  string  
boolstring
  1404148886.981015 -   -   -   -   -   
bad_IP_checksumbro
  1404148887.011158 CHhAvVGS1DHFjwGM9   192.168.4.149   51293   
72.21.91.29 443 bad_TCP_checksum-   F   bro
  #close2017-10-04-18-48-43
  == Diff ===
  --- /tmp/test-diff.62112.output.baseline.tmp  2017-10-04 18:48:43.0 
+
  +++ /tmp/test-diff.62112.output.tmp   2017-10-04 18:48:43.0 +
  @@ -46,5 +46,6 @@
   #open -XX-XX-XX-XX-XX
   #fields  ts  uid id.orig_h   id.orig_p   id.resp_h   
id.resp_p   nameaddlnotice  peer
   #types   timestring  addrportaddrportstring  string  
boolstring
  -0.00 -   -   -   -   -   truncated_link_header   
bro
  +XX.XX-   -   -   -   -   
bad_IP_checksumbro
  +XX.XXCHhAvVGS1DHFjwGM9   192.168.4.149   51293   
72.21.91.29 443 bad_TCP_checksum-   F   bro
   #close -XX-XX-XX-XX-XX
  ===

  % cat .stderr
  1404148887.011158 warning in 
/Users/slagell/Downloads/bro-2.5.1/scripts/base/misc/find-checksum-offloading.bro,
 line 54: Your trace file likely has invalid IP and TCP checksums, most likely 
from NIC checksum offloading.  By default, packets with invalid checksums are 
discarded by Bro unless using the -C command-line option or toggling the 
'ignore_checksums' variable.  Alternatively, disable checksum offloading by the 
network adapter to ensure Bro analyzes the actual checksums that are 
transmitted.
  1404148887.011158 warning in 
/Users/slagell/Downloads/bro-2.5.1/scripts/base/misc/find-filtered-trace.bro, 
line 48: The analyzed trace file was determined to contain only TCP control 
packets, which may indicate it's been pre-filtered.  By default, Bro reports 
the missing segments for this type of trace, but the 'detect_filtered_trace' 
option may be toggled if that's not desired.

istate.bro-ipv6-socket ... failed
  % 'btest-bg-wait 20' failed unexpectedly (exit code 1)
  % cat .stderr
  The following processes did not terminate:
  
  bro -b ../recv.bro
  bro -b ../send.bro
  
  ---
  <<< [72978] bro -b ../recv.bro
  received termination signal
  >>>
  <<< [72998] bro -b ../send.bro
  received termination signal
  >>>

--

Adam J. 

Re: [Bro-Dev] Performance Enhancements

[Slagell, Adam J]

On Oct 5, 2017, at 2:45 PM, Jim Mellander 
> wrote:

1. Obviously, branch prediction, as mentioned above.  3% speedup for (almost) 
free is nothing to sneeze at.
2. Profiling bro to identify other hot spots that could benefit from 
optimization.
3. Best practices for compiling Bro (compiler options, etc.)
4. Data structure revisit (hash functions, perhaps?)


Jon Siwek was optimizing the main event loop last February, but I believe it 
could only go so far without the new Broker API being integrated. Also, I 
believe there is a need to move off of the select() function. Anyway, there is 
definitely a lot of optimization that could be made there.

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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

Re: [Bro-Dev] Bro working well on Mac OS High Sierra, just a couple test failures

[Slagell, Adam J]

On Oct 4, 2017, at 2:14 PM, Thayer, Daniel N 
> wrote:

The second
failure looks like another race condition (try again a few times and it
will likely pass).

Right you are. 4th time’s a charm. :-)

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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

Re: [Bro-Dev] Broker has landed in master, please test

[Slagell, Adam J]

On May 23, 2018, at 3:12 PM, Michael Dopheide 
> wrote:

Do you want dumb programming questions asked here or on the main Bro list?  
While most people might not need it yet, discussion there might help get more 
people interested or help avoid issues with custom policy conversion.

I think those question belong on the main list which is for using Bro and its 
language. This list is really more about development of Bro itself.

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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

Re: [Bro-Dev] Moving to GitHub?

[Slagell, Adam J]

On May 18, 2018, at 11:11 AM, Robin Sommer 
> wrote:

What I was envisioning is more or less a clean slate: we'd migrate
over a few tickets, but essentially we'd start with an empty list. I
realize that sounds pretty harsh. However, I hardly ever see any
activity on older tickets in JIRA, and I generally believe that the
less open tickets a tracker has, the easier it is for people to
understand what's actually relevant and worth spending cycles on.
Tagging tickets may help, but in the end if everybody just filters 95%
out all the time anyways, I'm not sure what the value is.

That said, I'm open to a real porting effort if people do believe it's
helpful to get all the JIRA tickets into GitHub. What do others think?

Start clean for BIT. Unless it is marked critical, I don’t think it needs to go 
over. If people have tickets of their own they want to move over, it should not 
be too hard to manually recreate a couple.

And after BroCon I think we kill the Jira and wiki completely. We should be 
done with the project management and event tickets by then.

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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

Re: [Bro-Dev] Moving to GitHub?

[Slagell, Adam J]

I am in favor. I would like to still maintain the the Jira and wiki for a 
couple months until we finish up some work. Really just the BPM tickets. 

> On May 15, 2018, at 7:19 PM, Robin Sommer  wrote:
> 
> This has been coming up in various contexts & subgroups of people, and
> I wanted to send it out as a proposal to gather some broader feedback:
> Do we want to move Bro's git repositories and tickets to GitHub?
> 
> Currently we're hosting our Git repositories on our own server at
> git.bro.org; from there, we mirror them to GitHub. For issue tracking,
> we use JIRA at tracker.bro.org. Much of all this is a legacy setup in
> some sense. I believe it would simplify life for both users &
> developers if we moved to GitHub as the authoratative place for both
> code and tickets.
> 
> More specifically, I propose that we:
> 
> 1. Turn the current git repository mirrors on github.com/bro into
>authoritative source for all Bro code. Then we discontinue
>git.bro.org. We can set up up some notification system there
>instead that points people still using the old URLs to GitHub.
> 
> 2. Switch to using GitHub as our primary issue tracker. Giving
>the large amount of old tickets in JIRA, I think we should
>just start from scratch there, porting over just the most
>recent pending tickets. We'd keep the JIRA running in
>read-only mode so that we don't loose the history and can
>always refer back to old tickets.
> 
> 3. Switch to a mostly PR-based development model (i.e., no more
>merge requests tracked separately through tickets), and also
>use GitHub for code review & feedback.
> 
> 4. Make sure it all integrates nicely with Travis CI (which has
>already been set up recently).
> 
> About the only downside I see is that emailing out our standard commit
> notifications won't be quite as smooth anymore: we'd still get them,
> but with a bit of delay as some system would need to be polling for
> changes, rather than being triggered immediately. Not much of a
> problem I think (and with some additional work, we could make them
> push-triggered, too; but probably not worth it).
> 
> What do people think? Any support, or concerns?
> 
> Robin
> 
> -- 
> 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

Re: [Bro-Dev] "bro" name is non-inclusive? (Contribution is rejected based )

[Slagell, Adam J]

The project announced that it is changing its name this fall. We are still in 
the process of doing this.

See http://blog.bro.org/2017/10/a-new-name-for-bro-project.html

There was also a note in early January noting that the project was seeking 
outside help from a branding firm, and so there are delays to the original 
schedule. That was on the main Bro list.

On Mar 9, 2018, at 12:03 AM, Vitaly Repin 
> wrote:

Hello,

I would like to bring your attention to one strange and extremely unexpected 
difficulty I faced
while trying to include user agent parser for bro I have developed (plugin: 
https://github.com/vitalyrepin/uap-bro
 ) into the list of uap implementations 
https://github.com/ua-parser

The request I have made has been rejected: 
https://groups.google.com/forum/#!topic/ua-parser/nJEc6SZIxyU

The reason:

/quote begin/

While I understand that you're not responsible for the unfortunate name of the 
Bro language, and while it might be that the name references an Orwellian "Big 
Brother" more than it refers to bro culture, I still can't get behind including 
or linking to a project in a language that has such a non-inclusive name.

That obviously sucks for the effort you've put into this project, and sucks for 
Bro users that won't be able to find easily. But overall, it sucks even more 
for women who feel excluded from programming because of such poor naming 
choices.

Of course, I’ll happily include your project if the programming language 
changes name.
/quote end/

It sounded very weird for me originally. But I have googled for "bro" and "non 
inclusive" and found this discussion: 
https://news.ycombinator.com/item?id=7121268

Have anybody faced this problem before? Has it been discussed in any way in the 
bro community?

I think it might be a good idea to have at least an article with explanation of 
the origins of the "bro" name and the stand towards inclusiveness. (Not sure it 
will help with ua-parser project, however).

Thanks!
P.S. Sorry for the partial mail sent  a couple of minutes ago.
--
WBR & WBW, Vitaly
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
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