I was updating the new notice scripts based on feedback from Robin and I started to change the notice pathway to be event based instead of function based because it provided an easy way for people to extend the built in notice framework with their own functionality but then I noticed this comment...
# This handler is useful for processing notices after the notice filters
# have been applied and yielded an Notice::Action.
I was updating the new notice scripts based on feedback from Robin and I started to change the notice pathway to be event based instead of function based because it provided an easy way for people to extend the built in notice framework with their own functionality but then I noticed this comment...
Personally, I like where you are going with making it easier to extend
the built in framework. There have been multiple occasions where I
have wanted to generate multiple custom email notices from 1 event.
For Example, if event occurs, log it and 'notice' as usual, but if it
is a notice contains an old version of 'Java' also email the help desk
at a different email address than the one that broctl knows to use. I
would also want to create a custom message format. This was easily
accomplished with a cron'd shell script that scrapes mail.log every
ten minutes, checks a static file to see if the host was already
alerted on, if not, add host to the file and send the email
identifying the time, host and version of software that needs to be
patched. I have figured there were ways to accomplish this in the
current release of bro, but took the simplest route.
# This handler is useful for processing notices after the notice filters
# have been applied and yielded an Notice::Action.
#
# It's tempting to make the default handler do the logging and
# printing to notice_file, rather than NOTICE. I hesitate to do that,
# though, because it perhaps could slow down notification, because
# in the absence of event priorities, the event would have to wait
# behind any other already-queued events.
event notice_action(n: Notice::Info, action: Notice::Action)
{
}I think that doing the notification and printing through an event has a lot of benefits but I see the downside too. What does everyone else think? Especially whomever wrote that comment.
What kind of delay or slow down are we talking here? Seconds or
minutes? I can't imagine it being more than a minute, which would be
the least of my worries as long as the time stamp in the notice was
accurate.
I didn't write the comment, but figured if you opened it up to
"everyone"... thanks for letting me share. 
Will
What kind of delay or slow down are we talking here? Seconds or
minutes? I can't imagine it being more than a minute, which would be
the least of my worries as long as the time stamp in the notice was
accurate.
I'm pretty sure I'm the one who wrote the comment, and the concern is
delays of 100s of msec, not even seconds. The reason is because one of
the notice actions might be some form of "drop connectivity", and for
automated malware the msec's matter regarding how quickly the drop goes in.
That said, a better way of dealing with this concern would be to have
a solid notion of event prioritization.
Vern
Personally, I like where you are going with making it easier to extend
the built in framework. There have been multiple occasions where I
have wanted to generate multiple custom email notices from 1 event.
I have frequently run into very similar trouble when working with the current notice framework.
What kind of delay or slow down are we talking here? Seconds or
minutes? I can't imagine it being more than a minute, which would be
the least of my worries as long as the time stamp in the notice was
accurate.
Hopefully less than seconds even but there's no way to know what your event queue will look at any specific moment.
I didn't write the comment, but figured if you opened it up to
"everyone"... thanks for letting me share.
I'll count that as one vote for flexibility over immediate immediacy (since in most cases it would still be very quick).
Perhaps we could implement the notice pathway as events and then make a way to inject certain events higher in the event queue if it turns out to be problematic for anyone in the future.
Thanks,
.Seth
The reason is because one of the notice actions might be some form
of "drop connectivity", and for
automated malware the msec's matter regarding how quickly the drop goes in.
Ohhh. That's a good point which I hadn't even considered.
That said, a better way of dealing with this concern would be to have
a solid notion of event prioritization.
What about a new keyword to indicate that the event should be placed at the top of the event queue?
immediate_event notice_action(n, ACTION_DROP);
.Seth
I just worked around this problem by allowing users to add anonymous functions to a set of functions that get called for each notice. It's sort of a parallel track to the event based pathway that is only used when things need to be run closer to real time.
It will at least give us the ability to support the near realtime constraints of the drop script and the easy event based extension mechanism.
.Seth
I just worked around this problem by allowing users to add anonymous functions to a set of functions that get called for each notice.
Hmmm, this suggests another easy fix, which is that NOTICE itself genereates
an event, such as secondary_notice_event, and thus that want to hook
non-time-critical stuff on can use that.
Vern
Yep, that's essentially how it's done with emphasis on the event based notice extension and the function based notice code there in case someone needs it.
I'm going to be committing a lot of updates to the notice code in just a minute if you'd like to take a look at it.
.Seth