Replies: 2 comments 7 replies
-
How about extending the existing EDIT: That might end-up a bit more repetitive and verbose than your first proposal, particularly if all signatures are dispatched to different events as the string parameter becomes redundant. However, the
|
Beta Was this translation helpful? Give feedback.
-
@awelzel given we've converged, what's next? Add an issue for this to the backlog? (Fine by me if you want to take it over from here. Fine if not, too :-)) |
Beta Was this translation helpful? Give feedback.
-
Currently, Zeek's signature framework supports the generation of a single event:
and when writing signatures, all that's specified is the
msg
that goes with that event:We've been developing Zeek scripts that need to dispatch on the particular signature matched. Currently this requires a bunch of comparisons of
msg
(and these can happen in different instances ofsignature_match
event handlers, depending on the modularity associated with the content). An extension to deal with this would be to allow theevent
specifier in a signature to optionally be the name of an event to generate, rather than a string to associate with it:(the
event
value could instead be a string like now, in which casesignature_match
is generated), or perhaps:where the given event would have to have a common type signature (which for the second example could be the same as the
signature_match
event).This seems handy and pretty straightforward to implement. Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions