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). hope this helps, risto > Kind regards, > Agustín > > >
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
