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.
>
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
