Security Tips and Pitfalls

Some of the basics…

General:
Do not use single (and obvious) word or name passwords for your logins. It’s amazing how often a simple rule like this is ignored. Use a password generator, or think up a not so obvious combo of words, numbers and phrases; and implement different passwords for each login you have (including your host admin account and MySQL user, if possible). If you need to keep a physical copy of passwords somewhere, don’t make that taped to the monitor or stuck on a bulletin board next to your desk.

WordPress:
Delete all import*.php, install*.php and upgrade*.php files in the wp-admin/ directory. Though unlikely to cause problems, once WP is installed (or upgraded) and running there’s no need for them. If *not* allowing user registration, wp-register.php (blog root) can be removed.

Server:
With directory permissions, typically 755 is best, though many setups (or certain directories) require 775. For files, use 644 (or 664). The goal is to not provide public write access to anything. Exceptions are to low-priority, temporary files and directories such as a cache folder, but even here there shouldn’t be a need to make them publically writable. If so, something is off with the server. If your host cannot make the appropriate changes, think about a new host.

For those a bit more serious about securing WordPress, look into restricting access to the wp-admin/ directory. There are javascript and php tools for this, but the most secure way is to lock a directory down through the server. For Apache, search the Web for information on .htaccess/.htpasswd.

When you say use 644 for files, does this mean that when you make any change(s) to various templates within the active theme (e.g., index.php, the stylesheet, page.php, about.php, single.php, etc.) you must first be at 666 (“if this was writable, you could edit it”) to make changes, but then change each of these files back to 644, every time? Just checking.

666 on files is permission overkill, in that it allows public write access, which as we know not a good thing (ironic that 666 is bad here, eh?). 664 should be enough in most environments, providing write access to owner (user) and group.

When *I’m* editing files over HTTP, the server sets the owner of the process or request to me (that is, my host account). This is an issue of trust, in that it assumes I’ve added the script or program that performs the action. For the best of security I could remove write access to every level, but giving write permissions to user is an acceptable compromise. With several different ftp logins (as I have) uploading files, write access to group may be necessary to avoid conflicts between file owner and user request.

Where the above doesn’t work, it’s likely the server is set to generically assign ownership to nobody or wwwuser or some such to any process on the server. This is common on user-type hosting, and it can be a bit more protective to the server as a whole, but it’s not the most adept way of juggling security with accessability. If you’re stuck with this but still need to edit files online, then switching permissions from 644 to 666 and back is the smart if complicated way of securing your site.

A long jaunt to answering your question, but hopefully I’ve explained a bit of the why.

I hope it’s ok to jump in on this? I’m new to this forum and also a newbie webmaster.

I tracked Kafkaesqui’s post up to “Servers” and promptly got lost. Can someone point me to some reference so I can understand it?

I have started doing some work on this in the form of “WordPress Securify v1.0a”.

It is a simple shellscript that currently supports the following features:
– Removing .txt/.html/import*.php/install*.php/upgrade*.php files…
– Renaming default directories…
– Remove WordPress Version

Future releases will include:
>> Removing the software type
>> Rename filenames “wp-filename” to “random_filename”.
>> Check file and directory permissions.

Full information here:
https://michaeldaw.org/projects/wp-securify/

This tool was inspired by Kafkaesqui’s comments.

“This tool was inspired by Kafkaesqui’s comments.“

:) – I appreciate that.

Your work looks interesting.

Your audience will be limited with a shell script, but anyone really serious about protecting their site should have at least the basic knowledge for working at the command line (and be provided with a shell account from their host – ssh only, of course!).

One thing I should point out is that removing version info can affect some plugins which require the information to function correctly. Perhaps the smarter (though more complicated) step would be to snip $wp_version from any core file echoing or applying it to one of the various user agent values.

Kafkaesqui,

“Your audience will be limited with a shell script..”

It seemed like a good idea during the early hours of the morning ?? Now that I think about it, it may be better to convert it into a PHP project.. I will think on this one.

“removing version info can affect some plugins..”

Is this a popular practise? I assume the main reason for this would be as a validation step to ensure the correct version of WP is running before install? Yes, we can probabally alter the script to remove the version from public PHP scripts. I was looking into this area for a future release anyways so this is not a problem.

“I assume the main reason for this would be as a validation step to ensure the correct version of WP is running before install?“

Possibly in some of the more complex plugins, but it could also be for choosing between SQL queries (for example, the posts table structure has changed over time), or if a function is (or is not) available in the core. Then there are plugins like this one…