I dont know how to stop them.  I continue to add filters to block their IP addresses, but that doesnt seem to stop them.  so far they are not doing anything harmful but creating fake phony accounts, and they keep missing a few fields, that I have set to required, but because the active social registration makes them a member after the first page, I think they created an automated script to just bumbard any site with new members every 10 minutes.

How can i prevent this?

I tried turning on the CAPTCHA feature in the registration.... That does nothing when you use the active social registration..

I may have to start looking at other alternatives..

Adam,

Have you tried blocking them from your hosting control panel? I had a few coming from an ISP in India and was able to block them after a few days...I had to keep adding IP addresses but it finally worked.

Terry

That didnt work. I have been blocking people, but they still keep registering with new IP addresses..

I have had around 60 new accounts registered in the past 2 days.

They are getting to the first page, and not filling in anything from the 2nd, 3rd, 4th page.

Each time I set up a new host settings filter, to block that IP that has registered with, and thought it would slow down, but it actually made it worse. Things just seem to be getting more and more.

I think I have to switch back to the private mode for a while, and I will authorize the people myself.

Are the IP's coming from the same country Adam? We get 99% of our spam from IP's in India or Pakistan. Since our readers are typically not from there I thought of using a module that will automatically redirect visitors from those countries to a different login page where they are forced to go through a multitude of forms before they even get to the actual real registration form.

If you're interested these are the two options I'm looking at. I'm going to include a captcha form as well on the first page.

http://ipcountryredirection.codeplex.com/

http://www.snowcovered.com/Snowcove...geID=13390

Thanks SilverSurfer.

I will check that tonight. I think they were from different IP ranges, and different countries, but I will go home tonight and try a few more techniques. I know today, there were another 10 or so FAKE accounts I have to go and delete.

I have to go through the logs, and then block all those IP addresses.

I wondered if there was a way to just block that entire country IP scheme. I could care less if they can check the website or not. Most of the visitors are based out of the US or in Japan.

Adam - you can block ranges using IP restrictions on IIS. A good firewall can do the same. We block entire counties on some of our sites. There are plenty of web resources available that will give you IP ranges by country. Not perfect but it's been very effective for us.

This is another idea I had, but I don't know if it's possible in DNN. I want to create a user group called "suspect users" or something like that. If I add a person to that role I want them to be able to post anything on the site, but for it to only be visible to other members of the same group or themselves.

In other words, nobody but themselves would see what they posted, so even if they spammed the site their posts would be invisible to search engines and everyone else reading the site.

If they are later determined to be legit posters based on their posts then they can be moved to another group and everyone will see what they wrote.

Anyone have ideas on how to do this. I know we can limit what roles can see what modules, but can we control who can see what based on the user role within the module itself?

We had the same thing on this site. We were getting them every minute or two. I made some changes based to the signup form last Wednesday and we haven't had any since. This change is also included in Active Social 1.3.4

Can I ask what type of change you made? Is there something behind the code, or something we can see from the view of the first page?

I just feel changing the way that the registration occurs, and requiring the members to complete the entire process or those NEXT pages and when they get to the final page, its complete, is a better system.

That means the automated scripts wouldnt be able to complete registration until they visited the last page of the registration process.

Also - why does CAPTCHA not work with the AS registration model? Is there a token I could add, which may be able to stop things?

Yes

No

If that's the case then just don't use the sign up wizard. Use the regular DNN registration form. The sign up wizard serves a specific purpose and is meant to capture new visitors with little resistance. Just because you recently got hit with a spam bot doesn't mean we should change everything. We find the problem and fix it while still keeping the main purpose in place.

I've had several registrations from spam bots over the past few days too. About 6-8 a day. Not doing any damage, but eventually they will start to bloat the DB. Also, I think the bots are "tripping" something during registration casuing errors during the registration causing the log to fill with errors, just a hypothesis at this point. Will I submitted a ticket in regards to the errors.

The IP addresses that I have been seeing coming through with the bots are from European area, generally they have been using one of the following domains for the email:



Those are the four culprits that are stealing my time and energy.

I've looked over the ticket, but thought others could benefit from the response as well. This isn't specific to Active Social. We get the same errors on this site with DNN 5.x. Never get the errors on activesocial.com with DNN 4.9.5.

The errors are viewstate validation errors. You will get them on nearly every form on your site that does a post back. We get them on our blog comments, registration forms, contact forms and login forms. These errors aren't anything new and they have been worse since upgrading to DNN 5. We were getting them on the standard dnn registration form long before we started using the signup wizard on this site. The problem is that DotNetNuke traps the error before the module can, which means we can't control the frequency of the error.

Captcha isn't the answer either, it actually makes it worse.

We are testing a couple other solutions, but it will take some time.

I will be trying out 1.3.4 today, and see if the BOTS stop.

