In the blog directory;
Type the following to see folders in and under this directory that are writeable by group and/or others:
find . -type d -perm +022 -ls
Do the following to take away write permissions from group and others on those same folders:
find . -type d -perm +022 -exec chmod go-w '{}' \;
Type the following to see files in and under this directory that are writeable by group and/or others:
find . -type f -perm +033 -ls
Do the following to take away write permissions from group and others on those same files:
find . -type f -perm +033 -exec chmod go-wx '{}' \;
And then, test to see if your server can run wordpress with the wp-config.php file invisible. It is obviously more secure to do this, since this file contains your database passwords in plain text! To do this:
chmod 600 wp-config.php
or, instead, just:
chmod go-rwx wp-config.php
to make your config file unwriteable and unreadable by others and also by group. The former sets all perms explicitly; the latter merely takes away read, write, and execute from the group and other. These measures work great for me on my linux shared server but the resulting permissions on wp-config.php may be too tight for some servers which are set up another way. My joyent server has something called php-suexec where Apache can run as my user or something like that.  If upon setting the permissions for wp-config.php to 600, you get an error about permissions in ‘wp-load.php on line 27″, or something like that, you may need to leave the wp-config.php readable by group and others, so just
chmod 644 wp-config.php

Edit: I have discovered that to coax the upload feature to function on a certain Linux configuration, where Apache apparently does not run as the user account (no suexec), the uploads folder inside wp-content must be writeable by the group and by everyone! That is unless it’s possible to make the apache user be in the same group as me or something. Anyway apparently according to the Wordpress codex, it was designed to work that way. On a different server where apache runs the suexec module so it can run as the user (me) I can still keep my uploads folder 755. Not in this configuration. So far it must be 777 for that folder only.  Unless there is a way for me and the web server to share group permissions somehow . . .
And read on for my whole rant on the subject, including my first attempts down below—–

Security is a matter of trust, and access should be granted on a need-to-know basis, and (you) don’t need to know. ;) loi
Consider, for example, the case of 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 this if you can:

sudo chown -R me .

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

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

I’m following along with what’s 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 think it’s a typo and 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 removing write permissions for group and for other. 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

—EDIT 2009-01-06

I have now done this in a linux box and it seems like it’s different.

I think on Linux the find option, or test, “-perm +mode” might behave differently than on BSD. I’ll report back later but these are the ones that worked on Linux:

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

The above means find in this directory files of type file (not a dir, etc) that are either group or others writeable, (I think) and change their permissions to 644. 644 is how you want most, if not all regular files’ permissions set.
Directories (folders) to be accessed publicly you want to be 755 generally. That means rwx for owner and rx for others and group.

find . -type d -perm +022 -exec chmod 755 '{}' ;

also use for instance to test the result:

find . -type d -perm +022 -exec ls -la '{}' ;

The above lists the contents of the dirs found as well as the dirs.
You can use this to list files found – simpler:

find . -type d -perm +022 -ls

For more information, please type “man find” in the terminal.

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.