random title

Anti-spam: Dual honey traps

While posting the first article in the redesign series I realised I was in the middle of a spam attack. I got quite a few spam comments on my own blog, and more than a few on both Claires and Captain Ds blogs.

I spent quite a while last night deleting them from my main blog, and most of this morning deleting them from my supporting blogs (like my link blog) and from all the other blogs I host for my friends from this install. Inconveniences like these will make you understand that spammers are, to put it mildly, scum.

While I was deleting them from my blog, I grabbed the IP address of each spammer, so that I could block them with a .htaccess file. I found that there was a low ratio of comments to IP addresses. These things were coming from everywhere.

I implemented the Comment Spam Quick Fix from over at Burningbird, but I thought it could be improved.

I've renamed mt-comments.cgi to zombocom.cgi, and updated my templates accordingly. Anything that hits mt-comments.cgi automatically gets their IP added to the blacklist. This is the first honey trap.

The second honey trap is in the new comments script. Anything that fails the Comment Spam Quick Fix test also gets added to the black list.

I don't have a clue if this will work with version 3 of MovableType, but I suspect it won't. All I'm certain of is that it works with my copy of MovableType 2.661, which is otherwise unhacked. It may be possible to adapt it to MT3. Use this at your own risk.

First steps

  • Download a copy of your mt.cfg file.
  • Download a copy of your mt-comments.cgi script.
  • Rename mt-comments.cgi to a different file name (I use zombocom.cgi in this example).

The new .htaccess file

Put this in a file called “.htaccess”:

  1. Order Allow,Deny
  2. Allow from all
  4. # Automatically added

Download this code (1.txt), or download my most recent htaccess file.

Renaming the comment script

You've already renamed the file, now you need to let MovableType know about it. Open up mt.cfg, and replace the line that reads:

# CommentScript mt-comments.pl

With:

CommentScript zombocom.cgi

Save your changes.

Rigging the first honey trap

Take this code and save it as mt-comments.cgi

  1. #!/usr/bin/perl -w
  2. use strict;
  4. # Tasty honey
  5. open(DENY, ">>.htaccess") or die "Tried to add host (" . $ENV{REMOTE_ADDR} . ") to deny list, but failed to open file\nError: " . $!;
  6. flock(DENY, 2); # <-- Lock the file
  7. print DENY "Deny from " . $ENV{REMOTE_ADDR} . "\n"; close(DENY) or die "Tried to close deny list but failed (Host: " . $ENV{REMOTE_ADDR} . ")\nError: " . $!;

Download this code (2.txt).

Rigging the second honey trap

Update your templates as per the Comment Spam Quick Fix, but instead of their edit of mt-comments.cgi use the following code in the same place in zombocom.cgi:

  1. use CGI qw(:standard);
  3. if ($ENV{'REQUEST_METHOD'} eq "POST") {
  4. my $data = param('snoop');
  5. unless ($data) {
  6. # Tasty honey
  7. open(DENY, ">>.htaccess") or die "Tried to add host (" . $ENV{REMOTE_ADDR} . ") to deny list, but failed to open file\nError: " . $!;
  8. flock(DENY, 2); # <-- Lock the file
  9. print DENY "Deny from " . $ENV{REMOTE_ADDR} . "\n";
  10. close(DENY) or die "Tried to close deny list but failed (Host: " . $ENV{REMOTE_ADDR} . ")\nError: " . $!;
  11. die;
  12. }
  13. }

Download this code (3.txt).

Installing the spam fix

  • Upload mt.cfg, zombocom.cgi and the .htaccess file. Make sure zombocom.cgi and .htaccess have the correct permissions.
  • Rebuild your site.
  • Upload the rigged mt-comments.cgi script.

Hopefully this is of some use to you. It seems to be working for me... I've already caught a few bots while writing this article. If anyone has any suggestions or bugfixes, please leave a comment.

Comments

Michele:

Movable Type is terrible when it comes to comment spam, which is why I moved over to Wordpress. Blocking the IPs that are spamming you is fairly pointless, as they change all the time. There are other ways of stopping it, for example by user agent or through the use of challenges.
I've been trying a number of different techniques, but have finally settled on a random image code:
http://www.mneylon.com/blog/archives/2004/12/15/more-blog-spam-solutions/

Posted at January 1, 2005 10:28 AM

David Barrett:

I wouldn't say that blocking IPs is pointless, but after writing this I did realise that blocking IPs for an indefinite period of time was a really bad idea.

Blocking IPs is good for one thing: if you've detected that a certain IP is spamming you (through other spam-detection methods), you can block the IP to stop the attacker taking up precious CPU cycles.

But blocking the IP for an indefinite period of time is bad, as the IP that is blocked may be dynamic; when another user is given that IP, they will be unfairly denied access to the comment script.

A good solution would be one that, when a spam comment is detected, blocks that IP from using anything CGI for a limited period of time (perhaps a couple of hours). That way, any major spam attack from a single host, that is detected, can be handled easily.

Unfortunately, even what I've implemented didn't stop a lot of spam. I found I started to get a lot of randomised spam... spam which is made up of random characters, with a random (non-existent) domain name as a link. The only way I've been able to manage it has been through its own failings... it seems to only target specific posts, making MTs interface not completely useless when it comes to deleting them.

Based on the timing, and the complete pointlessness of the spam, my guess is that some spammers are googling "anti-spam" or something similar.

I've come up with another method of spam detection, based on Stop Gap Extreme in Wordpress, that should work better. I'm not going to implement it yet as I have a lot of work on my plate, and it will take to long to think it through. At the moment, I think layers of anti-spam techniques (least computationally intensive first) are the way to go... but I need to think about it.

I don't like using random image code, as this is inaccessible. Switching to WordPress is also a no-go, because even before the spam I was already pissed off at MT for really being just a blog engine. I have ideas for this site that are impossible to implement in either MT or WordPress, at least not without significant recoding of each.

O, and I hate PHP :)

Posted at January 1, 2005 01:55 PM
Copyright © 2003-2006 David Barrett. Valid XHTML & CSS.