I have been blocking each and every request manually though filters, and its slowed down, but the locations are all throughout the world, and not just 1 specific country.

Thanks for adding this in Will.

Will,

The New registration works to keep spam down. It has stopped for the past few days.

Just wanted to let you know.

Hmm - I am now getting this problem a lot worse - I get around 30 new users a day and have switched to 2 stage verification. Only about 5 new users verify their account. I had an issue today with an upgrade to DNN5.4.2 and when a new user joined it was timing out the site (but I was getting notified about the new user). One user joined 15 times with a different username (same email) each time - it had to be a bot just repeatedly hitting the site until it got through (I emailed them with no reply and no user would try 15 times to join a site that timed-out more than once).

Just thought i would mention it - not sure what the solution is (I don't show these users on PokerDIY but I would prefer not to let all these bots in - Captcha on sign up is the only thing I can think of although it is a major UI barrier)

Rodney, did you find the cause of your problem? I see that nobody replied on the DNN forum which concerns me because I don't want to have similar issues when I install 5.4.2

Unfortunately not - site has been unusable for 24 hours now... I am waiting for PowerDNN to do a rollback. I think it could be to do with the spider load issue - my SQL server is getting hammered. My test site is just not under load, thats really the only difference. In the past 2 years I have upgrade about 4 times and each time my site goes down for days at a time and I lose hair...

Just to clarify, when you say upgrade you are talking about a DNN 5.4.2 upgrade correct? Are you doing something to limit access to your site during the upgrade process? If not, you should with a site like yours I would do more than just create an appoffline file. Also, most of the failed DNN upgrades we have come across have something to do with the EventQueue table. The sites with problems tend to have entries that are no longer relevant.

Posted By Smart-Thinker on 01 Jun 2010 04:48 PM
Unfortunately not - site has been unusable for 24 hours now... I am waiting for PowerDNN to do a rollback. I think it could be to do with the spider load issue - my SQL server is getting hammered. My test site is just not under load, thats really the only difference. In the past 2 years I have upgrade about 4 times and each time my site goes down for days at a time and I lose hair...

Hang in there.  Been there done that myself many times.  The DNN upgrade process leaves a lot to be desired. 

Unfortunately my sites are not as big as yours but I always test the upgrade process on my localhost. When upgrading on my live site I still use the appoffline file to make sure that DNN keepalive services (or users) don't visit while I am upgrading. After uploading the upgrade package I delete the appoffline file and manually startup the upgrade process.

Since we're talking about this process. Here is my "ideal" upgrade process:

1. Test on a localhost install
2. Test on a local restored backup of my production site
3. Redirect all traffic to a "please standby" website (done using my firewall)
4. Restrict my production site to only my IP Address
5. Backup everything
6. Upgrade
7. Test production
8. Remove IP restriction, restore traffic to production
9. Monitor and test
10. Go to bed.

(I usually start these at about 1:00am to minimize downtime for users)

Posted By Will Morgenweck on 01 Jun 2010 04:53 PM
Just to clarify, when you say upgrade you are talking about a DNN 5.4.2 upgrade correct? Are you doing something to limit access to your site during the upgrade process? If not, you should with a site like yours I would do more than just create an appoffline file. Also, most of the failed DNN upgrades we have come across have something to do with the EventQueue table. The sites with problems tend to have entries that are no longer relevant.

Yes, DNN 5.2.2 to DNN 5.4.2. There is an issue in 5.4.2 where all spiders do not observe the module caching - hence every none browser request is going to hammer the server - that could be the problem but I am not sure.

I outsource all upgrades to PowerDNN (I think they have a one-click type upgrade tool) - I always do my cloned test site first (which NEVER fails and takes about 20 minutes) and then I do the live site which always fails and takes about 20 hours.

Thanks for all the suggestions on upgrading - I might start doing them myself as it's starting to get costly with all the rollbacks etc.

Rodney, there is a new upgrade and roll back module that just got released, I bought it but have not tried it yet. It might be a good solution for the future as you can roll back yourself if needed.

http://www.snowcovered.com/Snowcove...geID=17739

Hmm - interesting - I am not sure if I would trust a module with that scale of upgrade though - I would prefer to do it all manually. Has anyone used it?

Yes. Works great.

http://twitter.com/wmorgenweck/stat...4358751924

I just tried it last week. The current version wouldn't work with PowerDNN but they were very responsive. They are attempting to iron out their issues with PowerDNN before I retry it.

I hate to say it, but the majority of upgrade problems we encounter seem to be hosted with PowerDNN.

I also use PowerDNN and used their upgrade assistance once and have performed the upgrade myself. My biggest problem has been getting the upgrade files uploaded. I had to unzip the upgrade zip and ftp the entire directory structure over my current installation. I did this because I couldn't find a way to unzip it on the server.

Definitely backup your db and backup your site before attempting.