also spracht martad

Weblogs are intrinsically subject to spamming and other security breaches, due to their own participated nature. Some degree of protection is provided within the default WordPress installation —but the way the Internet is going, the protecting “walls” need to be much thicker than that, or spammers are guaranteed to attack your new WordPress blog within hours from making it publicly available on the Web.

Securing and fine-tuning your WordPress installation requires acting on three separate and complementary aspects: administrative access, spam protection measures and directory permissions. Administrative access rules and (some degree of) spam protection measures are offered by WordPress in your blog’s Site Admin interface, whereas permissions are accessed through FTP, Telnet/SSH or pair.com’s ACC.

I describe here how you can improve security on the test blog we have just finished installing, and suggest that you follow the same procedure after installing every new blog you want to set up.

Default administrative access rules in WordPress

First, we adjust WordPress’s default installation to provide better protection on your blog by changing the default admin user. As you would have noticed, the (in)Famous 5-Minute Installation of WordPress creates for your new blog a (default) user with unlimited administration power. This default user, which has your email address (as you specified in Step 9) and a random generated password, is simply called admin. Basically, this means that all WordPress blogs have, by default, a user with maximum administrative privileges, whose name is admin —and if a malicious spammer Martian wanted to interfere with your blog, chances are that it wouldn’t take too long for it to “guess” the admin access password that WordPress assigned to this newly setup admin user.

So what I did to avoid this potential security breach, and what I suggest that you do now, is to first create a new user with admin privileges, and then demote the default admin user to the role of Subscriber. Like this:

1. In Safari, navigate to your blog, which for the purpose of this tutorial is at http://www.soapboxcorner.info/martad7/
2. Click on the Site Admin link, which is usually the first item in the sidebar navigation menu under the Meta heading.
3. Login with your default username (admin) and the password WordPress assigned to this user (as explained in Step 9 of this tutorial).
4. Click the Users link at the top of the Dashboard page (admin interface).
5. Fill in the fields for adding a new user (yourself, with a username and password of your choice) and choose Administrator for this new user’s role. Choosing a non-intuitive username and a strong password will of course offer greater protection.
6. Log out as admin, then login again using your newly created Administrator account.
7. Go back to the Users page and select the checkbox next to the (default) admin user.
8. Under the user list, click the radio button next to Set the Role of checked users to, select Subscriber from the drop-down list and click the Bulk Update button.

With the default admin user relegated to a Subscriber role, you won’t have to worry about anybody mistakenly or maliciously trying to break into your blogs. On a side note —if you were wondering why didn’t we simply delete the default admin user… well, it’s because we can’t. In other words, WordPress does not allow deletion of the default admin user (this might change in future versions).

Spam Protection Measures

WordPress offers some degree of spam protection features in the Discussion and Privacy tabs of the admin interface Options page.

Changing the default settings will affect how easily spammers will ever be able to use WordPress’s Comments feature to “write” to your blog. So for instance, if you uncheck all the checkboxes in the Discussion Options page, except the ones for Allow people to post comments on the article and An administrator must always approve the comment, nobody will be able to post a comment without you (or another administrator you set up in the Users page) first approving it.

However, changing these settings in the admin interface of your WordPress blog will not automatically protect you from receiving spam, masqueraded as “comments”, on your admin email address. What you can do to block this kind of spam requires activating some extra features.

In previous versions of WordPress, the Comment Moderation section in the Discussion Options page had a link to the WordPress Codex Spam Words List, which could be used to populate the available fields for Comment Moderation and Comment Blacklist. I recommend that you browse around the WordPress Codex, starting from the Spam Words List page, for better ways of protecting your blog and your admin email address.

If, like me, you choose to use this list of common spam words in the available field for Comment Moderation, you might want to also add the word blogspot. Judging from the spam I received before activating the Akismet plugin, most spammers these days are happily hosted (and probably actively helped) by google’s own “free blogging tool”, blogspot.

Directory Permissions

In short: Directory (and file) permissions, sometimes referred to as privileges, tell the Web server whether a certain directory (or file) can be “served”, and who can access it.

If you are wondering how come these permissions affect WordPress, and why should we bother, the answer is that WordPress (the blogging software) needs to talk to the Web server and obtain “permission” to create and display your blogs, which are nothing but dynamically generated Web pages. If permissions were too strict, WordPress would not be able to work; if they were too loose, your Website could be accessed too easily, and therefore possibly compromised.

The remote host we use for our blogs, at pair.com, runs the Apache Web server, which understands and interprets Unix permissions. On pair.com, we do not really need to worry about directory permissions on blogs, because the default value for newly created directories (on your pair.com remote host) already offers a good protection level. By the by —because WordPress requires access at the directory level, here I will only look at directory permissions; and if you wish to get a better grasp of the bigger picture and understand the way Unix permissions work, you can refer to pair.com’s Knowledge Base article.

