2016-02-09 14:51 GMT+02:00 nitesh kumar <delhinitesh2...@gmail.com>:
>
> ---------- Forwarded message ----------
> From: nitesh kumar <delhinitesh2...@gmail.com>
> Date: Tue, Feb 9, 2016 at 3:56 PM
> Subject: Re: [Simple-evcorr-users] SEC problem
> To: Risto Vaarandi <risto.vaara...@gmail.com>
>
>
> Hey Thanks, for the reply.
> However I am not able to get the idea of using RESET contexts.
>
> Also here it is assumed that the login failure will happen at most every
> hour, that's not my case.
>
Since you didn't actually specify what's your case, I used 1 hour as an
example. Nevertheless, it is easy to change it to any other value -- you
just have to change the context lifetime 3600 (appears twice in the
ruleset) to the value most convenient for you.
Also, in order to explain the principle behind RESET context, I have used
your example events and assumed the maximum allowed time frame between
login failures is 12 hours.
>
>
> Consider this simple log example file, which needs to be monitored.
> Log rotated (daily at 00:00):
>
> [20160122 00:32:58] Login failure for user ABC
>
when this event appears, the context CONTINUOUS_ACTIVITY_ABC does not
exist yet, so the first rule matches. As a result, the context
CONTINUOUS_ACTIVITY_ABC is created with the lifetime of 3 days. Since its
action on expire contains the following action:
pipe '%s' /bin/mail -s 'SSH login alert' root@localhost
an alert e-mail is sent to root@localhost, provided that the
CONTINUOUS_ACTIVITY_ABC context is allowed to expire normally.
Also, the context RESET_MONITORING_ABC is created with the lifetime of 12
hours. When this context expires, it will delete the
CONTINUOUS_ACTIVITY_ABC context, in order to prevent it from sending an
alert e-mail. Note that the lifetime of RESET_MONITORING_ABC context is
extended for another 12 hours each time we see a login failure for ABC.
Therefore, if these login failures keep appearing during 3 days and are
less than 12 hours apart, the RESET_MONITORING_ABC will never expire, and
thus the 'delete' action will be never invoked for CONTINUOUS_ACTIVITY_ABC.
This in turn means that CONTINUOUS_ACTIVITY_ABC will have a chance to
expire normally, and therefore it will be able to send an alert e-mail 3
days after its creation.
[20160122 08:33:58] Login failure for user ABC
>
when this event appears, the first rule no longer matches, since the
context CONTINUOUS_ACTIVITY_ABC already exists. However, the second rule
does match and extends the lifetime of the RESET_MONITORING_ABC context for
another 12 hours.
[20160122 14:34:58] Login failure for user ABC
>
The lifetime of the RESET_MONITORING_ABC context is again extended for 12
hours.
[20160122 21:35:58] Login failure for user ABC
>
The lifetime of the RESET_MONITORING_ABC context is extended for 12 hours.
[20160122 21:35:58] Login failure for user XYZ
>
> Log rotated:
> [20160123 03:32:58] Login failure for user ABC
>
The lifetime of the RESET_MONITORING_ABC context is extended for 12 hours.
Note that at 15:32:59 the RESET_MONITORING_ABC context expires, since we
haven't seen any login failure for ABC during the last 12 hours. Therefore,
the context CONTINUOUS_ACTIVITY_ABC gets deleted, and no alert e-mail will
be issued for the root-user at 20160125 08:33:59.
[20160123 19:32:58] Login failure for user ABC
>
Since the context CONTINUOUS_ACTIVITY_ABC no longer exists, the first rule
matches and the monitoring starts from scratch for the ABC user.
[20160123 21:35:58] Login failure for user XYZ
>
>
At 07:32:59, the RESET_MONITORING_ABC context expires, since no login
failures have been seen for the ABC user during the last 12 hours, and the
context CONTINUOUS_ACTIVITY_ABC gets deleted.
Log rotated:
> [20160124 12:32:58] Login failure for user ABC
>
Monitoring again starts from scratch for user ABC.
It is easy to see that if we would have used the max allowed window of 24
hours between events instead of 12 hours, the RESET_MONITORING_ABC context
would not have expired, and alert e-mail would have been issued at 08:33:59
in January 25. If this is the window you would like to use, you can replace
3600 with 86400 in the ruleset example from my previous e-mail.
kind regards,
risto
>
> Now I want to get alerted for ABC user only as this is happening
> continuously for last three days for him, how many times it has happened is
> irrelevant.
> If you can explain with respect to this example that will be very helpful.
>
> Thanks,
> Nitesh
>
> On Sat, Feb 6, 2016 at 4:45 AM, Risto Vaarandi <risto.vaara...@gmail.com>
> wrote:
>
>> hi,
>> one possible approach for addressing the problem is outlined below (the
>> file contexts have been omitted for the reasons of clarity):
>>
>> type=Single
>> ptype=RegExp
>> pattern=sshd\[\d+\]: Failed .+ for (\S+) from [\d.]+ port \d+ ssh2
>> context=!CONTINUOUS_ACTIVITY_$1
>> desc=Continuous SSH login failures within 3 days for user $1
>> action=create CONTINUOUS_ACTIVITY_$1 259200 \
>> (pipe '%s' /bin/mail -s 'SSH login alert' root@localhost; \
>> delete RESET_MONITORING_$1); \
>> create RESET_MONITORING_$1 3600 (delete CONTINUOUS_ACTIVITY_$1)
>>
>> type=Single
>> ptype=RegExp
>> pattern=sshd\[\d+\]: Failed .+ for (\S+) from [\d.]+ port \d+ ssh2
>> desc=SSH login failure for user $1
>> action=set RESET_MONITORING_$1 3600
>>
>> The ruleset above assumes that the word "continuous" means each login
>> failure happening at most 1 hour after the previous one. In order to
>> implement the monitoring two contexts are used -- CONTINUOUS_ACTIVITY_user
>> exists as long as the given user is monitored, and when this context
>> expires normally after 3 days, it will also emit an alarm about the user.
>> The RESET_MONITORING_user context is employed for ensuring that subsequent
>> login failures are separated by at most 3600 seconds, and if this is no
>> longer the case, the context will delete the CONTINUOUS_ACTIVITY_user
>> context, preventing it from expiring normally and emitting an output alarm.
>>
>> The task of the first rule is to match an SSH login failure if the user
>> is not yet under monitoring, and create the CONTINUOUS_ACTIVITY_user and
>> RESET_MONITORING_user contexts for the user. The second rule matches SSH
>> login failures if the user is already monitored, and it simply extends the
>> lifetime of RESET_MONITORING_user for another 3600 seconds. Therefore, if
>> RESET_MONITORING_user expires, no SSH login failure have been observed for
>> this user for more than 3600 seconds (that's why CONTINUOUS_ACTIVITY_user
>> needs to be deleted from action-on-expire list of RESET_MONITORING_user).
>>
>> Hopefully this example is useful,
>> risto
>>
>>
>>
>> 2016-02-05 10:17 GMT+02:00 nitesh kumar <delhinitesh2...@gmail.com>:
>>
>>> Considering this example from here -
>>> http://simple-evcorr.sourceforge.net/man.html#lbAD
>>>
>>>
>>>
>>> /usr/bin/sec --conf=/etc/sec/sshd.rules
>>> --input=/var/log/secure-current.log
>>>
>>> in order to monitor the /var/log/secure file for sshd events.
>>>
>>> Also, suppose that the /etc/sec/sshd.rules configuration file contains
>>> the following rule for correlating SSH failed login events:
>>>
>>>
>>>
>>> type=SingleWithThreshold
>>>
>>> ptype=RegExp
>>>
>>> context=[_FILE_EVENT_/var/log/secure-current.log]
>>>
>>> pattern=sshd\[\d+\]: Failed .+ for (\S+) from [\d.]+ port \d+ ssh2
>>>
>>> desc=10 SSH login failures within 2 days for user $1
>>>
>>> action=pipe '%s' /bin/mail -s 'SSH login alert' root@localhost
>>>
>>> window=172800
>>>
>>> thresh=10
>>>
>>>
>>>
>>> Requirement – :
>>>
>>> Alert only if this happens for a particular user continuously over 3
>>> days (the count doesn't matter).
>>>
>>>
>>> Problem is can't set a threshold value because it will alert as soon as
>>> it sees those many login failures.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Simple-evcorr-users mailing list
>>> Simple-evcorr-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>>
>>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
