Spammers Using Self Registration

Spammers Using Self Registration

by Mark Iannone -
Number of replies: 20

I manage a Moodle for a highschool chemistry program.

I get about 200 people per week self registering for my moodle. They do not get into the classes, but they become users in the admin settings. If I disable the eye for self enrolment at the course level, none of my self enrolled can login to my courses. How do I disable while still allowing my uses to log in.

Authentication > Manage authentication. Alternatively, self registration may be enabled for a short period of time to allow users to create accounts, and then later disabled.  How?

Mark Iannone

Average of ratings: -
In reply to Mark Iannone

Re: Spammers Using Self Registration

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Mark,

You can disable self registration by setting 'Self registration' to Disable in the common settings in Settings > Site administration > Plugins > Authentication > Manage authentication. This will result in no 'Create new account' button on the login page. You will still need to keep Email-based self-registration enabled to allow your highschool students (who previously self registered) to keep logging in.

For further suggestions on fighting spam, please see the documentation Reducing spam in Moodle.

Average of ratings: -
In reply to Helen Foster

Re: Spammers Using Self Registration

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers

Helen, thanks for your comments.

I too have had numerous bogus users register on my Moodle.  They cannot get into any course because all of my courses require a "key."  I do use self-registration, and really don't want to be turning this on and off.  I really want to keep this enabled.

In Moodle, I can tell Moodle to delete any user not confirmed within (I use) three days.  Works great!  However, some of these spamming systems seem to be able to that the URL from the email that they (the spammer) receives, and complete the registration.  They end here because they do not have any enrolment key.

I would love to have a similar option in User Accounts|Bulk actions to delete users who are not in any course.  As far as I can see, I cannot do this.

My question for you is, does any of this make sense?  Do you think it makes sense for me to add a "Feature Request" to add the ability to delete users not in any course?

I know that I should be able to accomplish this if I knew SQL a little better.  I am still learning.  But for those unwilling to learn SQL and dabble in the database, this feature (i.e., bulk delete users not in any course) would be nice.

If you know anyone who is quick with SQL, maybe you can post the command for this.

Average of ratings: -
In reply to Rick Jerz

Re: Spammers Using Self Registration

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Rick,

Could you use either the 'Never accessed' or the 'Never modified' checkbox?

