bro cluster notification options

Zeek
1

We're moving from a single production Bro system to a Bro cluster while
also upgrading to 1.5.2. I've got a few questions about customizing
notifications.

1) We have a situation where one of the Bro workers may be monitoring a
shared link. We want all the events sent centrally to the manager still,
but there's a request that an outside entity have access to that worker's
logs as well. One option is to set "redef suppress_local_output = F;" and
export the logs from the worker directly, but there's also the issue of
email alerts. Is there an option to specify a different mail_dest for a
given worker node?

2) Related to that, we want to send some alerts to different email
addresses. Our use case here is sending off new, untuned alerts to a
different address than our normal incident response list. One option is
to just write a function that does that emailing through a script, but I'm
just checking to make sure there isn't a built-in variable for that.

Thanks,
Dop

2

The direct answer to that question is, no, there's not right now, but
it wouldn't be hard to add.

However, there's a more general question here how to support such
setups, as there are a number of things involved it seems. For
example, what about alarms that cross the "worker boundary", like
scans? Do you want them to go to the external entity? Perhaps only if
one of their IPs gets scanned (which would be tricky though).
Generally speaking, for all things not directly done on a single
worker, but either correlated across workers (like scans), or derived
on the manager (like notice policy), things could get a bit murky.

Depending on the specifics of what you're monitoring, I can see
another way of doing this: running the one worker independently of the
others (i.e., no shared proxy with the others), and adding a second
"slave manager". That guy would be receiving just stuff from this
special worker, and could be configured with its own mail_dest, notice
policy etc; it would also do its own logging, so you don't need to
enable that locally on the worker. At the same time, the "normal"
manager would just keep running as usual, being connected to that
worker as well, and handle all the configuration (as well as also
receive the logs).

Generalizign this furher, we're getting to something Seth has been
thinking about quite a bit already: a "deep cluster" where broctl sets
up a hierarchy of worker/proxies/managers for monitoring different
sub-parts of an organisation's network, all controlled for a central
location.

Robin

3

Not a variable, but there's a function email_notice_to() you can use
in your notice_policy, like this:

    redef notice_policy += {
        [$pred(n: notice_info) = {

            if ( n$note == HTTP::HTTP_SensitiveURI )
                {
                if ( /INTERESTING-URL/ in n$URL )
                    email_notice_to(n, "guy@interested.in.this.url");
                }

            return F;
        };

This mails out matching notices to the given address in addition to
normal handling. If you only wanted to mail them out, but not be
reported locally, that normal handling could just set them to
NOTICE_FILE.

Robin