CS & IT Solutions

This is basically notes I am taking while learning in the school of hard knocks based on an article I posted 2008-July-31. To cut to the meat of the matter, here are the notes I took as I learned:

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.

source here

I’ve long been a fan of FreeBSD (although I also use a Mac, Linux, and Windows machine — right tool for the job, and all that), and one of the things I like best about the various BSDs is the ease with which you can set up a stateful packet-filtering firewall. To put it simply, pf rocks.

Setting it up for the first time, though, can be a bit of a chore. If you are interested in giving pf a look, here’s how you do it on FreeBSD.

Recompile your kernel
For the sake of argument, let’s assume that we are going to be setting up a machine called “zeus” as a gateway server with a few simple services running on it. We first need to compile the pf stuff into the kernel, and then install our new kernel. First, get to the right directory:

[tcs@zeus] ~> su -
Password:
1:28PM up 60 days, 3:54, 1 user, load averages: 0.03, 0.01, 0.00
[root@zeus] ~# cd /usr/src/sys/i386/conf/

Now, copy the file GENERIC to some new file (I’m calling my zeus):

[root@zeus] ~# cp GENERIC ZEUS

Edit the file ZEUS and add the following lines just below “options ADAPTIVE_GIANT”: Read the rest of this entry »