Tag: spam

where the wild (spammy) things are

Wordfence automatically blocks IP addresses that repeatedly attempt to brute-force logins on UCalgaryBlogs. After a few attempts, they aren’t able to try again for a few minutes (in case it’s a legitimate person trying to log in, it doesn’t banish them entirely right away). If they knock it off, the ban gets lifted. If they keep hammering, the ban gets escalated, eventually putting them in a permanent penalty box (identified by their IP address – not perfect, but it’s all we have).

wordfence-countries-report
Blocked logins by country, August 8-22, 2016

I was half tempted to just drop the ban-hammer on the entire country of Russia, but we have students there (and I wouldn’t want to anger Putin or his tiny-handed American mouthpiece). The US? Buffalo appears to be one of the biggest sources of spam bots – colocated servers (compromised? rented by spammers?) are a big chunk of the attacks we get.

battling spam on the campus wiki

The University’s campus wiki, wiki.ucalgary.ca, is still run as a semi-stealth pilot project. This seems strange, after running it for 7 and a half years (first edit, December 11, 2004), but it’s something I initially snuck onto a server, and it kind of grew from there. It’s still running on an aging and borrowed/scrounged server, and I’m supporting it in my spare time. Which means, it’s basically self-supporting. Which is fine, because the people that have been doing awesome stuff with it are a pretty self-supporting group. I’m working on getting the wiki adopted by IT so it will be properly managed, but that process takes time.

But. The spam. The wiki was configured to be open, allowing anonymous edits. The idealist in me wanted to provide a way for people to contribute without worrying that their edits would be tracked back to them. I’d even initially allowed anonymous edits, so people could edit without logging in at all. Sounds good in wiki theory. But in practice… The spam. It burns. It didn’t take long before I had to kill anonymous edits. The spam bots were drawn to that like fetid moths to a rancid flame. But I fought the urge to require campus authentication. The spam piled up, but was manageable. Until lately, when I just haven’t had the spare time to devote to pruning the rotting garbage that builds up.

So. I just installed an extension that will restrict new accounts to require a @ucalgary.ca email address. You can still use whatever you want for a username (use a pseudonym, nom de plume, whatever), and it’s not authenticated against the campus directory or anything. But you need to have a @ucalgary.ca email address to edit.

This feels like a decent balance, assuming students still have access to a campus email address. This is debatable. On ucalgaryblogs, less than 1/3 of students use their @ucalgary.ca email addresses. Is this because they haven’t activated them, or because they simply choose to use a hotmail or gmail or whatever.com address? One way to find out…

Anatomy of a spam blog attack

UCalgaryBlogs gets hammered rather hard by cretins looking to insert their rancid spam into any corner of the internet that helps people publish content. One just got through, and I did some quick digging to see how they did it. Persistent buggers.

I get an email notification any time an account or blog site is created. The username looked suspicious. I popped it into an IP locator, and found they claim to be from Alabama. Dothan, Alabama, to be precise. About 100 miles northeast of Pensacola, Florida. Not many UofC students are likely to be signing up for a new account from Alabama…

I poked around in the webserver logs, to see what that person had been up to.

Turns out they spent almost an hour and a half trying to get an account created. Their first attempt triggered the antispam scripts, and they got sent to a page that scolded them for being spammy spammers. Almost 45 minutes later, they came back to the signup page, but not before changing the user agent of their browser. It looks like they modify their browser’s user agent regularly, claiming to be either running MSIE 8 on a Media Center PC, Mozilla on a Media Center, Firefox on Windows NT, Google Chrome on NT, Safari, etc… They get to the point where it looks like the user agent string is reporting strange hybrid combinations that probably don’t exist in the wild.

Eventually, they get through to the signup page, and get the confirmation email. They click the link to confirm that they’re a verified human (ironically, reporting their user agent that time as being Googlebot 2.1).

They get a site created, and start customizing it a bit. The user agent strings settle down, so I’m guessing an actual human was doing this part. They change the blog’s theme, and start to access the xmlrpc interface to automate publishing content.

Right when I come down and flag their account as spam, take the blog site down, and ban their IP range.

So, they spent an hour and a half trying to circumvent antispam measures in an attempt to set up a splog site, and I squashed them in maybe 2 minutes (really, it took only a few seconds to squish them, but I got curious, and that took a little longer). This little exchange cost them far more time and effort than it did me, even though much of their work may have been automated. I just don’t get why they keep coming back…

Screen shot 2010-11-24 at 4.05.11 PM.png

Update: It just hit me – it’s even more obvious that something is fishy with this particular douchenozzle. There are no requests for images, css, or javascript files that are part of the pages they’re requesting. Clearly not a normal browser, and likely some custom scumbag spam automation app.

stopping splogs – the nuclear option

I’ve been battling sploggers on UCalgaryBlogs continually. I just finished marking about 50 users/blogs as spam – that’s since yesterday afternoon. I could easily stop the problem outright by requiring people to use an @ucalgary.ca email address to create a site, but that goes against the possibility of anonymity, and many (most!) students don’t use their campus email addresses.

