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 namedjohn
, your directories and files should all be owned byjohn:apache
orjohn:www-data
, NOTapache:apache
norwww-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 thewp-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 toapache:apache
.
- The only exceptions are the
- 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
|
|
Take ownership of everything in that directory (substituting your own username for john
and, if you’re on Ubuntu, www-data
for apache
):
1
|
|
Find all directories in this directory and set their permissions to 755
:
1
|
|
Do it again, but for files and 644
:
1
|
|
Give the uploads
folder back to apache
(or www-data
):
1
|
|
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
|
|
Finally, if it’s a Multisite install, give the blogs.dir
directory back as well:
1
|
|
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.)