Spammer registrations

For the past while we're had a number of reports of unexpected user registration on DNN sites. In some cases these sites still had public registration enabled but had no expectation of new members, suggesting something odd was going on. Further investigation showed that in some cases these unexpected new users proceeded to add content (including links) to their profiles that would be useful to help with SEO for those sites (sometimes referred to as "link juice"). We asked for and received a number of IIS log files and access to users sites, and have been able to establish that there is no issue with registration i.e. these are valid registrations and not a security issue that allowed someone to bypass registration. However, based on the speed and frequency of the registrations it's clear that an automated process ("bot") is being used to register on various DNN sites. This is an unfortunate problem, but is not uncommon with template driven applications such as CMS -for instance Wordpress has had to battle this on a number of occasions.

Initially anecdotal reports stated that enabling a captcha stopped these registrations, but in the past few days that has proven to no longer the case i.e. the anecdotal reports were either wrong or the spammers have updated their bot to calculate the registration captcha correctly. The full process the bot follows appears to be:

1. It searches google for sites that contain “Membership for this website is public”

2. Once a site is found (e.g. mysite.com), it executes a request for mysite.com/default.aspx?ctl=Register

3. Once the registration page loads, the bot pulls down the captcha image and calculates the answer (if a captcha is on the page), fills in the fields and clicks register. It then and updates the profile to contain some links to other sites in an attempt to enhance SEO

What can I do to stop this?

