-
Please support me in the 2010 Ride to Conquer Cancer - last year we were able to raise $6.9 million for the Alberta Cancer Foundation - hopefully we can raise even more in 2010! -
Blog under the Creative Commons Attribution 3.0 License
May
20
(2009)
Stopping Spamblog Registration in WordPress MultiUser
Filed under: work. Tags: apache, htaccess, spam, wordpress, wpmu.
I’ve been running a copy of WordPress MultiUser for over a year now. Comment spam hasn’t been much of a problem, thanks to Akismet, but if I leave site registration open (so students and faculty can create new accounts and blogs), the evil spammers find it and start sending their bots en masse.
I tried a few plugins, with varying levels of success. There’s an interesting one that attempts to limit registrations to a specific country, but it falsely reported some valid users as not being in Canada. Captchas work, but also block some valid users (and the signup captcha plugin I’d been using is possibly abandoned).
So, I did some quick googling, and came across the page on the WordPress Codex about using .htaccess files to stop comment spam. I made some modifications to the technique, and am now running it on UCalgaryBlogs.ca with apparent success. The apache logs show the bot attacks are still in full force, but not a single one has gotten through in order to register. And valid users have been able to get through. That’s pretty promising.
Here’s the technique – just drop a modified version of this into your .htaccess file for your WPMU server:
# BEGIN ANTISPAMBLOG REGISTRATION
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-signup\.php*
RewriteCond %{HTTP_REFERER} !.*ucalgaryblogs.ca.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://die-spammers.com/ [R=301,L]
# END ANTISPAMBLOG REGISTRATIONI put that block above the WPSuperCache block in my .htaccess file.
Modify the part that says “ucalgaryblogs.ca” to be whatever your WPMU server is (you may need to do more if you run multiple domains…), and modify the die-spammers.com part to point to wherever you want to send suspected evil spammers. I send them here.
What it does is detect any POST requests (submitting a form) for wp-signup.php, that haven’t been sent from a web page on the WPMU site or have an empty user agent string (identifying the software making the request), and sends them to a page that apologizes for any false positives (and provides a contact to get around it for valid users that somehow got sent there) and scolds evil spammers for being evil spammers.
The beauty of it is that it doesn’t require anything from WordPress. No plugins. No mu-plugins. No hacking core files. Nothing. Apache steps in and kicks spammers out before they get in at all.
That’s awesome. Great technique!
Wouldn’t it be more fun to send them to a page that puts their bot into some kind of endless loop. I guess they would have that figured out too.Is the the file you are editing the Apache file or the WPMU .htaccess file?
the endless loop would be interesting… Bad Behavior redirects people to fbi.gov so they show up in their server logs…
this is the .htaccess file in the root of the wpmu install – but it could just as easily go into the apache config file if .htaccess editing isn’t possible.
Thanks for this. It’s actually a decent solution. There is one thing you have to watch out for: Folks linking directly to your signup page from outside your site. We see folks give links as “You can sign up for a blog here” and then give the link directly to it. Since those are coming from outside the domain, that may cause issues. Maybe a workaround for that, and I haven’t looked at it, it to create some sort of landing page before hitting the form or embedding the signup form within a main blog page.
good point – but this is a WPMU install for use on a university campus, and I just tell people to go to the front of the site and follow the link. I’m ok with the risk of borking direct links to the signup page – there shouldn’t be any in my case. Hopefully…
I doubt that would be a problem – the user has to fill out the form on that page and then submit it. The referrer *has* to be the signup form.
Good catch, Donncha! Of course the POST request must have a referrer. There shouldn’t be much worry about valid requests being turfed, then. Spambots, begone!
It really depends. I’ve seen tracking software that does some weird stuff with POSTS and GETS.
One of my clients pointed out that instead of putting a domain in there as a referrer, it should be an IP address. If you use a domain, Apache has to do a lookup which takes time and increases load. If you’re using domain mapping, which you may not be on a college campus, it gets around that issue. I’m assuming that there would be a method of putting multiple IP addresses in there if you have a mu install spread out.
Also a suggestion not to send the spammer to some site like fbi.gov. That may get you in trouble legally as they may see you as the abuser.
Thank you! I just dropped it into the .htaccess files on my 4 mu installations. Will report back in a week or so….
Just reporting back: It will be a week tomorrow since I tried D’Arcy’s technique. I run 4 Mu sites …. to date 3 sploggers have gotten thru …. I’m wondering if these are live humans – slave labor – locked in a cell, pounding away at a keyboard. I’ve seen one of the “names” before….
yeah. I still get the occasional spammer getting through – but they’re having to do it manually, and FAR fewer are getting through as a result.
Over the last few days I have seen some registrations that I figure had to be real humans manually spamming. I had a Jim Kirk and a John Caparulo (Fictional/Celeb names, but no trailing numbers) … and what I found interesting was each one had chosen a different theme for the blog … not the default theme … I almost hesitate to delete them.
Almost. But then all the email domains seem to point back here: http://www.parallels.com/products/plesk/?cid=promo-plesk-domain
And if wpmu is on a subdomain I modify like RewriteCond %{HTTP_REFERER} !.*subdomain.ucalgaryblogs.ca.* [OR] ?
Sounds great, thank you! One question: If not running SuperCache, where in .htaccess should this go? Before or after uploads? Does it matter? Thanks again.
it shouldn’t matter much – just drop it directly above the SuperCache section, under everything else, and you should be fine.
Hi, I just saw, that you implemented Buddypress. I was just wondering, if your technique works with BP, too? I am not a programmer, so can you please tell me if I still should use the RewriteCond %{REQUEST_URI} .wp-signup\.php*
because I have deleted the signup.php and use only the buddypress register.php file.
Thanks for your advise, experience!
Sunny greetings from Switzerland,
Michael
ah, yes! this would have to be modified to handle the Buddypress /register url – I’m not sure exactly what that would take, but it may be slightly more complicated because the exact filename of the register page is hidden behind a prettified URL (so a simple tweak to the .htaccess line to catch %{REQUEST_URI}.register* would catch all URLs across the site that end in “register” – there could be Pages on sites that do that…
Ok, thanks. How do you do it on your BP-Site? Would that be bad, if it would catch all those register-pages?
While I have managed to defeat spambot signups, unfortunately, I was getting so many of the live human spammers that I finally disabled self registration on all my Mu sites. Now if someone wants a blog, they must contact me. Which kind of muddles the purpose of creating a social network. Sigh.
I have to admit, some of the human spammers were going above and beyond the call of duty. They picked out particular themes (instead the default) and added images to their spam blog posts.
P S Here’s a link to a post on WPMUtotorials about adapting for BuddyPress. http://wpmututorials.com/how-to/spam-blogs-and-buddypress/
thanks for this tutorial. I wonder, though, if this hack can be applicable to a regular (not Mu) WordPress site? I’m planning for a project to be a regular WordPress with open registration.
Hi and Thanks for the info! These spammers are a real pain in the arse! I tried just about every other fix that I was able to find….lo and behold the little bot blasters still get through. I just added your htaccess fix…..let’s see the little buggers get past this! Any type of bottleneck will be better then the current wide open no can stop them action I’m getting right now
Will report back in a few days!
Thanks again!
Hmmmm….4 new signups in the last few hours. Maybe I have the code in the wrong place? Here is what my htaccess file looks like:
———————
AddType application/x-httpd-php5 .php
RewriteEngine On
RewriteBase /
# BEGIN ANTISPAMBLOG REGISTRATION
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-signup\.php*
RewriteCond %{HTTP_REFERER} !.*sitesires.com* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://sitesires.com/spam-prevention/ [R=301,L]
# END ANTISPAMBLOG REGISTRATION
#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]
# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ $1/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
SecFilterEngine Off
SecFilterScanPOST Off
————————–
Any suggestions?
Thanks!
this won’t stop manual spamming by actual humans – you might be surprised at how many spammers employ farms of real people to bypass the automated defences, rather than writing better software.
I don’t know….the last 14 signups have all been a “name – letter – name – letter”, for example: johnfmichaelst
all of them were using a gmail account as well. Basterds
Thanks for this solution – we were getting upto 20 a day, I will let you know how we get on now it’s implemented
Again, thanks a lot
Sam
I was having this same problem on my WPMU and have disabled all registrations until they email me (same as Cheryl – above).
I think one of the ways to minimise this is to have a double opt in registration, where they have to go to their email and activate their link. Is there such a plugin for this? Or is there a hack that can be used for WPMU?
thanks,
Armand
The anti-spammer in me has a need to point out what you describe Armand is called “confirmed opt in.” “Double opt in” was a term created by spammers in an attempt to download confirming email registrations as being wasteful and annoying to endusers.
Reference: http://en.wikipedia.org/wiki/Opt_in_e-mail
Confirmed opt in is I believe what WPMu operates with. Clicking on a link in an email to confirm the registration is required. Unless I missed an upgrade in there somewhere that removed this. (Hope not…)
WPMU does have confirmed opt-in – you probably don’t want to add any more layers of email/confirmation to the process, as any friction makes people less likely to jump through hoops.
[...] WP-MU-Version fand ich Hinweise zum Spamschutz, manches gefiel mir nicht, aber der Hinweis auf Blocken per Referrer ist eine prima Idee. Zu finden ist die Anleitung auch im WP-codex, das habe ich aber erst [...]
I’ve added this to my htaccess file, will report soon to let people know if it has worked. I do get a lot of spam signups, I hope this will at least slow things.
[...] sent from a web page on your WPMU site or if it has an empty user agent string. Thank you again to D’arcy Norman for this [...]