Recently there has been a lot of discussion in the community around DNN Spam registrations and methods and processes to prevent or fix the issues that are associated with them. I've been debating on if/when I should actually write about this given that there is an Official DNN Software response on the issue, as well as many other community comments. Well, tonight, while on vacation I had a server go down and guess what it was because of this very issue so I think its time to give my quick perspective and recommended action points for those of you that are running a DNN site. These recommendations apply for ALL DNN versions!
Update Registration Mode Setting
If possible, set your registration mode to "none" if you don't need public registration. This is a great first defense. If this isn't possible, then go with the next best step and that is to create a custom registration page. If you do this, though make sure that you follow the instructions in the next step.
Optional: Add IIS Request Filtering
One of the recommended "stop-gap" items that DNN Corporation recommends for those that cannot set registration to "none" is to set a filter in IIS for request filtering. I STRONGLY recommend this solution and am rolling this out to ALL DNN sites that I manage or have any control over that need to allow user registration. This will prevent the most basic backdoor used by these scripters which should at least help limit things a bit.
Post Change Investigation & Resolution
This is the key, the above changes are quick & easy, but it is the investigation that is key. I'm writing this post because of the investigation and resolution that I had to do tonight while on vacation. I had a server that went down, with a client database that grew from 45mb to almost 1gb in 7 days, had a user count grow from 2 users to 197,000 users in that same 7 day period. All of this happened silently, without stressing server resources, without setting off any DDOS alerts or anything. How did it become an issue today? The site owner tried to make a change and then it fell on its face.
So, given that this can be a silent threat to your site, what do you need to look for, and what actions can you take to fix? Lets look at these next.
Do you have impacted Users?
If you are lucky, your site will not have any impacted users and you can stop here. However, if you go to "Admin" -> "User Accounts" and see that you have 50,000 users when you should only have 10 you have some work to do. This is the fastest way to look at things and identify what is going on. If you have rogue users you will need to do two things to truly 'clean' your installation from these user accounts.
Delete the User Accounts
The first step in resolution is to get rid of the users that are impacting the site. How you accomplish this is going to vary a bit. If you have 5, 10, 20 SPAM users, just manually use the DNN delete features, but make sure to note the User Id value for each user. If you have a lot of users, for example in my case more than 100K users to remove, you are going to want to investigate a scripting solution.
I will not post direct SQL here as you NEED to be a user with proper SQL knowledge to do this, but you can do this VERY fast and very clean within DNN. Simply set all of the users that you need to remove to "Deleted" in the database, then use the "Remove Deleted Users." Now, this process of having DNN remove the users might need to be repeated as there is a 30-second timeout on DNN database queries. In my case, it took 10 attempts to remove all.
Delete the Folders & Re-Sync Files/Folders
This is one area that is not often remembered by administrators with fake accounts. Each user that is created in more current versions of DNN have a folder created for them inside of the user's folder within DNN. You will want to go in and delete all of these folders from the filesystem. Then once that is completed you will want to go to "Admin" -> "File Manager" and sync the filesystem. This is imperative as more entries in the folders and permissions table will slow down areas of the site that interact with these tables.
Conclusion
We need to see what the final fix is for this issue, but in the meantime, we need to be vigilant and keep our own sites as protected as possible. Given the nature of this issue, I am being a bit vague in recommendations as the exact solution isn't going to be the same for all users and sites. If you have comments feel free to share them below, if you need help cleaning up my company IowaComputerGurus is always available to help.