Thank you Risto!!! Your explanation solved some of my doubts.xD.
Regards. Great work!. 2015-12-03 18:45 GMT+01:00 Risto Vaarandi <risto.vaara...@gmail.com>: > Consider the following example with a shorter window of 60 seconds and > theshold of 3: > > type=EventGroup > ptype=regexp > pattern=POST ([0-9.]+) (.*) > context=!seen_connection_from_$2_ip_$1 > desc=Check for connection by $2 > init=create seen_connection_from_$2 > count=alias seen_connection_from_$2 seen_connection_from_$2_ip_$1 > end=delete seen_connection_from_$2 > window=60 > thresh=3 > action = write - 'user $2 logged in from 3 different ips' > > Suppose you see the following events: > > 12:00:03 POST 10.1.1.1 Bob > 12:00:54 POST 10.1.1.2 Bob > 12:01:06 POST 10.1.1.3 Bob > 12:01:08 POST 10.1.1.1 Bob > 12:01:12 POST 10.1.1.4 Bob > > When you look at these events, you will notice that by the end of the 60 > second window at 12:01:03, there are only 2 events in the window. > Therefore, the counting operation which runs for user Bob will move the > window forward to 12:00:54 (the timestamp of the second event), leaving the > first event out of the window. In other words, after window sliding the > operation has only one event under consideration: > > 12:00:54 POST 10.1.1.2 Bob > > It is easy to see that the event at 12:01:06 will be processed by the > operation and will increase the event counter, since the IP address > 10.1.1.3 has not been observed before (there is no context alias > seen_connection_from_Bob_ip_10.1.1.3). > > However, when the event > > 12:01:08 POST 10.1.1.1 Bob > > appears, it will not match the rule, since the context alias > seen_connection_from_Bob_ip_10.1.1.1 already exists. Unfortunately, this > alias was created for event at 12:00:03 which has been already shifted out > from the sliding window. On the other hand, since the IP addresses of > events at 12:00:54, 12:01:06 and 12:01:08 are all different, we have > actually seen three accesses for the same user with different IP's. In > order to trigger the output action, an event with an IP address not seen > since the start of the operation (i.e., since 12:00:03) has to appear. > Therefore, when the event > > 12:01:12 POST 10.1.1.4 Bob > > appears, you will see the 'write' action triggered. > > If you would like to avoid this issue, you could use a variant of the > ruleset than John suggested: > > type=SingleWithThreshold > ptype=regexp > pattern=POST ([0-9.]+) (.*) > context=!seen_connection_from_$2_ip_$1 > continue=TakeNext > desc=Check for connection by $2 > action=write - 'user $2 logged in from 3 different ips' > window=60 > thresh=3 > > type=Single > ptype=regexp > pattern=POST ([0-9.]+) (.*) > context=!seen_connection_from_$2_ip_$1 > desc=create the context for user $2 ip $1 > action=create seen_connection_from_$2_ip_$1 60 > > In the case of the above ruleset, we are not using one context with many > aliases, but many independent contexts which have independent lifetimes. > Since the lifetime of each context seen_connection_from_$2_ip_$1 is 60 > seconds and starts when the corresponding event is first seen, sliding the > 60-second window further can only leave events older than 60 second out > from the window, which in turn means that their contexts expire when they > are left out. Therefore, they would be counted again when they appear in > the new window, and we don't have the issue we had with the EventGroup rule. > > This creates another interesting question -- once the operation has > produced an output action and terminates, some > seen_connection_from_$2_ip_$1 contexts might exist longer that the > operation itself. So how to get rid of these contexts, so that the next > potential operation for the same user would start with the clean state? For > this, you could use the following modification of the previous approach: > > type=SingleWithThreshold > ptype=regexp > pattern=POST ([0-9.]+) (.*) > context=!seen_connection_from_$2_ip_$1 > continue=TakeNext > desc=Check for connection by $2 > action=write - 'user $2 logged in from 3 different ips'; \ > create stop_contexts_for_$2 > window=60 > thresh=3 > action2=getsize %size clean_contexts_for_$2; while %size ( \ > shift clean_contexts_for_$2 %context; delete %context; \ > getsize %size clean_contexts_for_$2 ); \ > delete clean_contexts_for_$2; \ > delete stop_contexts_for_$2 > > type=Single > ptype=regexp > pattern=POST ([0-9.]+) (.*) > context=!seen_connection_from_$2_ip_$1 && !stop_contexts_for_$2 > desc=create the context for user $2 ip $1 > action=create seen_connection_from_$2_ip_$1 60; \ > add clean_contexts_for_$2 seen_connection_from_$2_ip_$1 > > Here, the second rule stores all context names for the given user to > clean_contexts_for_$2, and when the SingleWithThreshold operation for the > user terminates, it will execute the 'action2' field. Note that 'action2' > is not very frequently used in SEC rule examples and is a non-mandatory > field, but when you define it, it is triggered when the operation > terminates, provided that the 'action' field has been previously executed > by the operation. > > What the 'action2' field does is the following -- with the while () > action, it shifts strings out from the event store of the context > clean_contexts_for_$2 (these strings are the names of other contexts). At > each iteration, the string which is shifted out is treated like a context > name, and the corresponding context is deleted. At the end of each > iteration (and before the while-loop starts), the number of context name > strings in clean_contexts_for_$2 is stored to the variable %size (it is > easy to see that each iteration subtracts 1 from the value of %size). When > the value of %size becomes 0, the while loop will terminate. > > Also, the last ruleset example employs the stop_contexts_for_$2 context > which is created when the output action is triggered. This is useful when a > large number of matching events with different events come in for the same > username, because it stops the creation of new contexts after the operation > has reached the threshold. > > Last but not least, I hope my examples do not contain typos :) I have > tested them briefly while typing this letter, and I'd recommend to verify > them in your own test environment. > > kind regards, > risto > > > > 2015-12-03 17:39 GMT+02:00 Jaren Peich <burkol...@gmail.com>: > >> >> 2015-11-25 23:24 GMT+01:00 Risto Vaarandi <risto.vaara...@gmail.com>: >> >>> typo -- >> >> >> Hi, >> >> Thank you for your help!. I´ve tested and it works well. >> When do you mean that the "window slides" means that events continues >> like 80 minutes and it only generate one alert because the context still >> exists? and not 2 events till the event dissapear for a long time? >> >> Regards. >> > >
------------------------------------------------------------------------------
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