I currently run [Bad Behavior](http://www.bad-behavior.ioerror.us/), as well as [ReCaptcha](http://www.google.com/recaptcha). They stop the automated splog creation scripts, but there seem to be a LOT of people employed around the world to manually enter forms in order to get around captcha and anti-spam/splog techniques.

In looking through the WordPress.org forum on multisite (nee WPMU) issues, I found a new post called “[Splog Spammer Final Solution?](http://wordpress.org/support/topic/splog-spammer-final-solution)” It sounded a little like overkill, but when I thought about it, almost all splogs created on UCalgaryBlogs have come from a handful of countries. Countries where it’s not very likely that students and faculty will be creating new sites from. So I decided to try it out.

The forum post [links to a page containing lists of IP addresses and blocks](http://www.countryipblocks.net/networking/top-10-global-spammers-1q-2010/) belonging to countries where splog/spam activity is off the charts. All you do is copy some text, drop it into your .htaccess file, and hey presto. No more sites created from those countries.

Initially, I just banned all access from those countries. But that felt like a pretty slimy thing to do. So I stepped back and am now only blocking access to the site creation form wp-signup.php from those countries. If anyone affiliated with the university needs to blog while traveling the world, they’re free to do so, but they’ll need to have created the blog site from outside the Spam Zones. They should be able to access their sites, post content, etc… from anywhere.

I just tested the new splog-blocking technique, and it appears to be working. I’m really curious to see if it makes a dent on new splog creation.

The wp-signup.php script is [blocked](http://www.websitepulse.com/help/testtools.china-test.html) in Spam Zones:

Screen shot 2010-10-05 at 10.50.54 AM.png

But the rest of the service is available as usual:

Screen shot 2010-10-05 at 11.33.37 AM.png

The .htaccess file for UCalgaryBlogs now contains this at the bottom (after the WordPress stuff):

# block the fracking evil splog spammers

order allow,deny

(the contents of the various country block files go here)

#
allow from all

**Update:** Duh. Instead of trying to blacklist IP addresses and blocks of suspected spammers, it makes more sense to whitelist IP addresses and blocks that are likely to be used by valid users trying to create sites. I’ve modified the .htaccess file to deny access to wp-signup.php to everyone but those accessing from IP addresses that don’t smell suspicious…

spam irony

A spam roach managed to get through Akismet, .htaccess filtering and Bad Behaviour, to crap this little gem on my previous post. Thank you, Google, for giving these cretins a business model that makes this kind of nonsense worth their time.

spam_irony.jpeg

(actually – this isn’t irony at all. it’s brutal honesty. admirable, even. we should all be so honest…)

more fun with antispam measures

The spammers have decided to try crapping on my blog again. Distributed spam botfarms – Chinese, Hungarian, Latvian, Turkish, and now even Israeli (I didn’t know spam was kosher). annyway…

I had to crank up the antispam countermeasures a bit. Akismet wasn’t stopping them, so I’ve added Bad Behavior as well. Hopefully there won’t be any false positives. Bad Behavior always makes me a bit nervous, as it’s rather final and unforgiving. Both very good things if it’s right, but it’s occasionally wrong…

Blocking Spam In Mediawiki

Too much spam garbage was leaking into wiki.ucalgary.ca so I wanted to beef up the antispam strategy a bit. Currently, the antispam setup is:

  • Bad-Behavior blocks all requests to the webserver from evildoers (but I worry about false positives, so have whitelisted the entire UofC network)
  • users must be logged in to edit (but anyone can create an account)
  • SpamBlackList uses Wikimedia’s blacklist to block edits
  • regex rejects content with sneaky hidden CSS attributes
  • ConfirmEdit adds an extra step if content smells funny, as well as providing a simple match-captcha on account creation
  • SimpleAntiSpam adds an extra (hidden) step to trip up bots

I followed some of the excellent instructions on the UMassWiki on tweaking antispam extensions and config: UMassWiki:Blocking Spam In Mediawiki – UMassWiki. (note there’s a problem with the current version of Bb2ext – the Bad Behavior Extra extension – that is easily fixed by following the instructions on the talk page for that extension)

Stopping Spamblog Registration in WordPress MultiUser

Comment Spammers Burn In Hell...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.

Continue reading “Stopping Spamblog Registration in WordPress MultiUser”

Trying WP-SpamFree

end-blog-spam-button-01-blackThanks to a tip from David Esrati (who I’m not going to link to from this post because I’m taunting spammers and don’t want to inflict collateral damage on him), I’m testing out WP-SpamFree which is a really interesting antispam plugin for WordPress. I’ve used Akismet and Mollom before, and I’ve always been uncomfortable with externally hosted antispam systems. For some reason, I’m just not completely comfortable with relying on another server for this. I’d used Spam Karma 2 with great success, but since that went defunct I abandoned it as well.

Now, WP-SpamFree seems to offer an intelligent antispam system without relying on external servers or blacklists. I’m giving it a shot. So far, it’s been pretty successful.

Let’s see how well it does. Bring it.