I added some functionality to moodle that logs failed logins, and notifies users how many failed attempts there have been since last login, when they next log in.
I also added a new admin page to view the logs (similar to course/log.php).
There's a patch available at http://nzvle.eduforge.org/loginlog.patch - it's against the latest dev cvs version.
Penny
Hi Penny,
I am still a web neophyte so I request that you have patience with my questions. I have seen code like this before (a different mod, of course) and I did not really know what to do with it. If you can help me out now it would be appreciated,
Couse you also post an image as to how the log page is suppose to look?
Thanks in advance.
WP1
I am still a web neophyte so I request that you have patience with my questions. I have seen code like this before (a different mod, of course) and I did not really know what to do with it. If you can help me out now it would be appreciated,
- How do I install this code?
- Is it through SSH??
- If it is through SHH
- What do I name the file?
- What command do I use?
Couse you also post an image as to how the log page is suppose to look?
Thanks in advance.
WP1
What I posted yesterday is a diff between my moodle code and the latest development moodle version. In order to use it, you would need to ssh in and apply the patch using a program called patch - ( tutorial on diff and patch at http://www.kegel.com/academy/opensource.html )
However, patching your code may not work if you're running a different version to the one my patch is aimed at. If you're running the latest stable version (1.3.2) for example, there's likely a whole lot different to the version my patch is aimed at (1.4)
Let me know what version of moodle you're running & I'll grab a copy and see what happens with the patch.
I've made a screenshot of the admin page -
Also! I changed the patch this morning after realising something in the middle of the night (always the way!) so if you downloaded it already, you'll need to grab it again.
Penny
However, patching your code may not work if you're running a different version to the one my patch is aimed at. If you're running the latest stable version (1.3.2) for example, there's likely a whole lot different to the version my patch is aimed at (1.4)
Let me know what version of moodle you're running & I'll grab a copy and see what happens with the patch.
I've made a screenshot of the admin page -
Also! I changed the patch this morning after realising something in the middle of the night (always the way!) so if you downloaded it already, you'll need to grab it again.
Penny
Hi Penny!
Thank you so much for taking the time to respond, for explaing the process and providing an image of the page.
I am running v1.4 Dev as well as v1.3.1 and v1.3.2.
Where can I DL the "patch" program?
Thanks again.
WP1
Thank you so much for taking the time to respond, for explaing the process and providing an image of the page.
I am running v1.4 Dev as well as v1.3.1 and v1.3.2.
Where can I DL the "patch" program?
Thanks again.
WP1
( emailed more detailed instructions )
QUOTE:
"( emailed more detailed instructions )". Penny Leach
Hi Penny!
Did you ever e-mail me the additional instructions? I have not received anything as of yet. Could you e-mail them again?
Thanks in advance.
WP1
"( emailed more detailed instructions )". Penny Leach
Hi Penny!
Did you ever e-mail me the additional instructions? I have not received anything as of yet. Could you e-mail them again?
Thanks in advance.
WP1
If you are running linux or any unix, patch is probably there, or available in one of the base packages. If you are using windows, get one of the many unix tools for windows packages, either cygwin or unixtools.zip.
If you are not familiar with the process, I strongly recommend you get a unix sysadmin to lend a hand and show you around. It'll save you a ton of hassles.
cheers,
martin
If you are not familiar with the process, I strongly recommend you get a unix sysadmin to lend a hand and show you around. It'll save you a ton of hassles.
cheers,
martin
Thanks, Penny! 
Looks like a fair bit of work there, but I can't currently see how useful it is to know that information. ie if I see 9 failed login attempts it probably just means my password is hard to guess, but that would probably scare neophytes. If the cracker got in on the 10th try, then the lastlogin will be updated, so users would see "0 attempts" anyhow ... same thing if the cracker gets in on their first attempt.
Perhaps you can explain the logic leading to the development of this feature.
If the feature was to get added to Moodle I would like to see it using the existing log table rather than a new one. All we need to do then is add a little menu to the site log viewer to make it easier to select special events of interest. Does that make sense?
Looks like a fair bit of work there, but I can't currently see how useful it is to know that information. ie if I see 9 failed login attempts it probably just means my password is hard to guess, but that would probably scare neophytes. If the cracker got in on the 10th try, then the lastlogin will be updated, so users would see "0 attempts" anyhow ... same thing if the cracker gets in on their first attempt.
Perhaps you can explain the logic leading to the development of this feature.
If the feature was to get added to Moodle I would like to see it using the existing log table rather than a new one. All we need to do then is add a little menu to the site log viewer to make it easier to select special events of interest. Does that make sense?
Moodle today lacks any kind of mechanism to warn against dictionary and 'soft' DoS attacks. This is a bit of a worry when deploying Moodle in large scale for distance education.
To be fair, most web-based tools are lacking in this same respect, because they are mostly implemented on intranets or not-publiziced websites. But high exposure definitely leads to attacks.
The patch was designed to address this concern giving server admins and moodle admins useful info, by:
- Ensuring failed logins are logged to wherever PHP is logging. Once things are in a log, resourceful sysadmins can do a lot with grep and sed. We'll definitely have a logcheck regex to catch them on our server.
- Ensuring moodle admins have a chance of spotting the fact that there is a problem. When a moodle admin logs in, she'll see warnings for _any_ account that has had failed logins over a threshold, regardless of whether there were successful logins afterwards. Those warnings only go away after the moodle admin has checked the (web-based) activity logs. If concerned, she can get hold of the sysadmin to do something about it.
- Last, but not least, regular users do get to see if there were failed logins. We are mainly concerned about tutor logins, arguably, it could be configurable whether students see it. At the same time, if students are tech savvy it would be unfair to keep them in the dark.
I expect to have some perl scripts to run on a cronjob, going over the logs trying to spot IP addresses with high ratios of failed logins, and potentially add them to a firewall script.
This adds functionality to moodle that is important to sysadmins and moodle admins mostly. We thought it might be valuable to inform users, too, but is hardly central to the patch.
cheers,
martin langhoff
To be fair, most web-based tools are lacking in this same respect, because they are mostly implemented on intranets or not-publiziced websites. But high exposure definitely leads to attacks.
The patch was designed to address this concern giving server admins and moodle admins useful info, by:
- Ensuring failed logins are logged to wherever PHP is logging. Once things are in a log, resourceful sysadmins can do a lot with grep and sed. We'll definitely have a logcheck regex to catch them on our server.
- Ensuring moodle admins have a chance of spotting the fact that there is a problem. When a moodle admin logs in, she'll see warnings for _any_ account that has had failed logins over a threshold, regardless of whether there were successful logins afterwards. Those warnings only go away after the moodle admin has checked the (web-based) activity logs. If concerned, she can get hold of the sysadmin to do something about it.
- Last, but not least, regular users do get to see if there were failed logins. We are mainly concerned about tutor logins, arguably, it could be configurable whether students see it. At the same time, if students are tech savvy it would be unfair to keep them in the dark.
I expect to have some perl scripts to run on a cronjob, going over the logs trying to spot IP addresses with high ratios of failed logins, and potentially add them to a firewall script.
This adds functionality to moodle that is important to sysadmins and moodle admins mostly. We thought it might be valuable to inform users, too, but is hardly central to the patch.
cheers,
martin langhoff
OK, thanks Martin, that's different from the original explanation in the first post.
Adding a log entry for Moodle admins to view (as well as an entry in the PHP log for sysadmins to view) makes very good sense.
You still haven't explained how it helps to show this stuff to users, though ... since it only informs them of unsuccessful logins ... as soon as the worst case scenario comes true (a successful login!) then the counter is zeroed and the user won't see any problems. For this reason I would be inclined to leave the end-user notification out.
Moodle does in fact have a small amount of protection in this area already - it has a limit of ten tries per login per session - but this basic measure is just to prevent the most simplistic manual guessing and doesn't help a dictionary attack via curl, for example. Also, unlike many other systems Moodle usernames are never shown anywhere, so crackers need to guess TWO things.
Adding a log entry for Moodle admins to view (as well as an entry in the PHP log for sysadmins to view) makes very good sense.
You still haven't explained how it helps to show this stuff to users, though ... since it only informs them of unsuccessful logins ... as soon as the worst case scenario comes true (a successful login!) then the counter is zeroed and the user won't see any problems. For this reason I would be inclined to leave the end-user notification out.
Moodle does in fact have a small amount of protection in this area already - it has a limit of ten tries per login per session - but this basic measure is just to prevent the most simplistic manual guessing and doesn't help a dictionary attack via curl, for example. Also, unlike many other systems Moodle usernames are never shown anywhere, so crackers need to guess TWO things.
About using the existing log table - I dismissed that idea primarily because the existing table was geared around logging site activity rather than capturing errors.
Additionally, there were a number of fields that weren't applicable for logging failed logins, in particular, the username tried would need to be logged, which might not necessarily fit into the userid field if a username was being tried that didn't exist in the system.
Admittedly we could not use most of the fields in that table and chuck the username into the 'info' field, but it seemed like hacking a specific table to fit a more general purpose that it didn't seem particularly suited to.
Just my $0.02 & I am of course open to correction!
- Penny
Additionally, there were a number of fields that weren't applicable for logging failed logins, in particular, the username tried would need to be logged, which might not necessarily fit into the userid field if a username was being tried that didn't exist in the system.
Admittedly we could not use most of the fields in that table and chuck the username into the 'info' field, but it seemed like hacking a specific table to fit a more general purpose that it didn't seem particularly suited to.
Just my $0.02 & I am of course open to correction!
- Penny
Thanks, Penny. I'm fine with using the log table for this, it's
what it was meant for (failed logins are activity too). There is already some other error logging being done in the same way (for email failures) and it's good to have it in context among other logs.
Yes, don't put the userid in since the user has not logged in yet. Here is my suggestion:
id <= auto
time <= time()
userid <= 0
ip <= auto
course <= 0
module <= 'login'
cmid <= 0
action <= 'error'
url <= http_referer?
info <= username password
eg
add_to_log(0, "login", "error", $_SERVER['HTTP_REFERER'], "$username $password");
A menu on the standard logs display to filter just these special logs is all we need to add. For notification, perhaps we can just email the admin whenever there are more than ten tries within a given time period, or from a single IP number.
Yes, don't put the userid in since the user has not logged in yet. Here is my suggestion:
id <= auto
time <= time()
userid <= 0
ip <= auto
course <= 0
module <= 'login'
cmid <= 0
action <= 'error'
url <= http_referer?
info <= username password
eg
add_to_log(0, "login", "error", $_SERVER['HTTP_REFERER'], "$username $password");
A menu on the standard logs display to filter just these special logs is all we need to add. For notification, perhaps we can just email the admin whenever there are more than ten tries within a given time period, or from a single IP number.
New patch: http://nzvle.eduforge.org/loginlog2.patch
This time we use the log table and the level of users to display login failure info to on login is configurable (nobody|everybody|admins|admins&tutors).
On the current log display there's a new entry in the activity menu for the site called site errors which searches for action = 'error' in the log table (so as to not be restricted to just login errors for later).
I didn't put the password in the info field, just the username, for two reasons, firstly if I try to log in and I just type my password wrong I don't want it being stored as plain text in the log table, secondly it makes things tricky if we want to filter by username attempted.
Additionally, admin/cron.php has been changed to email the admin user(s) (also configurable) of failed logins over a given threshold for username or IP address.
Penny
This time we use the log table and the level of users to display login failure info to on login is configurable (nobody|everybody|admins|admins&tutors).
On the current log display there's a new entry in the activity menu for the site called site errors which searches for action = 'error' in the log table (so as to not be restricted to just login errors for later).
I didn't put the password in the info field, just the username, for two reasons, firstly if I try to log in and I just type my password wrong I don't want it being stored as plain text in the log table, secondly it makes things tricky if we want to filter by username attempted.
Additionally, admin/cron.php has been changed to email the admin user(s) (also configurable) of failed logins over a given threshold for username or IP address.
Penny
also: unified diff at http://nzvle.eduforge.org/loginlog2-u.patch