threeeighthsspacer.com

(To cut to the meat of the matter, scroll to “STEPS I DID”) Security is a matter of trust, and access to my stuff is granted on a need-to-know basis, and (you) don’t need to know. ;) It makes perfect sense. You see, if you can’t see my files, I’m more inclined to trust you to leave them alone. And we can be friends.
Consider, for example, the case of me running Wordpress on a shared server. It’s frequently recommended that after installing and setting up Wordpress we change the permissions on wp-config.php to 600. Why? With permissions of 644 It would be readable by other user accounts on a shared server. Since wp-config contains sensitive database information that would be an insecure situation. Of course, one could always change permissions and then change them back if and when one needs to edit the file.
I’m going to digress a bit for some background on file permissions in Linux/BSD/Unix. Permissions can be symbolic , like drwxr-xr-x or octal, like 755. By the way, the “d” in the front of drwxr-xr-x tells us it’s a directory (folder). If it were a file, it would be a “-”.
Here’s a table I made to help me remember :

To see information about the files in the current directory, including permissions, type

ls -la

The Wikipedia entry has a more complete explanation.
Setting permissions on all folders to 755 and on all files to 644 is emphatically recommended by many Wordpress blog owners. Contrarily, the Wordpress Codex says to make all the files in your wp-content directory writable by using the following two steps:

1. Go to your WordPress main directory, with a command like cd wordpress/
2. Enter chmod -R 777 wp-content

The Codex also says if you use Permalinks you should change permissions of .htaccess to make sure that WordPress can update it when you change settings or add some new Page (which requires update of the file to work when Permalinks are enabled).

1. Go to the main directory of WordPress
2. Enter chmod 666 .htaccess

I’m not doing that yet, though. I read that with a modern setup where the server (Apache, etc) runs as the user (setuid user) you can keep your wp-content directory 755. Also I read that you should simply set .htaccess temporarily to 666 while WP updates it when you change settings or create a Page.

STEPS I DID to my blog to tighten up the ol’ security belt
First, make sure I (the user) own everything in the blog directory.
cd to your blog directory (or your web root if you like)

cd my/blog

and issue the following command to find files not owned by you (please replace the word “me” with your username):

find . ! -user me

Maybe do

sudo chown -R me .

If you are hosted on Textdrive, and you find a file called .textdrive in your web root, don’t worry. It’s put there on purpose by admins to annoy you so ignore it. (Not really, but it’s leaverite. And you probably can’t change it anyway.)

So now to find all directories (folders) under the current folder and set their permissions to 755

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

The following command is modified from the command recommended in the Wordpress Codex here. Note that that document indicates cryptically that

You have to omit to use this command for /wp-includes/.

However, I wonder whether they meant to refer to /wp-content/, which is the folder mentioned elsewhere as being the only folder needing different permissions, those being 777 ! World-writeable?!
It seems that some or most of the files in /wp-includes have read-only permissions, 444 or -r–r–r– !
I felt that it couldn’t hurt to leave the permissions as strict as possible, while I wanted to change the permissions recursively, and not have to issue a bunch of separate commands I administer several blogs, and I’m going to have to duplicate this a few times. I did a little research:

man find

And I decided to find all files (not directories) under the current directory that are writeable by either the group or the world (other) or both and change their permission mode to 644. This will include the wp-includes directory but will leave more restricted permissions alone, instead of arbitrarily changing every file’s permissions (Please take note that this is the proper command for FreeBSD and probably will but might not be exactly right for Linux; please research for yourself) :

find . -type f -perm +066 -exec chmod 644 '{}' \;

After Wordpress is set up and running properly, and before it is attacked by someone who owns an account on your shared server,

chmod 600 wp-config.php

May 26, 2008 — Until I “fixed” this problem, on this Wordpress 2.5.1 blog hosted on textdrive, If I typed “FTP” and “server” in the main text field of the “New Post” page, and then published or saved my post, I got “Precondition Failed”

Try this on your wordpress blog.
Make a new post.
Type anything in the title field.
Type the words
“FTP” and “server” in the main text field you can type any other content too, but put those two words together and you will not be able to save your post. (edit: It appears that the only word that I really had trouble was “FTP ” - with the space after and without the quotes. I have heard of people having problems with words commonly found in porn spam and also some seemingly-innoccuous words such as “picture”)
Try to publish your test post.
Do you get the “Precondition Failed” error?

Precondition Failed

The precondition on the request for the URL /blog/wp-admin/post.php evaluated to false.

Update - I think it’s mod_security that causes that message. See
this Wordpress Support Page
Also see this Joyent help page
I tried creating a .htaccess file in my public_html directory using the rules suggested there. According to that, you can disable MOD_SECURITY with the following in your .htaccess file:
SecFilterEngine Off
This made it so that at one point I was able to post the word “FTP” alone in a post, which was impossible before. However, I didn’t want to completely disable MOD_SECURITY if I didn’t have to, so,
I tried this in my .htaccess instead, as Joyent suggested at the url above:

SecFilterEngine On
SecFilterSelective "REQUEST_URI" "/blog/wp-admin/post.php" "allow,nolog"
SecFilterSelective "POST_PAYLOAD" "FTP ,FTP,SSH ,SSH" "allow,nolog"

(Note that the above code consists of three lines, and the lines begin with SecFilt…. I will have to make a few adjustments to the theme CSS to make my blog wider . . .)
And that one worked! I don’t think I need the post.php entry so I may remove that line. Anyway it worked.
I am told that MOD_SECURITY is used for spam filtering, and there are many recommendations to disable mod_security as a workaround for this type of problem. However I don’t know. I am rather experimenting here. I’m glad I didn’t have to completely disable it.
I’m tempted to think that overall rules (on my server) are too strict or need tweaking. Or that I need to make a custom filter of my own. However, one would think that one could blog the word “FTP” server without having to rewrite apache rules. When the 3rd and 5th blog posts I made failed, I started thinking “What’s the use? I got me a blog that I can’t post on!”
So here are some suggestions for some rules to put in your .htaccess file so that MOD_SECURITY will be generally functional, and allow apache to allow posts about FTP SSH, etc…
Status: MOD_SECURITY enabled. Blog works. All good.
To implement this solution on your own blog, edit (or create, if it doesn’t exist) a file called .htaccess in the web root of your blog and add the above code to it. .htaccess files define per-directory rules for the apache web server. The .htaccess file which I added to fix my blog is in the folder which contains my Wordpress folder. I think that if you put the file in your actual blog folder it will work as well.