How To Prevent WordPress Spam Comments From Crashing Your WordPress Blog And Taking Down Your Server

First off, I just wanted to clarify that this article is NOT about how to detect and flag comments as spam. The WordPress plugin Akismet already does a pretty good job of screening out and filtering traditional WordPress spam comments.

Instead, this post is about how to prevent comment spam and other rogue activity from crashing your server and taking down your blog.

Photo By BoxChain

As I mentioned in my last article, the traffic to my blog has doubled in the past year.

And unfortunately during that time, the amount of spam comments has increased by an order of magnitude as well.

Just to give you an idea, there were several days in December where I was getting bombarded with over 20 spam comments every few seconds.

Yes, you heard that right. Whenever I refreshed my dashboard, I would see 20 or more spam comments in my Akismet filter. In fact, the amount of spam made all of the websites on my server extremely slow or inaccessible for a long period of time during those days.

The Problem With WordPress

Now under normal operation, my blog does pretty well under heavy traffic because of a plugin called WP Super Cache.

Essentially, this plugin creates a static version of every article in my blog so that it can be served very quickly to the end user.

However, this plugin is helpless against a heavy influx of comments because comments require your server to call up WordPress each time in order to process the comments one by one.

And because WordPress is such a resource hog, a heavy influx of spam comments can easily take down any blog even if you’re on a dedicated server and you use a caching plugin.

It doesn’t matter if you use the best comment spam filters in the world, all spam comments still have to get processed by WordPress which takes a good chunk of server resources.

The Characteristics Of Spam Bots

Now having a slow or inaccessible blog is one thing, but comment spam also affects other sites that are running on the same server which is unacceptable. After doing some research about spam bots, I discovered a few things.

• Spam bots typically do not accept cookies
• Spam bots can leave comment spam in a matter of seconds
• Spam bots typically don’t run javascript

So what does this mean? In a non technical terms, a spam bot does not behave like a regular user on a web browser. And the key to solving my problem involved detecting the spam bot immediately and directing it to an error page instead of launching WordPress.

Based on the characteristics described above, I could detect spam bots either by placing a cookie on the user’s machine, disabling comments for many seconds after a page loads or coming up with some javascript code to detect the spam bot.

Solving My Comment Spam Problem

After much deliberation, I came up with a fix to secretly insert a cookie on the user’s machine whenever an access is made to a page on my blog. I could then look for this cookie on the user’s machine before allowing a comment to go through.

Because a spam bot typically doesn’t accept cookies, I could easily detect the bot and direct it to a static error page.

Originally, I was planning to post my source code on this blog entry which I wrote in javascript (I would be happy to send it to you if you are curious), but after talking to a few fellow bloggers, I discovered that the same author of WP Super Cache, Donncha, had already written a plugin called Cookies For Comments which essentially does the same thing that I just wrote.

Because his plugin is written a lot more elegantly than my javascript plugin, I highly recommend you go and download it.

But if you plan on using Donncha’s Cookies For Comments plugin, make sure you make the following change to your .htaccess which differs from the plugin’s installation instructions.

What do these 2 lines do? Basically, these lines of code detect the presence of the secret cookie that was inserted on the users machine. If the cookie is not present, the user or spam bot is directed to WordPress’s 404 page or “page not found”.

Now the problem with this default setup is that WordPress still gets called in order to process the 404 page which still requires a lot of server resources.

The difference here is that the spam bot is directed to a completely static error page which prevents WordPress from being loaded up altogether.

Problem Solved??? Not Quite

So the changes I described above fixed my comment spam problem, but after running smoothly for a few days, my server started crashing again! Looking at my server logs, I discovered the following.

mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar

Basically, some rogue machine kept trying to access the same nonexistent file on my server over and over which was crashing the site. Now with normal websites, these rogue accesses would not affect the server at all.

However, WordPress processes all accesses to nonexistent files and sends users to WordPress’s custom 404 or “page not found” webpage.

Did I mention WordPress is a resource hog? All it takes is a bunch of these bogus accesses and your server will still go down no matter what caching plugin you use.

The secret to solving this problem is similar to my comment spam problem. Ideally, we want to take WordPress out of the equation entirely and send the rogue user to a completely static error page in order to save server resources.

What does all this code do? Basically, when a file is requested from my server which matches one of the types above, I want my server to bypass WordPress altogether. If the file does not exist, the user will be directed to a static error page called 404.html.

Once again, bypassing WordPress is the key to solving my crashing problems. Because the rogue process in my server logs is accessing a .rar file, I now redirect this malicious user to my error page which takes practically no resources at all.

Does This Solve All Of My Problems?

So I’ve been running with the above 2 changes for a few weeks now and my server has been running like a champ with no slowdowns. Unfortunately, the way WordPress is written makes it impossible to prevent all rogue accesses from crashing your server.

For example, whenever someone tries to access an article that is not found on my blog, WordPress still gets loaded. So in theory, if someone wanted to take down MyWifeQuitHerJob.com or any WordPress blog for that matter, all they would have to do would be to access nonexistent pages on the site over and over.

But in the meantime, everything seems to be stable on my end. Hopefully in the future, WordPress can be patched to address these server issues.