blog.johnpray

an annotated brainlog

WordPress Security: Quickly Set the Proper File and Folder Permissions

| Comments

Having your web site hacked isn’t fun. Having your employer’s eleven (11!) separate WordPress installations simultaneously hacked, causing their entire website to be placed on Google’s malware warning list (resulting in some great visitor deterrance by Chrome, Firefox, and Google Search results), and learning about it early on a Sunday morning is just about as not-fun as it comes.

This happened to me. Let’s try to keep it from happening to you.

The folder and file permissions on the eleven WordPress installations I inherited at this job were not properly locked down. Here’s some of what I learned that Sunday (and for the week afterwards):

  • All files and directories in a WordPress installation should be owned by a user other than the web server (apache on CentOS, www-data on Ubuntu), though still in the web server’s group. For example, if you have a secure user named john, your directories and files should all be owned by john:apache or john:www-data, NOT apache:apache nor www-data:www-data.
    • The only exceptions are the wp-content/uploads/ folder on all installations, which the server needs access to so your authors can post images and other day-to-day files, and the wp-content/blogs.dir folder on Multisite installations, which the server needs access to to create and manage the various sub-sites. They should both still belong to apache:apache.
  • All directories (or folders) in the installation should have permissions of 755, which allows all server users to read and execute just the folder, while the owner (john, in this case) can write to it (though not necessarily the files inside).
  • All files in the installation should have permissions of 644, which provides read permissions to all server users, write permissions to the owner, and execute permission to no one. (I feel that I should mention that “users” in this case refers to accounts on the server’s very-back-end, in Linux – not to site visitors or WordPress users.)

Long story short, 755 for directories and 644 for files means that even if a hacker manages to somehow get a malicious script file onto your site, she/he/it isn’t going to be allowed to execute it. These are the best-practice permissions recommended by those who know WordPress best.

Since I had to make these changes efficiently and reliably over eleven different WordPress installations, I put together a handy list of commands for quick copy-paste action. Here they are for your WordPress-securing pleasure. They should work on a typical LAMP stack, but your mileage may vary. (I shouldn’t have to tell you to always have backups handy.)

On the command line for your server (via ssh, telnet, cyborg telepathy, or however you prefer to do these things), navigate to the directory containing your WordPress installation. This could be the root directory of your web site, or a subdirectory. For example:

1
cd /var/www/html/wordpress/

Take ownership of everything in that directory (substituting your own username for john and, if you’re on Ubuntu, www-data for apache):

1
sudo chown -R john:apache ./*

Find all directories in this directory and set their permissions to 755:

1
sudo find . -type d -exec chmod 755 {} \;

Do it again, but for files and 644:

1
sudo find . -type f -exec chmod 644 {} \;

Give the uploads folder back to apache (or www-data):

1
sudo chown -R apache:apache ./wp-content/uploads

In my case, I also needed to give existing folders starting with backup- back to apache as well, as that’s where our backup plugin placed its database backups:

1
sudo chown -R apache:apache ./wp-content/backup-*

Finally, if it’s a Multisite install, give the blogs.dir directory back as well:

1
sudo chown -R apache:apache ./wp-content/blogs.dir

That should do it. No guarantees that you’ll never be hacked again, but it should certainly be less likely.

Oh, and if you find yourself in a situation with eleven separate WordPress installations to maintain, do yourself a favor and turn them into a single Multisite installation.


If you need someone to build, maintain, or fix a WordPress site for you, I’m getting into freelancing to share my moderate skills with the world. Drop me a line or check out my StackOverflow Careers profile. (I also do Ruby on Rails. See my recent project, the Science Game Center, built from scratch in Rails by my own ten fingers.)

Comments