The easiest thing to do to stop registrations is to disable registration by setting it to none (https://www.dnnsoftware.com/help#Documentation/Using_the_Control_Panel/Admin_Console/Site_Settings/User_Account_Settings/Registration_Settings/Enabling_User_Registration.html)

If you cannot do this as you want to support registration of new users, then private registration is recommended. During one of the security team’s periodic audits, we determined that the old default of "public" was sub-optimal, and changed the new default to "private" with the 7.0.0 release, so anyone who has installed DNN since 7.0.0 will already be using "private" and not have anything to worry about.

It's also recommended that you enable registration captcha's - whilst captcha is widely regarded as being broken (https://www.google.hu/?gfe_rd=cr&ei=8m58U6PbIqHc8ge_3YHoDQ#q=captcha+broken), the fact that it works in some cases will at least reduce the number of unexpected user's registering.

I want to offer public registration, is there anything I can do?

Whilst we work on this issue, there are a few things you may consider.

1. Consider altering the "Membership for this website is public" text in the PublicMembership.Text node in App_GlobalResources\SharedResources.resx. Whilst this doesn't solve the issue, it offers a form of "security by obscurity".

2. There are reports that the bot attempts passwords with a length of 7-10 characters. Changing the minimum password length to 11 (or above) via the minRequiredPasswordLength parameter in web.config stop's these automated registrations (though clearly the bot authors could update their bot for longer lengths). Note: this is intended for a new install, I believe that it may lock out users with shorter passwords in existing installs.

3. If using IIS7 or above, you can use request filtering to block requests for ctl=Register - see https://www.dnnsoftware.com/forums/forumid/108/postid/501219/scope/posts#501219 for an example.

4. Some anecdotal reports state that added an additional, required field to your profile blocks the bot - this would make sense as it's targeting the default registration page. As such a new required profile property will likely halt the unwanted registrations (see help.dnnsoftware.com - search for "Managing your User Profile")

5. Change the registration page and block requests to the default registration - see https://www.dnnsoftware.com/wiki/page/replacing-registration-page-with-custom-and-blocking-the-default-register-page

6. A community member (interactivewebs) has created a module which replaces the built in Captcha with the much more difficult to crack reCaptcha one- see here

I have a custom registration page, is this a problem for me?

This would not normally be a problem as the bot is targeting the default DNN registration page. However there was a bug in the logic that handled redirects to custom registration pages - https://dnntracker.atlassian.net/browse/DNN-4842 . This bug was fixed in 7.2.2, so upgrading to that version will resolve it.

What else are DNN doing about this?

We continue to investigate and analyse the various reports, and make plans to resolve it. We're currently considering various measures to make it much harder (e.g. update/replace the captcha, remove/control the ?ctl=Register logic), as well as to make it pointless for spammers e.g. allow sites to set control whether users can use html in their profile, and hope to roll out some solutions to this soon.

Comments

Thank you for your post Cathal. I have already upgraded the site to DNN 7.2.2. But the problem is still same. I changed the password strength to 11 for now as I mentioned in the forum post as a temp solution.

Prasad Maduranga Wednesday, May 21, 2014 9:50 AM (link)

@Prasad - do you mean you are using a custom registration page but when you go to yoursite.com/default.aspx?ctl=Register the default registration page loads - or do you mean you still see the spam registrations (if it's the later then that's expected, hence the suggested workarounds whilst we work on a more permanent solution)

cathal connolly Wednesday, May 21, 2014 9:54 AM (link)

Hello Cathal, - I am using the standard DNN registration module and used custom registration page. But it was same when I was using the standard registration method as a popup. So I did try with a custom page as well. That is after upgrading to DNN 7.2.2 and with and without custom registration page, it created spam accounts. I changed the password strength to 11 and now no new spam accounts. This will be good until bot change his password length. And users won't like to give too long passwords as well.

Prasad Maduranga Wednesday, May 21, 2014 10:01 AM (link)

@Prasad, that's expected then - it's only if you're using a 3rd party registration module on a custom registration page that the secondary problem existed (which was resolved in 7.2.2)

cathal connolly Wednesday, May 21, 2014 10:39 AM (link)

Thanks, Cathal. Your article is very helpful.

We met this issue these days and it puzzled us a lot. We tried the captcha control and also the "email verify" process, but neither of them works. So we decide to modify DesktopModules\Admin\Security\Register.ascx (and Register.ascx.cs), try to add some custom verify mechanism to prevent these spam machines. Now it works. And today we spend a about a hour to clean all the spammer users.

Please check http://www.dnnsoftware.com/forums/forumid/118/threadid/501138/scope/posts for more details. And we find a way to find out existing spam users. Try execute " select * from users where LastModifiedByUserID>0" in "Host - SQL", you will find 99% of the result users are spam registration users.

DnnModule.com Wednesday, May 21, 2014 11:04 AM (link)

There's no better time to turn back to this Community Voice suggestion... http://www.dnnsoftware.com/voice/cid/153238

Will Strohl Wednesday, May 21, 2014 3:38 PM (link)

I discussed a few options in this forum post. As a start, DNN needs to use a more sophisticated one than the simple one they are using now. An extra hidden form textbox is another option which doesn't cost anything to the visitor and has zero drawbacks.

http://www.dnnsoftware.com/forums/forumid/118/threadid/501138/scope/posts

Tony Henrich Wednesday, May 21, 2014 7:16 PM (link)

I used this SQL to soft-delete the bogus users. It might work for you - but do a 'select' first to make sure it's not going to pick up valid users.

update Users set IsDeleted = 1
where UserName = displayname and (LastIPAddress is null or LastIPAddress = '') and FirstName = '' and LastModifiedByUserId = -1
and CreatedOnDate > '2014-05-12'

Bruce Chapman Monday, May 26, 2014 12:42 PM (link)

We have created a free module to help stop these registrations:

http://www.interactivewebs.com/blog/index.php/dotnetnuke-modules/dotnetnuke-dnn-spam-registrations-problem-fixed/

David Finley Thursday, May 29, 2014 3:41 AM (link)

@ Bruce Chapman,
I found the Interactivewebs' module (iWebs Register) while searching for solution to the User Registration SPAM problem.

However, I could not get the module to work.
I downloaded and unzip the modules from the Dropbox. There are two modules, one for DNN 6.2 and one for DNN 7.x.

My site is using DNN 6.2.6. After I installed the version for DNN 6.2, my website crashed.
Do you have report from other user with similar problem?

Samuel Phung Monday, June 2, 2014 2:18 PM (link)

@Samuel - I recommend using the solution I have posted in the Wiki:

http://www.dnnsoftware.com/wiki/page/replacing-registration-page-with-custom-and-blocking-the-default-register-page

This saves from having to use any type of third party registration module or other captcha - and it is effective in preventing bots from finding and filling out the registration page.

Bruce Chapman Tuesday, June 3, 2014 7:46 AM (link)

Hi Bruce.

We have had no reports of crashing sites. We are happy to support it. Drop a support ticket on at: www.interactivewebs.com

David Finley Tuesday, June 3, 2014 8:53 AM (link)

@Bruce Chapman

I follow the instruction on the link you provided.
1. Created a custom login page (xxxregistration)
2. Configure the site to use the custom login page.
3. Add a request filter to reject the default register URLs.

The site now bring up the new custom-login page when I launch the following URL:
http://mysite.com/register.aspx

I double check the steps I took to make sure I am not missing any step.

Is this an expected behavior?

Sam

Samuel Phung Tuesday, June 3, 2014 5:00 PM (link)

@David I think that was for Samuel

@Samuel - if you're still getting the standard register.aspx then you haven't completed your request filter properly. If the request filter is properly configured, register.aspx will return a 404. It does show that you have set up your custom registration form properly if you're seeing it on that URL, but your request filter isn't working.

Bruce Chapman Tuesday, June 3, 2014 5:55 PM (link)

HI Cathal,
Good to hear that this is being taken seriously as it is proving a major pain point for me. Can I throw into the mix the request that whatever improvements you make to eliminate this irritation, that you consider the options for making the changes back-portable into older versions of DNN - I am thinking in terms of an updated provider that can be installed onto older sites. For many reasons a lot of us I am sure have customer sites that are 'stuck' at older DNN releases so just saying "this is fixed from DNN 7.4 (or whatever) onwards please upgrade" is not going to provide us with any relief.
Thanks,
Graham

Graham Lewis Wednesday, June 4, 2014 5:01 AM (link)

@ Bruce Chapman
Looks like the solution is for DNN 7 and above.
I use the exact steps on a DNN 7.2.2 site and it works, the default register.aspx page is suppressed.

The site I am having problem with www.embedded101.com is still on DNN 6.2.6.
The same steps that work on the DNN 7.2.2 site would not work on DNN 6.2.6.

Any suggestion?

Note:
I am not able to upgrade this site to 7.2.2 yet.
The upgrade failed, probably caused by one or more of the installed module.

Samuel Phung Wednesday, June 4, 2014 11:27 AM (link)

@ David Finley,
I was not able to install the "iWebsRegister 62.6.2.0 PA.zip" package to a DNN 6.2.6 site, www.embedded101.com
The installation process failed to complete.

I have been using DNN since 4.1 and can say that I am familiar with DNN's module installation process.
I take a look at the package and can see that it has the "register.ascx.resx" and "registersettings.ascx.resx" files, which are the place where you need to make change to implement Google RECAPTCHA.

I actually installed the module to the live production site without testing (not a good practice).
I did a backup prior to the install and able to revere to the backup without problem.
I will try again on a test site when I have time.

On a separate note, I also purchased the "Advanced Login" module from your company and implemented on the www.embedded101.com site hoping this module can help solve the registration SPAM problem.
So far, the registration SPAM continue, with the following basic installation:
- Create a custom login page
- Place the Advanced Login module to the custom login page
- From Admin/Site Settings/Advanced Settings, change the "Registration Page" and "Login Page" to the new custom login page.

I believe the problem still remain due to the fact the default "Register" page is still accessible programmatically.
Any suggestion?

Samuel Phung Wednesday, June 4, 2014 11:42 AM (link)

The bot is only targeting the control accessed registrations page as detailed here:
http://www.interactivewebs.com/blog/index.php/dotnetnuke-modules/dotnetnuke-dnn-spam-registrations-problem-fixed/

The Advanced login module has the ability to add Captcha to your custom registration forms, but does not add it to the DNN core registrations module in the same way that our free module does. For this reason, we would recommend that the free module is used, and that for more general security or the morphing of the bot, that Captcha is used for way of the advanced login module.

As we have discussed in this forum. If you had troubles installing the module, then please submit a support ticket at http://www.interactivewebs.com - we would like to fix any errors that come to our attention, but as yet we have not seen them ourself and cannot fix them. Be sure to follow instructions too by registering your domain and entering the Recaptcha details within the module before initiating it into the site. Otherwise the recaptcha component will fail to load.

David Finley Thursday, June 5, 2014 3:33 AM (link)

I used the solution that Bruce provided which doesn't require any 3rd party modules and it completely stopped spam registrations. Of course you have to implement customer registration on all sites in the installation that have Registration turned on.

http://www.dnnsoftware.com/wiki/page/replacing-registration-page-with-custom-and-blocking-the-default-register-page

The only difficulty is that you can't see the Registration Module in the Host or Admin Add Module function. I'm guessing the version that Bruce has is the Pro so you can search for the module from the Add New function. I went into Host Extensions and then in the Registration module made it available for the site I was working on. Once I added it and put in the request filter. BAM, no more registrations.

Works for now until the spammers figure something else out. Should give the core team some time to figure out a more secure and permanent fix.

Thanks Bruce!!!

Robert Stordeur Thursday, June 12, 2014 2:17 PM (link)

We have been using Bruce's recommended solution at:

http://www.dnnsoftware.com/wiki/page/replacing-registration-page-with-custom-and-blocking-the-default-register-page

However, we just ran into a DNN 6.2.9 instance that the ?ctl=register request filter is not working correctly. The /register one seems to be working. We have tried separating the two into multiple request filters, but still no success.

(?<=\?)ctl=register|(?
Has anyone else had issues in DNN 6.2.9 with this? If so, how did you resolve? We unfortunately cannot upgrade DNN to 7.x just yet for this client.

David Poindexter Monday, June 16, 2014 4:27 PM (link)

By the way, we just figured out the issue with the one Request Filter not working. The site was running under 3.5 Framework. As soon as we switched it to 4.0, the request filters started working like a charm!

David Poindexter Monday, June 16, 2014 5:14 PM (link)

QUOTE
The only difficulty is that you can't see the Registration Module in the Host or Admin Add Module function. I'm guessing the version that Bruce has is the Pro so you can search for the module from the Add New function. I went into Host Extensions and then in the Registration module made it available for the site I was working on. Once I added it and put in the request filter. BAM, no more registrations.
UNQUOTE

It would be a really helpful idea for someone to edit Bruce's wiki to reflect the info above for the many of us who aren't that deep in the weeds, and don't have Pro.

sschleiffer Thursday, June 19, 2014 10:06 PM (link)

Actually, I just tested this again yesterday on a development server that is running DNN 7.3. The module search function is available in the Community version. I don't know which version, but it's in 7.3. As a side note, it's a great feature since scrolling to the right to find a module was always time consuming.

Robert Stordeur Friday, June 20, 2014 11:37 AM (link)

Thanks for all the useful information on stopping this by all, but what about the flipside? How about the 1,000's of fake users on our sites, does anyone know of any free modules/clean way to clean this up that doesn't require one to click 'delete' on each account record using DNN? I'm managing nearly 40 sites from DNN 4 to DNN 7.2.2 that all have the same issue. Any thoughts on that would also be helpful.

Michael DeBaise Wednesday, June 25, 2014 4:47 PM (link)

I'm using the method of masking my public registration text in conjunction with re-CAPTCHA.. There's a slight flaw. The text 'Note: - Registration may take several seconds. Once you click the Register button please wait until the system responds.)' is also used for public registrations.. Where can I change this text?

gopher49 Wednesday, June 25, 2014 5:20 PM (link)

I see another issue.. If you use the URL filters then the 'Register' button on the login page gets a page not found.. How can I resolve that?

gopher49 Wednesday, June 25, 2014 7:22 PM (link)

My sites (those affected) are not many and don't have many users. What I found after the Brice Chapman Wiki prescription was given to the patient was an absolute cessation of new spam reg. To delete I logged in as host, went to Admin > Users and selected all Unauthorized. Then I simply deleted all of them and then Removed all of them. I check first and none of them had ben authorized, and none who were legit were deleted in the process. No need for a module. Certainly good care to verify my experience must be used prior to a mass delete on a production site with 1000s of users.

When I "assigned" the registration module in order to have oit appear in the module roster to select from, I was unsure whether now that I have placed it on the new reg page, whether I can (or should) unassign it. Any thoughts from you DNN Masters?

sschleiffer Wednesday, June 25, 2014 10:58 PM (link)

Great suggestions, but I've already disabled registration, removed all spam registered users, but they're still maxing my server memory with attempted user login on the spam users that used to exist. Plus they're trying to run some sort of injections script. So my server capacity is still maxed out, making our sites run slow and working on them next to impossible. I wrote all details on a thread at http://www.dnnsoftware.com/forums/forumid/108/threadid/503937/scope/posts

I'm looking for suggestions to stop them now that I have turned off all registrations, deleted all accounts, and even made all profile pages admin only in permissions. Please visit my thread to view all that we've done and also the problems we are still seeing in event viewer. If you don't visit the thread, here's what I said in it.....

We had well over 100,000 spam user registrations on our server. One site alone had over 47,000 spam registrations. Here's the steps we've taken to prevent new registrations BUT they are still trying to login and also create other issues that has our server resources MAXED out.

Steps we did on ALL dnn sites on our server.

1. Set user registration to "None" in Admin-Site Settings-User Accounts
2. Set all user profile pages permissions to "Admin" only in view page permission settings.
3. Hard deleted all users
4. Cleared Admin-Event Viewer (some sites this log file was over 3gb).

While this has prevented them from making new registrations and also has blocked profile pages so the spam links in the profiles can't be visible, our server is consistently maxed out. We're running twice the ram as most servers, and the total sites on the server should only use about 45% of it's resources, however since the spam registration stuff has begun in the past 2 months or so, our server resources stay maxed at 95-100%, which makes it SUPER slow, especially when trying to work on a site. Just logging into a website can sometimes take over 2 minutes.

When I go to one of the sites that had a ton of spam registrations, then go to Admin -> Event Viewer, I see page after page of login attemps and other errors. Because I deleted all users, they can't login, but their bots keep trying. So, I clear the event viewer. Wait only 5 seconds, refresh the event viewer page, and within those 5 seconds there's 6 pages of even issues.

Half of these events are login failures, I've tried to block the login ip addresses through Host-Settings, but they're logging in from everywhere, USA, NY, France , Phillipines, etc, etc.

There other half of the events are "General Exceptions" which I don't fully understand. What concerns me is the statement of "Module Injection."

I have copied below this General Exception. Does ANYONE PLEASE have any idea how to fix, or help on this. I've been awake for almost 5 days battling this, and it's ONLY on my DNN sites. Some are running DNN6 and some DNN7. I'm about to lose some hosting clients due to long loading times. PLEASE anyone have any ideas.

Besides the attempted logins into accounts I've deleted, here's the other event that keeps being shown, at least 3 times EVERY SECOND.

AssemblyVersion:7.3.1

PortalID:0

PortalName:Honolulu & Oahu Cleaning by Distinctive Homes Hawaii Cleaning Services

UserID:-1

UserName:

ActiveTabID:56

ActiveTabName:Home

RawURL:/?ctl=register

AbsoluteURL:/default.aspx

AbsoluteURLReferrer:http://www.dhhics.com/

UserAgent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36

DefaultDataProvider:DotNetNuke.Data.SqlDataProvider, DotNetNuke

ExceptionGUID:93e0b670-dae8-46f8-aed9-657ce8f51f92

InnerException:Unhandled Error Adding Module to ContentPane

FileName:

FileLineNumber:0

FileColumnNumber:0

Method:System.Threading.Thread.AbortInternal

StackTrace:

Message:

DotNetNuke.Services.Exceptions.ModuleLoadException: Unhandled Error Adding Module to ContentPane ---> System.Threading.ThreadAbortException: Thread was being aborted.
at System.Threading.Thread.AbortInternal()
at System.Threading.Thread.Abort(Object stateInfo)
at System.Web.HttpResponse.AbortCurrentThread()
at DotNetNuke.Modules.Admin.Users.Register.OnInit(EventArgs e)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.AddedControl(Control control, Int32 index)
at System.Web.UI.Control.EnsureChildControls()
at DotNetNuke.UI.Containers.Container.get_ModuleControl()
at DotNetNuke.UI.Containers.Container.ProcessModule()
at DotNetNuke.UI.Skins.Pane.InjectModule(ModuleInfo module)
--- End of inner exception stack trace ---
at DotNetNuke.UI.Skins.Pane.InjectModule(ModuleInfo module)
at DotNetNuke.UI.Skins.Skin.InjectModule(Pane pane, ModuleInfo module)
Source:
Server Name: onewave

Paul Coffman Wednesday, July 2, 2014 1:24 PM (link)

Did you consider adding Recaptcha?
http://www.interactivewebs.com/blog/index.php/dotnetnuke-modules/dotnetnuke-dnn-spam-registrations-problem-fixed/

as per that post?

David Finley Wednesday, July 2, 2014 10:47 PM (link)

I can't login to the site because we have maximized the amount of space allowed on our site. (500 MB?) How can I even begin to address this problem? I am a novice webmaster.

Jan Wednesday, July 9, 2014 12:15 PM (link)

Think you are going to need the help of your host on this one. They should allow for you to expand the available space while you sort out the issue.

If you have a back or can get a backup. We can deploy the site on a dev server for you. You can then sort out the issue then upload it back to the host.

David Finley Thursday, July 10, 2014 1:39 AM (link)

In addition to implementing a more secure CAPCHA like the Google one in the next release (I already have programmed in the temp fix in mine) but some of these registration still comes through either by a very good boot that crack Google or some manual effort from the spammer. From 20-30 per day, I now only get 1 or 2.

But here is my idea, the whole purpose of the spammer is to get his url link in his user profile, to what end can be questioned as it does not benefit any SEO ranking. Si if the verified registration process, the one with an email back get altered so that ONLY after a confirmed registration can the user profile be updated, that the whole purpuse goes away unless the spammer gives his real valid email and completes step 2 of the profile update, and then at least we have is at the time valid identity/email.

Vikingno Monday, July 14, 2014 8:43 AM (link)

@Vikingo - that's one of the items we plan on addressing for 7.3.2 (there are around half a dozen changes planned to address this issue)

cathal connolly Monday, July 14, 2014 1:00 PM (link)

I've done all these things and much more. Problem is they 100,000+ old spam registered users (Now deleted) are now consuming 100% of our server memory trying to login. We've been battling this for 3 weeks and it's cost one client over $1,000,000 in sale.s

Paul Coffman Monday, July 14, 2014 3:20 PM (link)

All these login attempts are coming from a few ip addresses or a lot? I am thinking if these ip addresses can or should be blocked before reaching IIS. I used to run my own hosting company and use a dns server software called Simple DNS Plus (http://www.simpledns.com) and I could set it up so that if x requests come from the same ip address within x seconds, it automatically blocks the ip address. I would gets attack from certain servers and the dns server used no extra overhead to block them and they never reached the web server. I am assuming in this discussion that you're getting attacked by a few sources. I have several ideas but they involve custom code. For example, if I had this problem in my environment, would have a list of these users they are trying to use and every time an attempt was used to log in with any of these users, I would grammatically add the ip address to the blocked ip list in the dns server. Or writing an http module and have a list of them in memory before attempting to authenticate with SQL Server. The whole idea is to use memory as much as possible before connecting to the database and blocking them once they are identified so that that are blocked in the future. Maybe these bots have some intelligence in them where when they are know they are blocked they quit for good. You have tried many things. It's time to get unconventional. BTW, $100,000 is a lot.

I hope the next version of DNN really works against those bots.

Tony Henrich Monday, July 14, 2014 6:59 PM (link)

They're coming from IP's all over the world, from NYC to the Philippines, France, etc. It's almost as if there's a virus installed on personal computers all over the world that are sending out the bot requests.
I'm the closes I've ever been to quitting DNN. I can't even work on my existing sites much less build new ones. Losing clients for the firrst time in the history of our business.

Paul Coffman Monday, July 14, 2014 8:33 PM (link)

@Paul - sorry to hear about the problem. I'm assuming you've applied one or more of the suggested workarounds and are no longer seeing automated registration, but rather what is effectively a denial-of-service attack (albeit because they expect the logins to exist). Typically a spammer would stop trying to log in if the user no longer exists, but clearly the scripts they use don't have that intelligence. I'm surprised that they're taking so much capacity if their scripts can't log in - perhaps you'd be better setting a custom login page and redirecting the requests to a 404 page (i.e. examine your IIS logs and if the automated login attempts are to /login.aspx block that url)

We have half a dozen different fixes/enhancements scheduled for this issue for 7.3.2, from setting captcha as a new default, to making it harder to crack, to removing the value of spam accounts (e.g. not displaying unverified profile pages, changing richtext properties to plaintext for new installs etc.), which should stop automated spam registration, but denial-of-service attacks are a different case so I recommend you look into blocking them either via network hardware (e.g. firewall) or url.

cathal connolly Monday, July 14, 2014 9:33 PM (link)

Paul Coffman,

You should contact us at http://www.interactivewebs.com - If you are serious about a client being impacted with serious financial implications.

There is a lot we could do with some custom modules on this issue. We could for example make a module that monitors registrations from IP addresses and block addresses once they have more than a certain number of attempts within a set period. This data could be shred through a cloud service to create a global list of blocked IP addresses for all DNN site. Or we could look for the speed that forms are filled in, and respond to that. There really is a lot that can be done.

From our perspective we have solved our own problems and there is no financial benefit for us to develop our free module more than a few user requests every week or so. If you have a client that could benefit from some professional services, then please contact us because we have not really scratched the surface of what is possible with all this.

We imagine that many of the features of this plugin for Wordpress: http://www.wordfence.com/ would be easily replicated in a DNN module.

David Finley Monday, July 14, 2014 9:59 PM (link)

@Paul - as Cathal says - if you have already changed your registration page and stopped the registrations, the next step should be to change the login page URL and block the old one so it returns a 404. If desperate you could also replace your login page with a plain .html with a javascript redirect in it that the bot wouldn't execute, until a more permanent solution is found. I would say the bot is using a botnet - this is usually how an attack like this is done as it is trivial to block a single IP. Unfortunately the issue is currently focussed on DNN but also affects many other platforms as their open-source nature makes them easy to build an attack against.

Bruce Chapman Monday, July 14, 2014 10:15 PM (link)

About 2.5 ~ 3 months ago, I ran into the same spam registration problem with 2 of my sites. At the time, Both sites were on DNN 6.2.7.

I ended up upgraded the sites to DNN 7.2.2 and follow the recommendation provided in the following thread (created a custom registration page and disabled the default registration page):
http://www.dnnsoftware.com/wiki/page/replacing-registration-page-with-custom-and-blocking-the-default-register-page
Note: The information on this link only work on DNN 7.x and does not work on DNN 6.x

After these updates, the spam registration problem went away.

Hope this help someone with similar problem.

Samuel Phung Monday, July 14, 2014 10:41 PM (link)

ARRGGGHHH Not to be frustrated, but I've already created a custom login page, that's only accessible by anyone who knows the entire URL of the new login page. I've used IIS to set anyone that tries to visit any defualt login page like
/login /login.aspx or ?ctl=login to to abort the request.
THEY CANNOT ACCESS A LOGIN PAGE. It's their attempts from their 100,000 plus fake spam accounts looking for login pages, or looking for profiel pages (no admin only) and that's what's tying up my memory.

Paul Coffman Tuesday, July 15, 2014 1:08 AM (link)

@Paul - that's still strange. Using a high level filter such as ISAPI or even IIS url request filtering should meant the requests are rejected before the application processes them i.e. they should not effect performance unduly as the requests never make it to DNN (rejecting them at a higher level such as a firewall is better but not always an option due to hosting constraints). Perhaps you could share a section of your IIS logs with the security team so we could review ? If you can please send them zipped up to security(at)dnnsoftware(dot)com

cathal connolly Tuesday, July 15, 2014 8:13 AM (link)

@cathal What is the ISAPI or module filtering on? You have legit and spam users trying to log in using the same login screen. How is the filter differentiating between the two?

Tony Henrich Tuesday, July 15, 2014 12:38 PM (link)

@Tony -I don't have a site this is effecting. However typically automated scripts such as this use GET requests for predictable urls e.g. ctl=register for register, and ctl=login (or login.aspx or /login) for login. If a site is using a custom page for login's, and the IIS logfiles show the spammers using a predictable path such as ctl=login (or login.aspx or /login) then blocking those with an IIS request filter should mitigate the issue but still allow users to login by clicking the link for the correct login page

cathal connolly Tuesday, July 15, 2014 5:20 PM (link)

@Cathay Connoly I have emailed 14 days of IIS logs from one of the sites getting hit the hardest. It's now been almost 3 weeks since we removed the ability to register, removed login links, setup "Abort Request" in IIS Redirect for any of the /login or /login.aspx or /?ctl=login and yet we still can't slow it down. We can't even login to our sites to do work anymore.

Paul Coffman Tuesday, July 15, 2014 5:29 PM (link)

@Paul I didn't know you disabled logging in. I am guessing it's only you who's able to use the login page using a custom url? Either your server is not powerful enough or you're getting hundreds or thousands of hits per minute. If your server is that slow I am guessing IIS is busy logging all the requests. Try disabling logging completely in IIS as a test and see if things improve. Even if you're getting requests from many ip addresses, they can be blocked. Use a tool like logparser where you can use sql like queries and find out how many distinct ip addresses they are. Whether they are changing over time. These can be added to a firewall, custom asp.net module or isapi and block them before reaching DNN.

Tony Henrich Tuesday, July 15, 2014 5:57 PM (link)

@Paul, I've received your logfiles and sent a response.

cathal connolly Tuesday, July 15, 2014 6:05 PM (link)

I am also suffering scam registrations from bots and have the luxury of turning off registration - at least for a while. however, while scanning my logs, it is plain as day that captcha has been demolished. also, I noticed a wide array of originating ip addresses, which leads me to conclude that the attacks are somewhat sophisticated, making the blocking of ip addresses at the firewall improbable.

I would like to see an organic systematic solution, if possible, which does not include captcha as it is an aggravation and impediment to site access. are there any predicted delivery dates for one? surely facebook, google, and others have addressed this problem.

tony bonn Tuesday, July 15, 2014 9:42 PM (link)

@Tony - captcha whilst imperfect is still typically the best way to guard against automated registration. We will be making a number of improvements to the captcha to make it significantly harder for automated bots, but will also be adding further layers of protection (see https://dnntracker.atlassian.net/browse/DNN-5494 for a list of some of them - others will be added closer to release but we don't wish to provide a step-by-step list as it may add spammers). These are all scheduled for 7.3.2 which is a few weeks from release.

cathal connolly Wednesday, July 16, 2014 4:55 PM (link)

@Tony - Recaptcha and Captcha are not the same thing. Technically recaptcha is already code that machines have not been able to read, and for this reason, it is much much harder to defeat with automated cracking machines. There is actually a really cool TED talk that explains it well. Recaptcha is also easier to read for humans. So grab the free recaptcah registrations module designed to defeat this problem at: www.interactivewebs.com

David Finley Wednesday, July 16, 2014 8:39 PM (link)

Captcha is the generic term (Completely Automated Public Turing test to tell Computers and Humans Apart). It's anything that a bot can't solve but humans can. It seems it's been associated with those images where the user has to enter what they see. However it could be anything. Entering the result of 6+5 is a captcha. ReCaptcha is just just one form of a captcha.

As proposed, DNN's captcha needs to be a provider type where the admin can choose which type they prefer to use; a stock one, recaptcha, solving a puzzle, entering the sum of two numbers, drag & drop puzzle, clicking a video to display some word... whatever or disabling it as is available now. So when one gets broken in the future, the admin can easily swap it to something more advanced. I prefer a simple javascript based one like adding two numbers. No squinting needed.

Tony Henrich Wednesday, July 16, 2014 9:26 PM (link)

@Tony - True enough in what you say. , but... Google is using two images in it's "recaptcah". Once image has been solved by machines and one has not. The one that has not has been identified as not solved by some of the most advanced automation available. They are automatically taking scanned word from their project to digitise the worlds books. They then use what they call "recaptcha" to have humans solve the hard words that automation can't. The results are cross matched with other humans guess of the word. For this reason, humans and machines usually differ, thus making this form of captcha much harder to solve with machines, and easier for humans. They also mix some secret sauce in there to make it even easier for humans and harder again for machines. It's really cleaver!

The bottom line. Once we used the google "recaptcha" all registrations stopped. So it's working well.

David Finley Wednesday, July 16, 2014 9:42 PM (link)

I know how recaptcha works. I have been using it since before Google acquired it. 1 or 2 or more images doesn't matter. It's still a captcha. It's just more complicated than a single image. The letters in the captcha DNN uses are too clear to be obfuscated by a modern bot. It was just a matter of time until a spammer noticed that DNN uses a simple, easy to break one and created a bot against it.

Moving forward, hopefully with 7.3.2, this issue should be over.

Tony Henrich Wednesday, July 16, 2014 9:59 PM (link)

What is the consequence of blocking access to /ActivityFeed/tabid/121/userId/1/Default.aspx
My sites are being slowed down by look-up of a user registration. I have written recapcha into the system, created a custom reg page for the site that require user registration and set user to non on 3 other sites that does not need reg, however, the boot that was created must not be very smart, as i think it is a two sequence deal, where it first register the user, than goes to update to fill inn all the spam links, all the ideas in this forum so far have prevented new registration, but since the boot does not know that, it tries executing step 2, filling inn user details, and that is what slowing system down, and create effectively a denial of service. I can live with user not being able to update their profile until a fix is created and wonder if blocking of the URL /ActivityFeed/tabid/121/userId/1/Default.aspx and send it to 404 will do that. Log shows multiple requests to this url

Vikingno Thursday, July 24, 2014 3:15 PM (link)

Vikingno Thursday, July 24, 2014 5:31 PM (link)

@vikingno : you can create a request filter to return a 404 for the ActivityFeed URL as well, if you like. You can use a regex match to 'wildcard' the UserId so it blocks all access to all user profiles. Or if you completely relocate the user profile page, just block the /ActivityFeed URL in the same way the registration page can be blocked.

Bruce Chapman Friday, July 25, 2014 6:32 AM (link)

I have solved my spam and run on my website, my log now have 0 attempt. I renamed and reworked the activity feed page and put a block on the old one. I set permission to view and update user profile and see activity feed to registered user only, so any user that do not confirm their registration via the email link will have no access to update spam into their user profile, this gave back the resources and site is now running fine and fast, in the reg side i did the recaptcha and the custom reg page.
Hope the new update will have some flexibility to thwart spammers, if not i will run my now customized version forever.

Vikingno Friday, July 25, 2014 7:51 AM (link)

@Vikingno - that is really good news! @Bruce Chapman - will these specific issues also be addressed in the upcoming release or do we have to resort to customization like @Vikingno did?

David Poindexter Monday, July 28, 2014 1:45 PM (link)

@David - the 7.3.2 release makes a number of changes (such as improving the captcha, changing the logic to make it much much harder to crack, changing the default profile biography field to a multi-line textbox etc.), that will solve the issue of future attempts. However things such as blocking access to the userprofile page are beyond the scope of that release - if you have a site that is occurring on you can apply a customization to block, but there are legitimate use-cases to not block so we will not be adding a rule for it

cathal connolly Monday, July 28, 2014 1:57 PM (link)

When will the 7.3.2 be released?

Paul Coffman Monday, July 28, 2014 2:29 PM (link)

@Cathal - totally understood and agreed. Thanks for the response!

David Poindexter Monday, July 28, 2014 2:45 PM (link)

7.3.2 has been in tested for a few days and is expected to be released early August (releases are quality driven so it's hard to give an exact date)

cathal connolly Monday, July 28, 2014 6:25 PM (link)

Awesome thanks @Cathal

Paul Coffman Monday, July 28, 2014 7:11 PM (link)

Final task for me was to remove all SPAM users. Easy with the Bulkusers module, searching for website not blank, and register date after April 1 2014, got over 1500 fake registrants, and I thought site was getting very popular. Then search Google for site:mysite.com to see all the benefitters of my slow reaction to my site popularity in form of activityfeed and profilefeed, then creating a wildcards the capture any instance of these new users, sending them to custom 404 error, expecting Google to dump their reference in next site crawl.

Vikingno Monday, July 28, 2014 10:46 PM (link)

Hallo all,
I am suffering from this problem to. 54000 users registered in one portal!
But something strange is also happening.
When looking/monitoring my eventlog is see record off type "Login failure" which is ok for me.
but I only see these record for the last two minutes. Record older then two, three minutes disapear.
All other records in the eventlog are ok. I monitored it also in my sql tables with the same result.
So I think the records are selectivele deleted. Is is by DNN core? do "something" inject/execute SQL statements?
any comment welcome.

Jan de Vos Tuesday, July 29, 2014 6:10 AM (link)

@Jan - all log event types support separate configuration so they can be enabled/disabled for individual portals (or for the full install), and also support retention levels. As an event such as login failure is common this is set up to only retain the last 10 entries -you can change this via admin->event viewer, scroll down and click edit log settings and then edit the login failure entry, however take care as setting it to a large value (or to "All") will mean more records are logged which can affect performance and database size.

cathal connolly Tuesday, July 29, 2014 6:21 AM (link)

If you are trying to identify the spammer accounts and have access to iis logs, you can search for "/?ctl=register". This LogParser query will help identify the DNN usernames registered this way:

SELECT date, time, cs-username
FROM '[LOGFILEPATH]'
WHERE cs(Referer) LIKE '%/?ctl=register'
AND cs-username IS NOT NULL
Order by date,time

I highly recommend Log Parser Studio as an interface for LogParser.

Eric Leasure Wednesday, August 6, 2014 3:11 PM (link)

I don't know how to access the SQL statement for authorization to unauthorize users to perform a mass delete as advised by Sebastian. I have 28000 spam registrations left. I have deleted over 5000 ...one at a time---enough to open up my site. Is there instructions (for a novice) on how to perform this task? I really don't think I can survive doing the rest one by one. (I had to buy a wrist brace yesterday: two clicks for every entry deletion plus emptying the cache about every ten deletes.)

More worrisome: I noticed on the activity log that some of the bot sites names that are already registered are logging in again. I have some screen shots to look at if it is helpful. Our registration is turned off, and these users are circling back to login again two or three users at a time. Is this something serious? It seems sinister. I know I need to get those registrations off the site. If I could get help with the above or the mass registration delete would release the publication, I would be very grateful.

Jan Friday, August 15, 2014 7:04 PM (link)

Spammer registrations are circling back and re-logging into my site. The activity log shows they login three or four at a time. For every three that get in, there about fifteen that fail. Registration is closed, so no new registrations. My host server provider thought you'd want to know this.

I have not figured out how to delete the registrations in bulk---I'm a novice, so I have been needing to do them one by one. 5000 down, 28000- to go. Explicit step by step instructions on how to perform bulk deletes would be very much appreciated. I do not have a programing background.

Jan Saturday, August 16, 2014 1:13 PM (link)

Jan, the Bulk User Manager v3.3 worked good for me (module available at the DNN store). First i mass deleted all the bounced emails harvested from my email system. (I used email confirmation with reg) Then, i searched for all users that had website or bio updated in their profile (as my website is not of the kind that you would need to have a bio) then mass deleted them all, without creating an email notice for each which would have overwhelmed my email system.

But until you have done so, just set profile edits available to admin only (module permission), then they cannot come back to update their profile with their latest blog, fake purse or other more questionable offering> If you search on your site with "site:mysite.com" on google you will see all profiles already indexed by google and others. Therefore I set profiles not to be indexed, created a root robots.txt for that area, created a custom 404 for the spamers benefit renamed my profile pages, and sent any click on any of these old links to neverland with a custom wildcard block, hoping that next web crawl will delete their reference because of 1 robots, 2 404 error and 3 non indexed in DNN automatic site xml. The least you want is for search engines to associate your siste with all the backlinks deposited by the spammers for questionable sites or products.

Vikingno Saturday, August 16, 2014 1:58 PM (link)

We are looking into using Bulk User Manager for deleting user accounts as well. However, how are you all going about cleaning up all the physical user folders in the /Portals/#/Users directory? Thanks!

David Poindexter Monday, September 1, 2014 3:05 PM (link)

After using the Bulk User Manager and hard delete them, the folders are empty, I don't have to many and was going to leave them, but before hard delete I exported a list that can be sorted in excel, so if I had time on my hand< i could just delete the empty folder using any ftp tool ex filezilla. If one first make a backup of the portal to the local machine, any over deleting can be restored.

Vikingno Tuesday, September 2, 2014 8:11 PM (link)

Thanks - not too interested in having to delete over 53k folders manually (especially given the crazy folder naming convention) just for this one site. Now multiply that by 100s of sites and that is our situation. ;-( So I really need a fully automated solution if at all possible. I was hoping to hear that Bulk User Manager also took care of deleting the user folders. These need to be deleted because the are bloating DNN FolderPermission DB table. If anyone can share some insights/guidance, it would be greatly appreciated! Thanks.

David Poindexter Wednesday, September 3, 2014 1:53 PM (link)

I went back and looked again, and it looks like the folders of the user id's I deleted is gone. Difficult to find since they are placed so randomly, but I am quite certain that they were removed by the bulk manager. Best thing would be to test it out on a dummysite. If not, delete the spammers, export your real users, delete all user folders and import the users again as new users. Have not tried it, but it is as far as I can see from the documentation possible with Bulk User Manager.

Vikingno Wednesday, September 3, 2014 9:11 PM (link)

Thanks! That sounds promising! We'll check it out.

David Poindexter Thursday, September 4, 2014 8:34 AM (link)

I have upgraded most of my sites to 7.3.2 and it seems to have helped. For those of you with thousands (I had one site with 47,000 spam registrations) and used the PHD Bulk User manager to remove them. It works great. BUT, don't try and do all at once, or it may freeze up. I did it one letter of the alphabet at a time from the spam user's name. So, I would use the module to permanently remove all users who's username begins with the letter "A", then when that was done "B" and so on. It takes a little longer, but the site, program never locks up. So far, all 92 sites are still clean. Now I have to figure out what's eating all my ram still, but even that has gotten better now that they've stopped trying to login.

Paul Coffman Thursday, September 4, 2014 1:56 PM (link)

I'm getting hundreds of Module load exceptions on my activity log. Is there something that I should do to get those to stop? Im pretty sure it is related to this spam problem.

Jan Thursday, September 18, 2014 4:37 PM (link)

@Jan, these are most like related to the Activity Feed. If you don't need it, I would recommend limiting access to only admins for the page.

David Poindexter Thursday, September 18, 2014 6:40 PM (link)

@Jan - please add a new item in the Community Exchange detailing the errors - it might be related but it might not. You could just have an issue with a module that logs an exception every time the page is loaded - possibly when a search engine bot indexes the page. Lots of exceptions doesn't necessarily mean problems with registration spam.

Bruce Chapman Thursday, September 18, 2014 7:09 PM (link)

I have found myself frequently revisiting this link when discussing the spam registration with others. However, many people are amiss to understand the add a request filter section, as the way it is presented in the linked post from above is a bit unclear.

However this alternate dnnsoftware blog post defines it very clearly and also lays out the pages in which changes have to be made and specific fields from within your site (so you can avoid direct modification of web.config).

http://www.dnnsoftware.com/wiki/page/replacing-registration-page-with-custom-and-blocking-the-default-register-page

Hopefully this helps.

Dustin Eastman Thursday, October 2, 2014 1:29 AM (link)

@David Poindexter and @Bruce Chapman, I tried what you suggested and both renamed and disabled the profile page to remove the errors being logged in my event log. But this did not solve it. Does anyone have a solution for the error logs getting generated for these users requesting /Activity-Feed/My-Profile/def/ErrorMessage and /Activity-Feed/My-Profile/userId/70

Jordan Tuesday, December 9, 2014 12:05 AM (link)

@Jordan - you may also want to try disabling your main Activity Feed page.

David Poindexter Tuesday, December 9, 2014 11:02 AM (link)

"Fake User Registration Spam" happen again!

Dear all,
I had this problem about 6 to 8 months back on my DNN 6.x sites.
Follow the recommendation I found from this discussion thread, I updated the site to 7.3.2, created custom registration page and added filter to block the following:
- example.com/default.aspx?ctl=register
- example.com/register

These fixes kept the fake user registration away for a few months, until this week.

During the past few months, I do have small number of user registration spam, once or twice weekly, which I believe were done manually.

Started about a week ago, I started to get more of these face user registration, started with 10 to 15 daily and increased to every 5 to 10 minutes, as of today. At this rate, it does not look like it's being done manually.

I like to know whether anyone else see similar pattern/problem, after applied the fixes and updated to DNN 7.3.2 or 7.3.3.

Thanks in advance for you feedback,
Sam

Samuel Phung Friday, December 19, 2014 12:42 PM (link)

@Samuel - we are seeing similar behavior with several client sites over the past 4 days. We have installed the iWebs registration module on two of them and it stopped registrations immediately. However, with another site, registrations are still coming through. Still digging for answers on this particular site. ;-(

David Poindexter Friday, December 19, 2014 5:50 PM (link)

We use a simple method to solve this issue. Check http://dnnmodule.com/ and click Register, you will see it will ask you to enter a extra specific word (in our site, it is "dnn") before register. This is not a problem for a human register, but it blocks spam program successfully.

It works perfect in our site. In fact, click "Admin - Event Viewer", we can see there are about 100 spam registers try to register everyday, but all of them failed because this modification.

We do this by modify DesktopModules\Admin\Security\Register.ascx (and also Register.ascx.cs), and I am very glad to share our modified files. If you like our idea, simply mail me at xiaoqi98@msn.com. And I will send our modification to you.

DnnModule.com Saturday, December 20, 2014 9:41 AM (link)

Like Samuel and David I began seeing an increase of new activity, escalating with the passing of three weeks. I had trouble with all my 6.9.x sites in the heart of last summer's attack. I upgraded to then 7.1.1 and used the Chapman post (custom reg page, register block) and then managed to delete my [mostly] unauthorized fake registrations. Overnight last night I had my hosting provider [ a DNN powerhouse and center of expertise] upgrade all my sites to 7.3.4. To my shock, I continued to get these attacks all day. Fortunately only a dozen or so for each site.

I'm going to look at "admin only" the Activity Feed [tomorrow] since I don't use it much on these sites and I did see it mentioned often in the cryptic language of the Event Viewer along with a slew of General Exceptions.

I appreciate all that Cathal and the DNN team do to make this thing work, but we need something else, OR we are all going to have to buy custom reg modules. I an using one on a production site with a page that makes a user type a string before it will even load the New Reg page, and it has never had an attack of the ZombieSpamBot on it.

Look forward to any additional insight from the community.

The sites of mine that are affected are NOT large or heavily trafficked. If the Core team needs access to look at any of it to help troubleshoot, I volunteer; swreg (a) sardawg.org.

sschleiffer Monday, December 22, 2014 9:08 PM (link)

I just upload our modification to http://dnnmodule.com/DNN73RegModification.zip. If anyone need it, just open http://dnnmodule.com/DNN73RegModification.zip with your browser and download it. Unzip what you download you will see 3 files (ReadMeFirst.txt, Register.ascx, Register.ascx.cs), open ReadMeFirst.txt to see how to use it.

Of course, it is just a temporary solution. I think DNN will introduce a more effective solution one day. But not every DNN site can keep on upgrading to the newest DNN version. So if you are suffering from the spam registration but can't upgrade your DNN site, I recommend you to follow our method (modify Register.ascx and also Register.ascx.cs). It is easy, but works perfect.

Mail me at xiaoqi98@msn.com if you need more detail.

DnnModule.com Monday, December 22, 2014 11:07 PM (link)

Thanks everyone for your continued vigilance and suggestions. We became aware of an uptick in the spammer registrations again, it appears they tweaked their scripts to look at the page first to calculate the registration page which means that the earlier mitigation of using a custom login page (and redirecting /register to a 404) no longer works. I did some intensive research at the weekend and prepared a list of 13 additional mitigations we can add, including a few that other CMS's such as Wordpress claim 99.9% success with. I'm discussing this with the team and the MVP's to see which ones really work and how best to add these to a future release. Note: a number of users have confirmed that if you set the registration to "verified" the users never return (as they are using spam email addresses) so you can then simply delete unauthorized users via the UI

cathal connolly Tuesday, December 23, 2014 12:05 PM (link)

Your note about "verified" is correct on one of my sites hat uses it. I did get over 150 registrations in the 12 hours since I wrote the above post. Further, making the "Activity Feed" page Admin only had no effect. I also got a couple of emails form real people whose spam emails had been absconded asking for me to remove them. I politely wrote back and did. A larger, more trafficked site's webmaster would have difficulty keeping up with such an effort.

sschleiffer Tuesday, December 23, 2014 12:28 PM (link)

I applied the dnnmodule.com Register fix discussed above and it stopped my 500 spam reg a day habit cold on one Verified site. Code is not my day job, but I was able to screen through the .ascx file enough to understand what it did. I have two suggestions if the Core team pursues something like this.
1. Figure out a way to make the "word" used a setting in the Admin>Site Settings, so each site could easily create their own 4 to 6 character [pure suggestion of length] "word" to use, rather than have to force many non-day job admins to mess with the host file structure editing/posting the Register.ascx file, AND not every site would be the same [protect against future script-writing bottom feeders from re-cracking it]. Naturally a default would be necessary for new installs.
2. Perhaps clean up the aesthetics of how it appears on the Register page; Kurt made it functional and understandable but it could look more like the rest of the screen.
I look forward to the community continuing to monitor, and the core team seeing a lot more of this picture than I do in solving it.

Best Holidays to all!

sschleiffer Wednesday, December 24, 2014 12:52 PM (link)

We have released a new version of the spam register module mentioned in this post. The new version supports the Google Recaptcha V2.0 and we believe this will be even better at catching this annoying crap!

Previously people have reported to us that they still get spam registrations when implementing out module. In all instances we have looked at, there has been other open registration systems on their site. We did find a very small number of registrations recently slipping through the module with Recaptcha enabled. We suspect the bot was updated to try and defeat captcha and recaptcha. Lets see them defeat Recaptcha 2.0!

David Finley Sunday, January 11, 2015 2:29 PM (link)

Wonderful David! Looking forward to implementing this because we have been scratching our heads profusely on several sites that seem to be "locked down", but registrations are still slipping through! ;-(

David Poindexter Monday, January 12, 2015 11:03 AM (link)

Today, as I am installing a fresh copy of DNN 7 to a new site, I got more than half a dozen spam registration.
During the installation process, it got stuck at the creating super user step for a very long time. At first, it appears like the installation has failed (I could not access the site from another instance of the browser). Then, after I restart the browser and access the site again, I am able to login to the site, and find out there were half a dozen fake user registration.

I imagine these robot scripts got to come from just a hand full of IP address. Is there a mechanism for DNN to detect inbound traffic's IP address and block certain IP from accessing registration page?

Perhaps, DNN Corporate can initiate an effort to collect a list of these bad IP addresses and make the list available to the DNN community, where we can implement steps to block these IP addresses.

Samuel Phung Thursday, January 29, 2015 11:26 PM (link)

@Samuel Phung, these ip addresses are fake (which are dynamic created by spam program), it is useless to collect them. I recommend you to follow my method (see my above comments) if you have problem to find a better solution to stop spammers.

DnnModule.com Friday, January 30, 2015 11:31 AM (link)

"Fake user registration SPAM" issue resolved (for now)!
After installing the "iwebs - Register" module and enabling this module to use the latest Google reCAPTCHA service, I've not seen any fake registration got through the system.

I like to thanks David Finley and Interactivewebs for sharing the "iwebs - Register" module to the community to address this problem.

I've been dealing with this fake user registration SPAM since May last years.
Cathal's recommendation, replacing registration page with custom and blocking the default register page, works for a while and was broken back in November.

I turned off user registration for a couple of months to avoid dealing with this problem, which is not an acceptable practice for a public facing community site. I managed to install the "iwebs - Register" module about 2 months ago and re-enabled user registration, using DNN default registration page and have not seen a single fake user registration got through the system.

If you implemented Cathal's recommendation, replaced default registration page with a custom registration page and implemented filter to block "< your website URL >/default.aspx?ctl=register ", you need to undo all of these and reverse back to using the DNN default registration for "iwebs - Register" module to function. (This is the case for me. I tried could not install this module last year, shortly after David announced the release of this module. I tested this module on a fresh install and works. After spending sometime trying different things, I find the custom registration page and filter was the problem preventing the "iwebs - Register" module from working.)

Until these robot script find their way to break this latest Google reCAPTCHA, this solution works for me.

Samuel Phung Monday, March 2, 2015 12:43 PM (link)

While the problem is not "Fake user registration", it's related.
I figure there are quite a few DNN guru paying attention to this discussion thread, I am sharing the information here.

As part of the problem I have with Fake user registration, I review the DNN's event log more frequent and pay attention to abnormal activities, and notice a surge in "HTTP Error Code 404 Page Not Found". While I don't understand the details, it looks like another robot script. Here are the summaries from a few of them. It seems like the robot script is going through different pages on the site.

Note: At this point, I have not notice any problem and I don't believe the robot script is able to do much other than increase loading to the web server.

I am hoping the DNN guru on this thread help explain the summary from the event log below.

[snipped]

Samuel Phung Monday, March 2, 2015 12:58 PM (link)

@Samuel the problem you listed is an old-fashioned spider-trap and not to do with spammer registrations. I snipped out the stack traces you posted as it interferes with the comment flow. If you have a problem like that, please post it in the forums or Q&A section of the website where you will get more visibility for the issue.

The bots you had on that are legitimate search crawler bots. You can verify the user agent and IP address to check on any bot crawling your site. Legitimate bots will also respect your robots.txt file so you can control their behaviour that way.

Bruce Chapman Monday, March 2, 2015 7:58 PM (link)

I think at this stage we are going to have unwanted users registering. Would this help http://declanward.com/Blog/tabid/119/ID/8/A-little-more-help-against-spam-users.aspx

Declan Ward Thursday, March 5, 2015 1:25 PM (link)

@DeclanWard that is exactly what i`m thinking too. Automatically delete spamuser after 60 minutes within a task. Will try your module now. thx, richard

Richard Tuesday, March 17, 2015 4:03 PM (link)

Products

Solutions

Resources

Partners

Community

About

New Community Website

Spammer registrations

Comments

Comment Form

NewsArchives

ESW Operations, LLC