Documentation Wiki

Improving the security of your PostNuke web

(Applicable to PostNuke 0.76x and earlier, and 0.8x)

PostNuke is supplied with an installation script that usually succeeds in installing PostNuke in most hosting set-ups. However, there are some steps you probably can take to make your site more secure, and you certainly should do this if possible. A summary of these steps is as follows:

• PostNuke's installation script places a directory called 'pnTemp' in the root directory of your PostNuke web. If possible, you are strongly recommended to move this 'pnTemp' directory to a directory that is outside your web root (*not in your public_html, or www directory), and then use an edited 'config.php' file that points to the location of a 'personal_config.php' file that is outside the world-browsable web root.

• If you're using PostNuke 0.76x or earlier, you can delete the file called 'config-old.php' in the root directory of your PostNuke web.

• If possible, you should change certain PHP settings to values that provide better security. 'register_globals' should be set to OFF. If you can't do it, then you could ask your hosting provider or system administrator to do so.

Ideally, make sure that your browsable web space does not contain any directories and files that can be written to. All files should have their permissions set to 644 or 444, and all directories should have their permissions set to 755.

You may have reasons for wanting to have writable directories, etc., but that goes beyond the scope of these instructions.

If you want to install other PostNuke modules or other software that require a directory in which to write data, it is generally possible to set them up so that their writable directories are outside the web root. In this case you should definitely do so. Writable directories can give malevolent hackers a means of defacing your web site or of taking control of your web server.

Generally, it is wise to always install the latest version of PostNuke modules and other software, because they are likely to be the most secure. Similarly, it is wisest to always use the most recent stable version of PostNuke for your web (development versions are not guaranteed to be either secure or stable, and you may not receive the same technical support as you would with a stable version).

Where should you install your PostNuke web? Should you install it in the web root of your web space? Or should you opt to install in a subdirectory below the web root, and then either have a top layer of HTML pages linking to your PostNuke web, or server redirection that redirects requests for the top index page of your site (index.php, index.html, or whatever) to the index page of your PostNuke web?

It's a moot point. Search engines don't always like to encounter redirection from the top index page, and some may even refuse to list such a site, so SEO considerations might make you choose the web root for installation. However, installing it in a subdirectory below your web root enables you to deny access to your PostNuke web by applying password protection via your '.htaccess' file, as an additional protection to PostNuke's own site disablement feature, if security considerations so demand.

Probably, most people opt to install in the web root, and most don't encounter any problem. It's your choice.

Detailed instructions about how to do secure a PostNuke web are given below.

For the purpose of these instructions, here are explanations of some terms we'll be using:

'Web root': this is the top directory in the directory structure that is accessible to web surfers. Frequently, it is where people install their PostNuke webs, but some people install their PostNuke in a subdirectory below the web root.

'PostNuke root directory': this is the top directory of your PostNuke web, i.e. the directory containing PostNuke files such as 'admin.php', 'user.php', 'header.php' and 'footer.php', and directories such as 'system', 'modules' and 'themes'.

'Top directory of your web space': in these instructions, we're assuming that most people are installing their PostNuke web in a hosted web space on a hosting provider's web server. With many hosting packages these days, you have access via FTP, SSH and tools such as cPanel to a directory that is immediately above the web root. This directory is not accessible to web surfers, it is only accessible to you via FTP, SSH and tools such as cPanel. Of course, if you're installing PostNuke on a local web server or other special environment, this will not apply to you.


1. If you're installing PostNuke at this time then, before you start, it's a good idea to make sure that no-one can get access to your web space during the installation process. But even if your site is already installed, it's still a good precaution to apply password protection to prevent access to your PostNuke root directory while you're carrying out the securing instructions below.

cPanel users

In the main page of cPanel, click on 'Password Protect Directories'.

Then click on '/ (Current Folder)'. (Click on the forward slash: 'Current Folder' is not clickable.)

In the next page that displays, put a checkmark in the 'Directory requires a password to access via the web' checkbox, and then create a user by typing a user name in the 'User Name' field and typing a password in the 'Password' field.

Then click on 'Add/modify authorized user'. You should see a new page informing you that you succeeded.

