One way to alter the policy Bro executes is of course to directly edit the scripts. When this can be avoided, however, that is preferred, and Bro provides a pair of related mechanisms to help you specify refinements to existing policies in separate files.
The first such mechanism is that you can define multiple
handlers for a given event. So, for example, even though the standard
ftp analyzer (bro-dir/policy/ftp.bro
)
defines a handler for ftp.request
, you can define another handler
if you wish in your own policy script, even if that policy script loads
(perhaps indirectly, via the mt
module) the ftp
analyzer.
When the event engine generates an ftp_request event, both
handlers will be invoked.
Deficiency: Presently, you do not have control over the order in which they are invoked; you also cannot completely override one handler with another, preventing the first from being invoked.
Second, the standard policy scripts are often written in terms of
redefinable variables. For example, ftp.bro
contains
a variable ftp_guest_ids
that defines a list of usernames
the analyzer will consider to reflect guest accounts:
const ftp_guest_ids = { "anonymous", "ftp", "guest", } &redef;
While “const
” marks this variables as constant at run-time,
the attribute “&redef
” specifies that its value can be
redefined.
For example, in your own script you could have:
redef ftp_guest_ids = { "anonymous", "guest", "visitor", "student" };
instead. (Note the use of “redef” rather than “const”, to indicate that you realize you are redefining an existing variable.)
In addition, for most types of variables you can specify incremental changes to the variable, either new elements to add or old ones to subtract. For example, you could instead express the above as:
redef ftp_guest_ids += { "visitor", "student" }; redef ftp_guest_ids -= "ftp";
The potential advantage of incremental refinements such as these are that if any other changes are made to ftp.bro's original definition, your script will automatically inherit them, rather than replacing them if you used the first definition above (which explicitly lists all four names to include in the variable). Sometimes, however, you don't want this form of inheriting later changes; you need to decide on a case-by-case basis, though our experience is that generally the incremental approach works best.
Finally, the use of prefixes provides a way
to specify a whole set of policy scripts to load in a particular context.
For example, if you set $BRO_PREFIXES
to “dialup”,
then a load of ftp.bro
will also load dialup.ftp.bro
automatically (if it exists). See Run-time environment for further discussion.