Closed (fixed)
Project:
Login Security
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
21 Sep 2009 at 00:57 UTC
Updated:
26 Jun 2014 at 14:55 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
ilo commentedI agree with EugenMayer that prior to blocking (soft or hard) an advice is also interesting for the administrator to know that something is going on the site, so I'll try to introduce this one for the 1.0 release also.
Comment #2
ilo commentedSO, I've created a new variable that can be used, containing the total tracking count in the time window..
What is missing in the description of the feature , EugenMayer is what should fire this notice, and when shoul I reset it. E.g. if we just find more than 30 invalid logins in the track time then the alert should be sent.. and wait for that count to be < 10 to reset the 'admin alerted' status and be able to the notification.
To help in the configuration of this feature, What are the options you want to consider?
- checkbox to enable or disable the email submission.
- textfield with 'threshold' to alert the admin..
- textfield with 'reset' to reset status? <- this one I'm not so sure, we can use 30% of the threshold variable to consider that attack has stopped.
For a more accurate ongoing attack detection, instead of using the "tracking time" window variable we can introduce another one, but I'm not so sure if it worths so much granularity.
Comment #3
deekayen commentedFirst, it seems like there should be a where clause on the query in #3.
Second, what's wrong with an email going to an admin when a user is blocked that contains the IP address of the last failed attempt? That seems like it'd just be 6-7 lines of code.
Comment #4
ilo commentedmm.. I'm trying to get the count of the total entries in the tracking table.. the WHERE will be WHERE 1 ?
If the idea is to notify a block operation, you can just put the %ip variable in the current email so you amy know the IP address of the host doing the password guess..
But the idea is not to notify on block, but to notify even if you don't have blocking enabled, so admin gets alerted about suspicious login activities I guess..
Comment #5
ilo commentedTo explain a little bit this patch, these are the changes in the README:
---
6.- For the onoing attack detection, all the tracked events are taken in count.
The system detects an ongoing attack and notices the admin about that. It will
remain in attack mode (no more notices will be sent) untill the attack is no
longer detected. This will happen when the total number of tracked events is
below 'maximum allowed to detect ongoing attack' / 3. Since then, once the
threshold value is reached again, a new notification will be set in the log
or sent by email.
E.g Say you put 1 hour of track time and a maximum number of login failures
to detect ongoing attack of 20. This means that if during the last hour there
are more than 20 invalid login attemps an attack is detected. A log entry is
created to notice the detected attack, and system switches to 'attack' status,
where no more notices about the attack will be logged or sent. After sometime
the attack stops. And once the number of invalid login attemps for this last
hour is below 1/3 of this maximum: invalid attemps are below 6 (20 / 3 for
the example) a normal status is recovered. If a new attack is detected, the
module will alert again about it.
---
I've tested and seems to work fine, not breaking any other protection. As always I need a little review for the english grammar..
Comment #6
ilo commentedCommited to 6.x-1.x-dev.
I have commited because of #583978: Consolidate strings and grammar and export .pot file, any issue regarding english grammar should go there.