hi John,
Hi Risto:
>
> ...
>
>
>
> >However, if you would like to suppress the output message that is
> generated
> >on 3rd input event and rather generate an output message "Events A , B and
> >C observed for IP 1.1.1.1" on 5th input event, it is not possible to
> >achieve that goal with EventGroup (or any other) rules, since after seeing
> >the 3rd event, it is not possible to know in advance what events will
> >appear in the future. In other words, SEC rules execute actions
> immediately
> >when a first matching set of events has been seen, and it is neither
> >possible to reprocess past events nor postpone actions in the hope of
> >better future match (which might never occur).
>
> I agree SEC has no built in delay mechanism for actions, you can
> create a context that expires in the future and runs an action on
> expiration.
>
> How about creating a delayed reporting context rather than
> writing:
>
> Events A and B observed for IP 1.1.1.1
>
> in EventGroup2, use an action like:
>
> create report_$1_event_A_and_B 60 (write - %s)
>
> and add the action
>
> destroy report_$1_event_A_and_B
>
> to EventGroup3.
>
That's another nice way for handling the problem. In my previous post, I
suggested to store all events for the same IP into the same context and
then use some condition to select most relevant event, but this approach
looks more lightweight and easy-to-use.
> This should prevent the reporting of A and B when A, B and C are
> seen. It will delay the reporting of A and B until the window to find
> A, B and C is done. This may not be desirable, but the laws of physics
> won't permit another option.
>
> Is there a variable that records how much time is left in the window?
> If so you can have the report_$1_event_A_and_B expire in that many
> seconds rather than in 60 seconds. (I assume the window expiration
> times of both EventGroups will be the same since they are triggered by
> the same event.)
>
> This is a bit of a hack but I think ti will work to delay the write
> action.
>
> Thoughts?
>
If one wants to query the number of remaining second in the event
correlation window, there is no such variable, but there is 'getwpos'
action for finding the beginning of the event correlation window of any
operation (in seconds since Epoch). For example, if one includes the
following action in the rule definition
getwpos %window 0
and this action gets executed by the event correlation operation, then the
%window variable is set to the time when the calling operation started.
Since %u action list variable holds a timestamp for the current moment (in
seconds since Epoch), one can calculate remaining seconds in the 60 second
window as follows:
getwpos %window 0; lcall %size %u %window -> ( sub { 60 - ($_[0] - $_[1]) }
)
The above function will find the difference between %u and %window
variables, and subtract the result from 60. If above action list gets
invoked during the last second of operation's lifetime, the function will
return 0, and using this value directly for context lifetime will create a
context with infinite lifetime. To handle this special case, one could
modify the above function to always return a positive value (e.g., 1
instead of 0).
kind regards,
risto
>
> Have a great week.
> --
> -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
