I have been thinking and trying different things but for now, it appears that if we are to share policies around, there is no easy way to be able to distribute input-files along with policy files.
Basically, right now I use
redef Scan::whitelist_ip_file = "/usr/local/bro/feeds/ip-whitelist.scan" ;
and then expect everyone to edit path as their setup demands it and place accompanying sample file in the directory or create one for themselves - this all introduces errors as well as slows down deployment.
Is there a way I can use relative paths instead of absolute paths for input-framework digestion. At present a new-heuristics dir can have __load__.bro with all policies but input-framework won't read files relative to that directory or where it is placed.
redef Scan::whitelist_ip_file = "../feeds/ip-whitelist.scan" ;
Something similar to __load__.bro model
Also, one question I have is should all input-files go to a 'standard' feeds/input dir in bro or be scattered around along with their accompanied bro policies (ie in individual directories )
Something to think about as with more and more reliance on input-framework i think there is a need for 'standardization' on where to put input-files and how to easily find and read them.
Aashish
Playing with Bro packages and bundles, there's one thing where I ended
up a bit confused and that's the meta data. We have two places right
now that store meta data about a package: there's the central set
stored with the package source (bro-pkg.index), and then there's the
set coming with the package itself (bro-pkg.meta). However, I'm a bit
lost what goes where, and which information should remain accessible
once things are bundled up.
Seems bro-pkg.meta generally has "description" and "tags" at least.
However, that information seems lost once I bundle a package up and
don't have access to the index repository anymore. There doesn't seem
to be an expectation that bro-pkg.meta would have similar information,
so there's nothing there to fill the gap.
Then, bro-pkg.meta has a "version" field (the docs show that as the
one field to put in there). I believe that version isn't really used
anywhere other than showing it as part of the meta data output in
"info". In Python it also maps to PackageInfo.metadata_version. But
then there's also PackageStatus.current_version, which is from git
(although I'm not sure how I would actually set that; is it just any
tag?).
Once packages go through bundle/unbundle I cannot run "info" when I'm
offline, and hence I don't get some of the information anymore (same
from Python with PackageInfo I believe)
Ideally, what I'd like to have is a single interface (speaking in
Python API terms) for a package that gives me all the meta-data
consistently, pulling it out from where's it's stored and maintaining
it when bundling. For things like "description", "tags", it could pull
them out of bro-pkg.index by default, and maybe override them from
bro-pkg.meta if they are defined there (so that one can set them even
if there's no package source to begin with). And bundles would then
carry the information through, probably inside their manifest. For
version information, bro-pkg could start with the git branch/tag but
override it with values from bro-pkg.index and bro-pkg.meta if defined
there. That way people could choose how to do their versioning. The
API would just offer a single version() doing the right thing, and
"bro-pkg info" would show that.
Does this make sense? I'm not quite sure about the reasons for the
current structure, I'm mostly thinking from the perspective of
information about the package I'd like to have access to easily, and
where it's coming from.
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
Could folks take a look at NEWS and see what's missing?
Couple of things I think we should add at least:
- Document the cluster framework's new logger node, with an
example how to use it.
- Document the recent intel framework updates.
- Add BroControl news/changes.
Any takers for these?
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
An argument was made in a GitHub issue [1] that the decentralized model for packages where each package is a distinct git repo may be inconvenient for some use-cases and that allowing multiple packages to reside in single git repo would be better.
I think supporting that would significantly change the design and goals of the package manager, so I wonder what ideas/thoughts others have about the current model vs. the proposed one?
- Jon
[1] https://github.com/bro/package-manager/issues/2
Would it be possible (also suggestion on what might be the best way) to add an event/execute a script once log-rotation/compression is complete.
Use case: We archive the logs to a mass storage while leaving a local copy for N days. Right now, its a guessing game on when to run the nightly archive (ie once log compression and local rotation is complete).
thanks,
Aashish
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 <slagell(a)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) <hlin33(a)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/)
> DEPEND (http://depend.csl.illinois.edu/)
> ECE, Uni. of Illinois at Urbana-Champaign
>
> _______________________________________________
> bro-dev mailing list
> bro-dev(a)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."
>
>
>
>
>
>
>
>
>
--
Hui Lin
Ph.D. Candidate (http://hlin33.web.engr.illinois.edu/)
DEPEND (http://depend.csl.illinois.edu/)
ECE, Uni. of Illinois at Urbana-Champaign
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
I just finished a branch that adds support for TLSv1.3 to Bro (branch
topic/johanna/tls13, important commit:
https://github.com/bro/bro/commit/fdef28ce7c3455d43267ab07dbb8ad96c9ea3890).
What do people think of the idea of adding that patch to the upcoming Bro
2.5 release?
I know that we are quite late in the current release process and that we
should not really make any feature changes after releasing the beta. It
would, however, be neat to be able to support TLSv1.3 starting the moment
that people actually start to use it; without that support, we will only
have empty lines in ssl.log for these connections. Furthermore, the
changes that are needed to support TLSv1.3 have nearly no interaction with
the code that is used to parse earlier versions of TLS. Even if there are
problems with the code (or if the on-the-wire format still changes), the
only thing that should happen is that binpac throws errors. Which is
exactly what already happens now when throwing TLSv1.3 sessions at the
current master versions of Bro.
Thanks,
Johanna
I see notifications as following:
----- Forwarded message from Xxxxxxx -----
Date: Mon, 3 Oct 2016 11:54:39 -0700 (PDT)
From:
To:
Subject: [bro-cluster] archive log failure
Unable to archive one or more logs in directory:
/usr/local/bro/spool/tmp/post-terminate-worker-2016-10-03-09-40-35-36665
Check the post-terminate.out file in that directory for any error messages.
--
[Automatically generated.]
But then there is no spool/tmp/post-terminate-*
However, in my /usr/local/bro/logs directory I see these folders emerge:
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-9
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-5
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-8
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-7
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-10
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-4
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-3
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-2
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-1
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20rk-5-6
drwxr-xr-x 2 bro bro 512B Oct 3 11:54 20ox-5-
drwxr-xr-x 2 bro bro 6.5k Oct 3 11:56 2016-10-03
drwxr-xr-x 2 bro bro 512B Oct 3 12:01 20na--
Now, I do use the followign setting in broctl.cfg:
# change log naming
MakeArchiveName = /usr/local/bro-cpp/common/scripts/makelocal-archivename-2.1
However above been there forever and I don't recall these archive failure messages or these directories show up until I moved to : bro version 2.5-beta-debug
Aashish