So for instance, the default permissions for the directory that contains our first test blog (as explained in Step 7) are drwxr-xr-x, which indicates that:

• You can read, write (which includes delete) and execute
• Other people on your pair.com’s server (computer) can read and execute
• Anybody else, including the general public, WordPress and the Web server, can read and execute.

Because anybody else’s permissions are limited to reading (files) and executing (programs, scripts), but only you can write to your own directories, your blog on pair.com is fairly well protected against accidental or malicious damage coming from “outside”. An implied drawback in this security model is that it limits a small set of WordPress’s own capabilities. Therefore, some WordPress users choose to change (loosen) permissions on their server, so that WordPress can write to its own directory.

I did not do that. Unless one wanted to change permissions twice (from tight to loose, and then back to tight) every time WordPress needs to be given write privileges, allowing WordPress unlimited access to the blog’s directory implies giving the same rights to the whole world —and as you probably know, there are in today’s world too many malicious people, who would make terrible use of this privilege.

There are in fact, I believe, better ways of obtaining similar results to what WordPress would do if it had unlimited privileges. Basically, WordPress needs write access for a small subset of functionalities, i.e. for those tasks that require changing (writing to) any of the files in its default installation (the actual contents of your blogs, i.e. your posts, comments, links and so on, reside in the database, and are therefore never written permanently to a file). In summary, WordPress would need write privileges if you wanted to do any of the following:

• Edit the .htaccess file to change the permalink structure. You would have come across this concept in the Option –> Permalinks page of WordPress’s Site Admin interface, and you can refer below for a workaround that does not require changing permissions.
• Change any of the files, which make up your installed Themes or Plugins, directly through the Presentation –> Theme Editor or Plugins –> Plugin Editor pages of WordPress’s Site Admin interface.

That’s it. There are no other reasons why you would want WordPress (and the world at large) to have write permissions on your server. So what you can do to perform the above functionalities without changing directory permissions, is to manually change the files that need changing —and by the way, it wouldn’t help at all to be able to change those files through WordPress’s Site Admin interface, unless you knew how to change them manually!

For now, I will only describe how you can manually change the .htaccess file, so that you can customise your permalink structure (some reasons why you might want to do this are explained in my article on Installing multiple WordPress blogs). One or more of my future Tutorials will guide you through the process of customising or creating new Themes.

Again, there are several methods for changing the .htaccess file to allow a custom permalink structure. The way I do it implies creating an .htaccess file, then editing it in a text editor before uploading it to your blog’s directory. You can follow (or skip) my detailed instructions for this:

1. Open a session to your pair.com’s Account Control Center.
2. Choose File Management, then “jump to your Web directory” by clicking the Web button under Jump to a Directory, at the top of the File Management page.
3. Click the folder icon next to the main directory you set aside for your blogs (for the purpose of this tutorial, we are using sboxcrnr)
4. Click the folder icon next to the directory where your first (test) blog is installed (for the purpose of this tutorial, we are using martad7)
5. Click the Web settings button for the blog’s (fictitious) [...]/sboxcrnr/martad7/ directory, then the Directory Listings link.
6. Select “Do Not List Files”, then press the Update button. This creates an .htaccess file with an added layer of protection, which effectively “hides” any file contained in this directory (also see Note 1).
7. Now start Transmit and open an FTP session to your remote host on pair.com. Make sure that Transmit’s preferences are set to show hidden files.
8. Navigate to the [...]/sboxcrnr/martad7/ directory and select the .htaccess file.
9. From Transmit’s File menu, choose Edit in External Editor (⌘J). My preferred text editor, and the one I set up on my Mac for editing remote files, is BBEdit, which launches (if not already open) and displays the contents of the .htaccess file.
10. Now login to the Site Admin of your test blog and click the Options tab, then the Permalinks sub-tab.
11. In Common Options, select Custom, specify below.
12. For Custom structure, enter /%year%/%postname%/ (this creates the shortest possible descriptive “permalinks” for your blog).
13. Now press the Update Permalink Structure button. You’ll notice that towards the bottom of the page, a text box displays some code: click once in the box, “select all” (⌘A), then “copy” (⌘C) and “paste” (⌘V) this code in your local (open) copy of the .htaccess file, appended to the existing text.
14. Save the file locally, in the right place (i.e., the directory on your computer where you already saved a copy of the wp-config.php file for this blog, as explained in Step 7 and Step 8 of this Tutorial).
15. Then, use Transmit to upload a copy of the .htaccess file to the blog directory on the remote host ([...]/sboxcrnr/martad7/ for this Tutorial).

Notes:

[ 1 ] While you are there… Make a note of the kind of permissions (listed in the Access column) for the main directory you set up for your blogs: for added security, you might want to change the default value, drwxr-xr-x, to drwxr----x. Also, you might want to add an .htaccess file to that directory, as explained at V. and VI. above.