I've discussed changing the Notice::policy notice handling mechanism with a few
people and I think that generally everyone agrees that the current mechanism,
while very powerful, sucks from a usability perspective. This is a good thing
to address now since we're either on the precipice of repeating a mistake to
more frameworks or adapting to a style that is easier to understand. I'm going
to give an example of how I think it could work in an evented model now.
Please shoot holes. :)
These implement the decidedly silly case of sending a notice to an email if the
SSH connection originated locally.
event Notice::policy(n: Notice::Info)
{
if ( n$note == SSH::Login &&
Site::is_local_host(n$id$orig_h) )
{
add n$actions[Notice::ACTION_EMAIL];
}
}
That would be replacement to the current model of this:
redef Notice::policy += {
[$pred(n: Notice::Info) = {
return ( n$note == SSH::Login &&
Site::is_local_host(n$id$orig_h) );
},
$action = Notice::ACTION_EMAIL],
};
Here are some random thoughts about these two approaches in no particular order:
- The evented model (top one) is more Bro-y and easier which is a BIG plus.
- The PolicyItem model (bottom one) has the ability to halt further processing
with the $halt attribute of PolicyItems. I don't think I'm convinced that this
is a huge issue.
- The evented model has latency from the event queue, but I don't think this
is a huge issue. The latency is normally ok. Jon, is it an issue for the file
analysis framework? I don't remember. The actions being applied would be
processed through an event queue too so they will be processed after the policy
events anyway.
- Code block prioritization is built into the evented model using the
&priority attribute. It's specifically implemented for PolicyItem model.
Any thoughts?
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