Now click on the 'HOME' icon at the top of the page, to take you back to the cPanel main page.

FTP users

First, we'll create a file called '.htpasswd', which will contain a user name and password for you to be able to have access to the PostNuke root directory that we are going to protect.

Open a text editor and create a new file.

Now you need a user name and an encrypted password. For this, you can go to this web page (this is just one - if you find it's not working, then there are many others; a search engine will find them for you):
http://www.kxs.net/support/htaccess_pw.html∞

Enter a user name of your choice, then enter a password of your choice, and then click the 'Create Password' button. If you enter the user name 'jackhammer' and the password 'spagettiho946?', for instance, then you will obtain this user name/password pair:

Paste it into the file you created in the text editor, and then save the file under the name '.htpasswd'.

Now you need to upload this file to your web server. Open an FTP session with your web server.

It is preferable to put the '.htpasswd' file in the top directory of your web space, i.e. the directory above your web root.

Upload your '.htpasswd' file.

Now look and see if there is already a file called '.htaccess' in the PostNuke root directory. If there is, then download it and open it with a text editor. If there is not, then open a text editor and create a new file. In the file you created or opened, paste this text into it right at the top (if you're editing an existing '.htaccess' file, then don't overwrite the existing contents, just paste into the top of the file):

You need to replace '/home/yourwebsite/' with the path applicable in your case to the '.htpasswd' file we created above.

Save the file. Upload it to the PostNuke root directory, overwriting the existing '.htaccess' file if there was one there previously.

The directory is now protected, and no-one will be able to have access to it while you're installing PostNuke.


2. Run the PostNuke installation script, and successfully complete the installation of your PostNuke web. Visit the home page of your new web just to make sure it really is working OK. If your web is already up and running, then just go to instruction 3 below.


3. Go to your PostNuke root directory, locate the file called 'config.php', and then open it in a text editor.

In PostNuke 0.76x and earlier, 'config.php' is indeed in your PostNuke root directory. But in PostNuke 0.8x and later, 'config.php' is in a subdirectory called 'config' below your PostNuke root directory.

Save the contents of this file to a temporary file on your local computer. You will need those contents later. Now highlight the entire contents of your 'config.php' file and then paste the code below as a replacement:

In the code above, '/home/yourwebsite/' should be replaced with the path used to refer to the top directory of your web space, which is not accessible from the Internet (it's only accessible to you via FTP or SSH or a tool such as cPanel).

Now save the edited 'config.php' file to its original location in the PostNuke root directory (with PostNuke 0.76x and earlier) or in the 'config' directory under the PostNuke root directory (in the case of PostNuke 0.8x and later).

Next, go to the top directory of your web space. Create a file called 'personal_config.php' in this directory, and paste into it the contents that were previously in your 'config.php' file (which we saved earlier in that temporary file on your local computer). In the case of a PostNuke 0.764 installation, it will resemble the code below (although, obviously, the database user name and password and the path to the temporary directory will be different, as may other items):

You need to edit the line below to match the location of the new 'pnTemp' that you are going to create in the top directory of your web space:

For instance, you might edit '/home/yourwebsite/public_html/' to '/home/yourwebsite/'. In the example I've given here - it's actually in a cPanel environment - the PostNuke web is installed in the root directory of the web space, and that's where the PostNuke installation script originally set-up the 'pnTemp' directory. But now we're going to move the 'pnTemp' directory up one level to the top directory of the web space, so we remove 'public_html' so as to point to the new location.

Note: you are not obliged to call the temporary directory 'pnTemp'. You can give it another name, provided that you specify that other name in your 'personal_config.php' file. For instance, if you're planning to set-up a multisite portal, you will actually require several temporary directories, so you could call them 'pnTemp-mysite1?', 'pnTemp-mysite2?', etc. Similarly, you would need several personal configuration files, too, so you might name them 'config-mysite1?.php', 'config-mysite2?', etc. You only have to make sure that they are correctly referenced in the appropriate 'config.php' files for each web. See elsewhere in the PostNuke documentation for more about multisite set-ups.

All that remains now is to actually set-up the 'pnTemp' directory structure in question, with the correct permissions applied to the directories.

Go to the top directory of your web space. There, create a directory called 'pnTemp' (in the case of the example we're discussing), and set the permissions to 755. At the present time, we still have not deleted the former 'pnTemp' directory that the PostNuke installation script originally created.

If you're using cPanel, the simplest way is to copy the directories inside the original 'pnTemp' directory within the PostNuke web root, and then paste them into the new 'pnTemp' directory you created in the top directory of the web space. The permissions will be preserved and, of course, the contents of the directories will be copied at the same time.

If you're using FTP, you can download the entire contents of the original 'pnTemp' to your local computer and then upload them into the new 'pnTemp'. Under Linux, it works just fine - the permissions will be preserved on all directories and files. But if you do it under Windows then you will have to set the permissions on all directories and files. I'm not sure what the situation is with Mac.

With SSH, of course, you can just change directory to the PostNuke web root, use the gzip command to create an archive containing the 'pnTemp' directory and everything underneath it, copy the said archive to the top directory of your web space, and then unpack it to recreate the 'pnTemp' directory and underlying structure and files.

The contents of the 'pnTemp' folder with a fresh installation of PostNuke 0.764 is as follows:

• 'Xanthia_Config' directory. Permissions set to 777. Contains one blank 'index.html' file with permissions set to 644.

• 'Xanthia_cache' directory. Permissions set to 777. Contains one blank 'index.html' file with permissions set to 644.

• 'Xanthia_compiled' directory. Permissions set to 777. Contains one blank 'index.html' file with permissions set to 644.

• 'adodb' directory. Permissions set to 755. Contains one blank 'index.html' file with permissions set to 644.

• 'error_logs' directory. Permissions set to 755. Contains one blank 'index.html' file with permissions set to 644. If your site has already been operational, this directory can also contain error log files.

• 'pnRender_cache' directory. Permissions set to 777. Contains one blank 'index.html' file with permissions set to 644 and one 'readme.txt' file with permissions set to 644 too. This 'readme.txt' is unnecessary: there's no reason for it to be there, and you might as well delete it. If you're site has already been visited, then this directory will probably contain cached files. You can leave them there or delete them, as you wish. As a precaution, it might be better to delete them.

• 'pnRender_compiled' directory. Permissions set to 777. Contains one blank 'index.html' file with permissions set to 644 and one 'readme.txt' file with permissions set to 644 too. This 'readme.txt' is unnecessary: there's no reason for it to be there, and you might as well delete it. If you're site has already been visited, then this directory will probably contain cached files. You can leave them there or delete them, as you wish. As a precaution, it might be better to delete them.

• 'rss' directory. Permissions set to 755. Contains one blank 'index.html' file with permissions set to 644.

• '.htaccess' file. Permissions set to 644.

• 'index.html' file. Permissions set to 644.

• 'pntemp.xml' file. Permissions set to 644. Serves no purpose, so you can just delete it.

With a complete installation of PostNuke 0.8x, there will also be a directory called 'feeds' (permissions set to 755) that contains one 'index.html' file (permissions 644). If your site has been operational, it can contain temporary RSS feed data. This data can be safely deleted.

If your web has been operational and you copied the old 'pnTemp' directory, anything else you might find within the 'pnTemp' directory should be deleted.

You have now completed the move. Go visit the home page of your web and make sure that everything works -- it should work perfectly.

You should now go and delete the original 'pnTemp' directory.

4. If your PostNuke web is 0.76x or earlier, you should now go to your PostNuke web root directory and delete the file called 'config-old.php' It serves no purpose whatsoever. With PostNuke 0.8x and later, that file no longer exists.

5. PHP offers flexibility in its settings, but some settings reduce the security of your web server. The PostNuke project recommends certain settings for some PHP parameters. 'register_globals' should be set to OFF.

To do this, insert the following line in the '.htaccess' file in the web root of your web space (at the top of the file, for instance):

or

If your web server is Apache 2, you may encounter the following problem, according to one post on http://php.net∞:

"...adding php_flag in .htaccess under apache 2 will cause internal server error. according to apache 2 manual, php_flag should goes to <virtual> or <directory> section."

END OF DOCUMENT - WORK IN PROGRESS