Is your site open to google by any chance? (I'm just wondering why spammers would choose to create accounts on your site.)

Regarding adding a feature request to the tracker, I see you've commented on MDL-19190 - perfect. smile

Average of ratings: -
In reply to Helen Foster

Re: Spammers Using Self Registration

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers

Mary, thanks for your reply.  I also saw, and appreciate your comment on MDL-19190.

First, no, my site is not open to Google.  I am using the Default=No.

The "never accessed" doesn't work because these spamming system will often times "confirm" themselves via the confirm email's URL, thus (in Moodle's eyes) they have "accessed" the system.

Likewise, "never modified" doesn't work because the spamming system registered them as users, and theirfore their user account (in Moodle's eyes) has been modified.

If you look at my attached file, those users not in grey are bogus.  Look carefully at their city and country, and you will see how clever these spamming systems are.  Even the names can appear real.

At this point, the only real difference between these bogus users and real users (as far as I can tell), is that these bogus users are not in any course.  Being able to identify users not in any course should be a very useful feature in Moodle.  Although I think this one feature will solve my own problem, it would also be helpful to be able to filter users by those within any specific course.  My guess is that a more robust filtering method like this will take more time for someone to program because it should include "is equal to" and "isn't equal to" conditions, along with "is blank".

Attachment Spammers.jpg
Average of ratings: -
In reply to Rick Jerz

Re: Spammers Using Self Registration

by Sebastien M. -
I am glad I found this thread. I thought I had seen it all. I really like the feature of purging unconfirmed accounts after a certain period just to get rid of the bots dummy activities. However, I too started noticing that bots can confirm their registration because they have a huge amount of fake and yet operational email accounts with easily recognizable domain names like “saladchef.me” or “nscream.com” (and what about fake accounts @hotmail?). Usually these fake users log into the system once and never come back. They never enroll in any course either. However, they pollute the database and this is annoying as we are publishing statistics about our membership. Their IP address is changing so I can’t block them this way.

I will be following closely this feature request (I think that suspending/deleting all users that never enrolled themselves in any course is a good avenue, why would we want to keep them anyway):

https://tracker.moodle.org/browse/MDL-19190

Regards,

Seb
Average of ratings: -
In reply to Rick Jerz

Re: Spammers Using Self Registration

by Greg Padberg -

I like Rick's idea of another user account filter option, I think we are probably at very similar situations.  I can't help but thinking preventing bogus accounts outright would be preferable to merely facilitating an easier cleanup.

Our organization is working towards allowing self-service of Moodle related things.  Our Moodle is currently version 2.2.9 with plans to upgrade to a newer stable version during the summer break.

I prefer to enable my users by granting appropriate access (NOT Admin!) and to not need my involvement for every little thing.

To that end, we have done the following:

  • enabled course requests
  • enable enrolment keys requirement on all courses which allow self-enrolment
  • assigned 'Manager' role to a designated user who is to assume responsibility for each of the larger course categories
  • created a 'Registrar' role for Distance Ed Registration (modified from archetype role Student) - Can create / edit accounts and manually enrol students into courses.
  • enabled Email-based self-registration
  • Server cleanup settings –unconfirmed or incomplete users get deleted every 7 days.

For email-based self-registration, we had previously used the "Allowed email domains" setting to restrict spammers and otherwise creating accounts manually.  With our goal of increasing self-service we opened up email registration, which lasted about 2 hours before having to enable the CAPTCHA feature.  Also updating the "denied email domains" setting as appropriate (mailnesia.com .co.uk .info).

Even after enabling the CAPTCHA feature I am still seeing bogus accounts added at the rate of about 2 per hour and most of those are able to somehow get confirmed via email.

The bogus account profiles are fairly easy to filter / suspend / delete as the country is random and our users are all within Canada.  In the Location settings our Default country is therefore set to Canada.  Considering this further it seems that on initial account signup page, JavaScript is used to automatically populate the Country profile field with the Default country.  Extending this even further, the bogus accounts would seem to indicate that the bots are not JavaScript enabled.  Could there be a browser JavaScript capability check done on the signup.php page before allowing any form data to be submitted?  My idea is to have an additional setting in Site Administration > Plugins > Authentication > Email-based self-registration.  I would like to see a checkbox for "Require JavaScript for Creating New Accounts" (default unchecked).  Could the spam solution be so simple that it only requires the client to be JavaScript enabled?  Might there be other mitigating factors such as accessibility, or any confusion caused by mobile or tablet themes?

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers

Thanks for the follow up comments.

Right now, I have disabled "hotmail.com" from self-enrolments, and this has helped.  Although I like your idea about making the default country be something seldom used, some of my real students might forget to change this.  I am not sure about doing anything to JavaScript. 

Average of ratings: -
In reply to Rick Jerz

Re: Spammers Using Self Registration

by Greg Padberg -

In the past month I have had 193 spam users with "Email-based self-registration", even with the reCAPTCHA enabled.  This is more than 6 per day, which is still enough to bother me constantly.  I am revisiting my server config, and am very close with what I feel should be a very effective and yet proactive solution.  Today I started experimenting with this notion on my test server and have it mostly documented.  My solution is to use GeoIP to allow access to /moodle/login/signup.php only from my internal network and the countr(y/ies) of my choosing.  Unauthorized users get 403 Forbidden on the Moodle signup page.  This strategy should allow all / any authorized users to create Moodle accounts using any email address they wish, while nearly eliminating the exposure for creating spam accounts.  Because only the signup page gets blocked from all unauthorized countries (and not the remainder of the Moodle installation), valid users can login from anywhere after their Moodle accounts have been created and confirmed.  After I have updated my production server configuration and had some time to prove the setup I intend to document and share the info here.

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers

Please vote for MDL-19190.  I would like to see a self-enrolment setting that says "Delete users that are not in any course after xx days."

Average of ratings: -
In reply to Greg Padberg

This forum post has been removed

The content of this forum post has been removed and can no longer be accessed.
In reply to Deleted user

Re: Spammers Using Self Registration

by Rick Jerz -
Picture of Particularly helpful Moodlers Picture of Testers

Thanks for your ideas, and refernce to MDL-39503.

What I really meant to say in my previous post is that in Site Administration|Users|Accounts|Bulk Actions, there should be a filter for "Users that are not in any course after xx days"

Once again, what I (and others) am finding is that with self-enrollment features (even Captcha), these (sophisticated ) spamming systems are able to create users.  In my Moodle, every course requires an enrollment key, so these spammers have not figured out how to actually get into a course.  Moodle doesn't provide any way to easily delete "students not in any course".

Average of ratings: -
In reply to Rick Jerz

Re: Spammers Using Self Registration

by Glenn Pillsbury -

Exact same situation here.  Lots of email self-registration fake accounts but no enrollments because of enrollment keys.  Having another filter for those accounts would be great.  I've up-voted MDL-19190.

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

OK as of an hour ago I now have applied my GeoIP blocking solution to the signup page on my production Moodle server.  Now for some historical metrics before I remove all the disabled spam accounts I have collected.

Since enabling the ReCAPTCHA I have had 526 spam accounts confirm via email in the past 51 days, so an average of just over 10 per day.  The spam accounts list random countries but 4 of the accounts listed the country as Canada (which is the country where I am located), making the spam accounts slightly less obvious to filter out.

I did have some notorious spam email domains listed in my "denyemailaddresses" setting (.info .co.uk mailnesia.com frenchcuff.org) but with my new setup I will be removing them altogether.

I will check back with this forum in about a week to let you all know how things are going, and will document my solution if the upgrade proves successful.  FYI, my production server runs Linux (Ubuntu Server 12.04 LTS) and my documentation will reflect that.

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

I`m calling it good, no spam accounts so far since implementing my GeoIP blocking solution to the signup page on my production Moodle server.  Normally I had about 10 per day but none so far in the past 4 days.  New users still get created OK, no complaints from anybody, and silence from the spammers.  I`m not an apache guru by any stretch but I read the relevant documentation and tested a workable solution to vastly reduce the Moodle server`s exposure to creation of spam accounts.

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

Here is the example documentation for my solution to reduce spam exposure.

Geoip limit countries other than Canada for email registration page.
Unauthorized users get 403 Forbidden for /moodle/login/signup.php

This example is using a recent Ubuntu Server with Apache2 and assumes an already working Moodle.
Allows IP addresses from 10.0.0.0/8 and GeoIP Country Code CA (Canada) access to /moodle/login/signup.php and denies all others.
Vary the recipe accordingly to suit your taste.
The usual disclaimers apply, don't try this on a production server unless you know what you are doing.
If you break stuff, you get to keep all the pieces.

Install the GeoIP dependencies:
sudo apt-get install libapache2-mod-geoip

Uncomment the GeoIPDBFile line from /etc/apache2/mods-available/geoip.conf:
sudo nano /etc/apache2/mods-available/geoip.conf

Add the following line somewhere in your Apache server config (httpd.conf or equivalent), I appended it to my /etc/moodle/apache.conf:
GeoIPDBFile /usr/share/GeoIP/GeoIP.dat

Create the file /etc/moodle/denysignup.conf with the following contents:
<Files signup*>
GeoIPEnable on
SetEnvIf GEOIP_COUNTRY_CODE CA WhiteList
#SetEnvIf GEOIP_COUNTRY_CODE US WhiteList
#Add rules here to allow more countries if desired
Deny from all
Allow from env=WhiteList
Allow from 10.0.0.0/8
Allow from 127.0.0.0/8
Allow from localhost
</Files>

Symlink the newly created file into the Apache configuration:
sudo ln -s /etc/moodle/denysignup.conf /etc/apache2/conf.d/denysignup

You may need to review the file ownership or permissions on the newly created files (chmod or chown).

Restart Apache to apply the changes:
sudo service apache2 restart

The following web pages are provided as helpful reference:
http://dev.maxmind.com/geoip/legacy/mod_geoip2
http://ubuntuforums.org/showthread.php?t=1410627
http://linuxdatum.info/web-server/howto-install-mod-geoip-for-apache2-on-ubuntu-precise

Average of ratings: Useful (1)
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

A quick update since geoip limiting /moodle/login/signup.php on my server (denies access to all IP addresses that do not reside within Canada). Email registration from within Canada works OK for any email address and once registered, Moodle users can login from anywhere. Moodle Admin and Users are all happy.

Only about 3 bogus accounts managed to get confirmed, from the networks of nobistech.net in the USA and OVH Hosting in Montreal (subsequently blocked).
All is quiet since adding the following networks to Security > IP Blocker > Blocked IP List:
142.91.0.0/16
142.4.192.0/19


In summary:

  • Opening up email registration to the entire world is a can of worms for sure.
  • Allowed email domains / Denied email domains setting within (Site administration > Plugins > Authentication > Manage authentication) can be effective, although it can also be quite restrictive for users wanting to signup using their preferred email. I was using this approach initially but have since abandoned it.
  • Enabling ReCAPTCHA should be the first line of defense (helps, but many still able to get through).
  • Installing and configuring libapache2-mod-geoip to limit access to /moodle/login/signup.php from outside of Canada was another significant reduction in the number of spam accounts.
  • Security > IP Blocker > Blocked IP List may need some tweaking / additions if any bogus accounts still make it through.
Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

Another addendum.  I will mention the importance of keeping an updated GeoIP.dat file, as ownership of various IP address ranges seem to change over time (and defunct networks from Canada have since been taken over and likely re-used elsewhere).  In the case with Ubuntu Server, the geoip-database-contrib package provides the means to download a new copy of GeoIP.dat, and to keep it fresh with automatically checking for monthly updates.

I have found some bogus accounts created from IP address ranges originating from the now defunct Avante Hosting based in Toronto:

http://whois.arin.net/rest/org/AHS-136/nets

Also from OVH Hosting in Montreal...  http://whois.arin.net/rest/org/HO-2

Thus my Security > IP blocker list currently looks like this to block out all the networks owned by those 2 organizations:

142.4.192.0/19
192.95.0.0/18
198.27.64.0/18
198.50.128.0/17
198.100.144.0/20
198.245.48.0/20
199.195.156.0/22
192.241.8.0/21
192.119.144.0/20
66.248.192.0/19
192.161.192.0/18
198.52.128.0/17

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

Another update on my approach to mitigate spam accounts. It has been extremely effective! Last week I had a spam account created but it did not get verified so it disappeared after 7 days. I think there has been maybe a single spam account that got through since the summer, which was easy to find and disable. I also updated the rules to block my internal networks so as to encourage my users to use their existing LDAP accounts rather than sign up for a new Moodle account. The config file now looks similar to the following (my internal network has been changed in this example):

<Files signup*>
GeoIPEnable on
SetEnvIf GEOIP_COUNTRY_CODE CA WhiteList
#SetEnvIf GEOIP_COUNTRY_CODE US WhiteList
#Add rules here to allow more countries if desired
order allow,deny
#Deny from all by default!
Allow from env=WhiteList
Allow from 10.0.0.0/8
Allow from 172.16.0.0/12
Allow from 192.168.0.0/16
Allow from 127.0.0.0/8
Allow from localhost
# prevent users on internal networks from new account signup,
# they should use existing LDAP accounts instead!
Deny from 10.244.0.0/16
</Files>

I am drafting up some ideas to submit to the Moodle tracker, as integrating this functionality within Moodle rather than at the web server config would make this solution more available to a wider audience of Moodle users. I am not a coder but would certainly be willing to help out with documenting this feature if it were integrated into Moodle.

Average of ratings: -
In reply to Greg Padberg

Re: Spammers Using Self Registration

by Greg Padberg -

Here is the same configuration adapted for Apache 2.4, as we have migrated our server to the newer version of Ubuntu Server (14.04 LTS):

# Deny access to signup.php (email-based self-registration)

# Allow from within Canada (via set variable WhiteList)

# Allow from within 10.x.x.x address space (our learning partners)

# Block from our networks to encourage LDAP authentication instead

# Deny all other access to minimize spam

# For spam bots within whitelisted IP addresses, use the Moodle IP Blocker

<Files signup*>

GeoIPEnable on

SetEnvIf GEOIP_COUNTRY_CODE CA WhiteList

#SetEnvIf GEOIP_COUNTRY_CODE US WhiteList

#Add rules here to allow more countries if desired, see the following for info:

# http://dev.maxmind.com/geoip/legacy/mod_geoip2/


# Apache 2.4 has a new method of access control, see the following:

# http://httpd.apache.org/docs/2.4/upgrading.html

# http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#require

# https://blogs.apache.org/httpd/entry/require_and_friends



<RequireAll>


# allow Whitelist (above) or any 10.x.x.x IP address

<RequireAny>

Require env WhiteList

Require ip 10

</RequireAny>


# prevent users on internal networks from new account signup,

# they should use existing LDAP accounts instead!

<RequireNone>

Require ip 10.244.0.0/16

</RequireNone>


</RequireAll>


</Files>


Average of ratings: Useful (1)