[Bro] help regarding sending scripts

[Jayanth Kannan]

Thanks so much for the long and detailed reply! I am not quite sure which of
the many options you suggested I would go for, but I will keep the list
posted on what I end up doing. I guess I will play with all your options a
little bit, and figure out what works for me.

Thanks,
Jayanth

On Wed, May 14, 2008 at 5:30 PM, Robin Sommer <robin at icir.org> wrote:

> (Late reply, sorry.)
>
> On Fri, May 02, 2008 at 09:30 -0700, you wrote:
>
> > I have a question about sending scripts from one Bro to a second one, and
> > having the second one install the script at run-time, and I was wondering
> > how it would be done. Any help appreciated! Details below.
>
> This requires a longer answer ...
>
> We don't have any prepackaged functionality at the moment to simply
> do a "send everything and install".
>
> What we have are two things:
>
> (a) a built-in function send_id() which will send a particular
>    script-level ID to the remote end, which will install it. That
>    includes variables but also event handlers, script functions,
>    etc. By sending all global IDs successively, one will eventually
>    have sent the whole configuration. (However, that would be best
>    done in C++ code by writing a new built-in function).
>
> (b) If it doesn't need to be network communication, there's the
>    command-line option "--dump-config" that puts the whole
>    configuration into a binary file, which can then be picked up by
>    another instance dynamically (by copying the file into the
>    .state directory of the target Bro). Internally, dump-config
>    essentially does just what I sketched above in (a): iterating
>    through all IDs and serializing them.
>
> So much for the theory. Now the practical part: I think this whole
> set of functionality hasn't been used by anybody in a long time.
> Because of Bro's internal structure, replacing policy scripts at
> run-time is actually pretty tricky and I wouldn't want to bet much
> money that when you try --dump-config, it will "just work". It did
> seem to work well with tests done while implementing all this stuff,
> yet I think it has never been exercised very much and the problems
> are subtle here.
>
> So, depending on what exactly you need, I'd suggest something
> different, which is what the Bro cluster is doing:
>
> (1) many policy changes are limited to fine-tuning, e.g., changing
>    the value of some configuration paramemter, like extending a
>    regexp to match more activity, or changing some detection
>    threshold. Sending just values of script variables works
>    actually pretty well and the Bro cluster limits online updates
>    to such cases: all variables which are declared as &redef can be
>    updated dynamically from remote. This is implemented by the
>    script aux/cluster/policy/send-config.bro in my branch.
>
> (2) another typical policy change is enabling/disabling a certain
>    kind of analysis (such as now loading the HTTP analyzer, or
>    disabling scan detection). My branch has some code to enable
>    this from remote by grouping related events into "event groups"
>    and then allowing to enable/disable event groups remotely. So
>    this can also be done during run-time.
>
> (3) finally, for everyting else (like adding new script code, or
>    changing an existing handler) Bro needs to be reinstarted. The
>    impact of that is mitigated by using persistent state so
>    that at least the most important state information is kept
>    across restarts.
>
>
> Any questions? :-)
>
> Robin
>
>
> --
> Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org
> ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080515/7c745c4d/attachment.html