Hi Risto and John,
I think the context solution with duration is the best solution.
Thank you very much for your contributions!
Kind regards
________________________________
Hi Risto:
In message
<cagfjscmizqkbqpvn9mfphmeybdfvayypbfwv33gplxy1do3...@mail.gmail.com> ,
Risto Vaarandi writes:
>hi Agustin,
>> Hi Risto,
>>
>> Thank you very much for your help.
>> I have another question related to this problem.
>>
>> Suppose we have the next entry in less than 60 seconds:
>> EVENT_TYPE_A 1.1.1.1 <--- the beginning of input for SEC
>> EVENT_TYPE_A 2.2.2.2
>> EVENT_TYPE_B 1.1.1.1
>> EVENT_TYPE_B 2.2.2.2
>> EVENT_TYPE_C 1.1.1.1
>> FINISH <--- (FINISH is also an event) the
>> end of input for SEC
>>
>> We have the following rule:
>> Rule 1:
>> type=EventGroup2
>> ptype=RegExp
>> pattern=EVENT_TYPE_A ([\d.]+)
>> continue=TakeNext
>> ptype2=RegExp
>> pattern2=EVENT_TYPE_B ([\d.]+)
>> continue2=TakeNext
>> desc=Events A and B observed for IP $1 within 60 seconds
>> action=logonly Events A and B observed for IP $1
>> window=60
>>
>> Rule 2:
>> type=EventGroup3
>> ptype=RegExp
>> pattern=EVENT_TYPE_A ([\d.]+)
>> continue=TakeNext
>> ptype2=RegExp
>> pattern2=EVENT_TYPE_B ([\d.]+)
>> continue2=TakeNext
>> ptype3=RegExp
>> pattern3=EVENT_TYPE_C ([\d.]+)
>> continue3=TakeNext
>> desc=Events A, B and C observed for IP $1 within 60 seconds
>> action=logonly Events A , B and C observed for IP $1
>> window=60
>>
>> We get the following output:
>> Events A and B observed for IP 1.1.1.1
>> Events A and B observed for IP 2.2.2.2
>> Events A , B and C observed for IP 1.1.1.1
>>
>> I'm waiting for the next output:
>> Events A and B observed for IP 2.2.2.2
>> Events A , B and C observed for IP 1.1.1.1
>>
>> The idea is to reduce the output.
>>
>
>One approach that is relatively easy to implement is the following -- when
>the first message for an IP address is generated, a context is created for
>this IP address which will prevent further matches by rules for this IP.
>Also, in all rule definitions, pattern* fields would be complemented with
>context* fields which verify that the context for current IP address does
>not exist. For example, in the following ruleset repeated messages for the
>same IP address are suppressed for 300 seconds (that's the lifetime of
>SUPPRESS_<ip> contexts):
>
>type=EventGroup2
>ptype=RegExp
>pattern=EVENT_TYPE_A ([\d.]+)
>context=!SUPPRESS_$1
>continue=TakeNext
>ptype2=RegExp
>pattern2=EVENT_TYPE_B ([\d.]+)
>context2=!SUPPRESS_$1
>continue2=TakeNext
>desc=Events A and B observed for IP $1 within 60 seconds
>action=write - %s; create SUPPRESS_$1 300
>window=60
>
>type=EventGroup3
>ptype=RegExp
>pattern=EVENT_TYPE_A ([\d.]+)
>context=!SUPPRESS_$1
>continue=TakeNext
>ptype2=RegExp
>pattern2=EVENT_TYPE_B ([\d.]+)
>context2=!SUPPRESS_$1
>continue2=TakeNext
>ptype3=RegExp
>pattern3=EVENT_TYPE_C ([\d.]+)
>context3=!SUPPRESS_$1
>continue3=TakeNext
>desc=Events A, B and C observed for IP $1 within 60 seconds
>action=write - %s; create SUPPRESS_$1 300
>window=60
>
>With these rules, the following output events would be produced for your
>example input:
>Events A and B observed for IP 1.1.1.1 within 60 seconds
>Events A and B observed for IP 2.2.2.2 within 60 seconds
>
>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.
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?
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
