Securing the installation
From phpCMS
Contents |
[edit] Securing the installation
This part of documentation is concerned with making phpCMS as secure as possible. The developers are always keen to deliver a very secure system.
[edit] Renaming the parser directory (only for Stealth Mode)
Changing the path where phpCMS is installed is only useful when using the Stealth Mode of phpCMS because otherwise the real parser path is shown in the address field of the web browser anyway.
But when using the Stealth Mode this should be the first and is possibly the most important modification of any newly made installation of phpCMS.
By default this path to phpCMS is /parser/. Anyone who has already tried out phpCMS before does know this, so a malevolent person would check this first. Also a path like /cms/ can easily be guessed and is therefore not really secure.
To have a fallback should anything go wrong, it is recommended to take these steps for the modification:
- Copying of the /parser/ directory and all of its contents to a new name (here /newparser is used as an example). One now has these two directories:
- /parser/ (the current phpCMS directory), and
- /newparser/ (the new phpCMS directory).
- The current settings and HTTP-Indexer profiles can easily be transferred to the new parser. To do so, one has to copy the two files default.php and defaults_indexer.php from the directory /parser/include/ into the new directory /newparser/include/.
- Copying of any plug-ins and scripts one is using from the old directory /parser/plugs/ into the new directory /newparser/plugs/.
- All new directories and files have to be given appropriate permissions (to find out more, see the chapter "Set the permissions").
- Editing of the .htaccess file located in the document root directory. In this file one has to enter the new path to the parser.
- Editing of the project files (*.ini) in the template/ directory below the parser directory and adapt the path of the HOME entry to the new parser path,
- Adapting the parser path in any project file (*.ini) in the template/ directory of the project (if existing, e.g. in a PLUGINDIR entry),
- Logging in into the parser graphical interface (Admin-GUI) with one's old password by calling http://domain.com/newparser/parser.php.
- Checking all of the following settings:
- Changing all instances of /parser/ into /newparser/.
- Turning off Stealth Mode for now.
- Now one may check to see whether the new parser correctly processes the pages: Calling http://domain.com/newparser/parser.php?file=/demo/index.htm (or replacing /demo/index.htm with any other page name of the website.
- Once one is satisfied with the tests one can turn on the Stealth Mode again and now one may delete the old /parser/ directory.
But one problem remains:
With the standard installation of phpCMS it is quite easy to find out the path to the parser even in Stealth Mode if one uses mail2crypt. One has just to disable JavaScript in the browser and then call a page with an email address encrypted by mail2crypt. When JavaScript is enabled mail2crypt uses a GIF image with the "@" sign which is loaded from the gif/ directory below the phpCMS directory. So one just has to look where the image is loaded from and one knows where phpCMS is installed.
To prevent this, one should copy the image to the directory where all the other graphic files for the website are stored, e.g. /images/, and then change the path to that image in the "Configuration" in the phpCMS Admin-GUI.
In addition, giving the file parser.php another name would increase security, but not to forget:
also this has to be reflected in the .htaccess file in the web root of the project.
[edit] Disabling directory index
When calling http://YourServer/ParserDirectory/ in a web browser a directory index (i.e. listing of all the files and (sub) directories) of the parser directory is shown by default on many web servers.
This may be a potential vulnerability.
Therefore it is recommended to block this function for the parser directory and every directory below.
In order to do this, one has to create a .htaccess file with the following instruction:
Options -Indexes
If the .htaccess file already exists, one can simply add that instruction.
(only usable if the web server supports .htaccess files.)
[edit] Turning off Debug Mode
When phpCMS is installed for the first time, the debug mode is switched to ON by default. Once everything works fine and the website is going to be published, the debug mode should be switched OFF. This can easily be done in the phpCMS administration GUI.
Why is this important?
If for example one tries to open a non-existent content page, phpCMS shows the complete paths in the file system in order to enable the webmaster to solve the problem. This reveals a part of the directory structure to a potential attacker and this information could be used by him to try an attack exploiting a possible security vulnerability in any installed software on the server (or in phpCMS, should there be one). To make it clear: just revealing a part of the directory structure to an attacker doesn't enable him directly to hack into the server, but it can be a useful information to help him.
More information about this topic can be found in the support forum.
[edit] Protecting critical directories
On web servers that can handle .htaccess files (like Apache), in order to protect directories from access via the browser, one can create a .htaccess file in those directories, but not in directories containing files, which are accessed by the browser directly or indirectly (like JavaScripts or style sheets).
On has to pay attention though, that this affects every (sub-)directory below.
The following directories of the parser directory structure are suitable for this:
- include/,
- stat/,
- cache/,
- session/ and
- temp/.
In recent phpCMS distribution packages, these .htaccess files are already provided.
The directory template/, however, is not suitable, because it contains files the browser loads (e.g. *.css).
Nevertheless, a clever reallocation could secure a part of the directories. For example one can take the *.css file and move it to a new directory which can be accessed by the browser. Then one can also secure your remaining template/ directory in the above mentioned way.
To secure a directory, the .htaccess file needs to look like the following:
Deny from All Order Deny,Allow
This instruction will be inherited by each subdirectory below.
If one wants to unprotect one subdirectory, one can create a further .htaccess file in that subdirectory which should contain the following:
Allow from All Order Allow,Deny
[edit] Relocating critical directories
In order to further improve security one can move other critical directories outside the web root on the server. In the templates directory for example, the passwords for the on-line editing are stored unencrypted in the .ini files.
Moving the templates directory in this way would lead to a directory structure like:
document_root/ document_root/web_root/ <= this where a call of http://domain.com lands document_root/web_root/parser/ *) document_root/templates/
so there is no way one could access a file in the templates directory via the browser.
*) This example shows a 'normal' installation, without applying the other tips in this article.
One only has to pay attention, not to move directories/files outside the web root that are called by the browser, even indirectly like external JavaScripts (.js) files or style sheets (.css).
[edit] Relocating important parser directories
Thanks to 'nzkiwi' from New Zealand for finding this out and sharing it with us in the phpCMS Support Forum!
Most Content Management Systems have fixed paths to their PHP files, which gives a hacker considerable help in breaking in. At least with phpCMS, one can rename the parser directory and even parser.php (see above).
After having followed all the other tips in this article, on could wonder whether there is anything else one can do to maximize security.
There is, but it involves a little bit more work - and: one needs access to the document root of the server and is able to configure it so that the web root is in a directory below the document root, like:
document_root/
document_root/domain/ <= this where a call of http://domain.com lands
( = web root of domain.com )
If one attempts to move all the subdirectories of the parser directory in a 'secure' location, i.e. outside the web root, one will run into a number of problems. At least the /gif/ and /help/ subdirectories must remain in the document path - they contain files that need to be accessed directly by the browser.
Here's how to proceed:
[edit] Installing phpCMS
First, one installs phpCMS as usual and makes sure it is running error free in "Secure Stealth Mode" before attempting the changes outlined below. Then one should follow the instructions in the installation guide to rename the parser directory. In the example below, it is renamed to '/myparser/'.
On the sever of this example, the directory structure is like shown above with the only difference that there are two different domains, and phpCMS was installed on domain1, so the directory structure was:
document_root/ document_root/domain1/ document_root/domain1/myparser/ document_root/domain2/
the parser's URL being http://domain1.com/myparser/parser.php.
For the next steps, one needs to find out the absolute path of the existing parser.php, which can be done using the PHP-Info option of phpCMS' Admin-GUI.
In this example it's assumed to be
/server/local/home/username/domain1/myparser/parser.php
[edit] Creating the new location
Next, one creates two more directories in document root:
document_root/myparser/ document_root/templates/ *)
*) See above for the reason why /templates/ is moved too.
Using the information from the PHP-Info obtained before, it is known that the absolute path to the new myparser/ directory is:
/server/local/home/username/myparser/
One has to make sure to note down the absolute path before taking the next step.
[edit] Moving critical subdirectories of the parser directory
Then one moves the following subdirectories (*) from /domain1/myparser/ to /myparser/ and obtains this structure:
document_root/ document_root/domain1/ document_root/domain1/myparser/ document_root/domain1/myparser/doc/ document_root/domain1/myparser/gif/ document_root/domain1/myparser/help/ document_root/domain1/myparser/temp/ document_root/domain1/myparser/template document_root/domain2/ document_root/myparser/cache/ (*) document_root/myparser/include/ (*) document_root/myparser/plugs/ (*) document_root/myparser/session/ (*) document_root/myparser/stat/ (*) document_root/templates/
To move the directories, on could use the host's Control Panel file manager or a suitable FTP client.
It is important, however, to check whether the permissions on all moved files and folders have not reverted to their default settings. In that case one must make sure they are correctly re-set as per the installation guide.
[edit] Adapting parser files
Note: Before changing anything in files of the parser, it is strongly recommended to make a backup of the original file!
1. Editing the parser
In the parser (/domain1/myparser/parser.php), line 48 is changed from:
define('PHPCMS_INCLUDEPATH', dirname(__FILE__).'/include/');
to
define('PHPCMS_INCLUDEPATH', '/server/local/home/username/myparser/include/');
(This is only an example and one has to adapt the modifications to one's proper situation!)
2. Editing the shell indexer
In the shell indexer (/domain1/myparser/shell_indexer.php), lines 53 and 54 are changed from:
$DOCUMENT_ROOT = dirname(__FILE__).'/..';
define('PHPCMS_INCLUDEPATH', dirname(__FILE__).'/include/');
to
$DOCUMENT_ROOT = '/server/local/home/username/domain1';
define('PHPCMS_INCLUDEPATH', '/server/local/home/username/myparser/include/');
(This is only an example and one has to adapt the modifications to one's proper situation!)
Probably one could have used relative paths, but often it is easier to just use the absolute paths.
[edit] Testing the modifications and further changes
One should now be able to run the Admin-GUI and make the following changes:
- Global Project file: /../templates/default.ini
- Plug-In Directory: /../myparser/plugs
- Server Cache Directory: /../myparser/cache
That was about it!
[edit] Templates directory
The (moved) templates/ directory is here used to store all project files. In that case the content files (.htm(l)) need to include a definition like the following one:
{PROJECT} ./../templates/home.ini
The project file (.ini) for that case looks like this:
; name of the field := value of the field HOME := / TAGS := $home/../template/home.tag PLUGINDIR := $home/../myparser/plugs TEMPLATE := $home/../template/home.tpl MENU := $home/../template/home.mnu MENUTEMPLATE := $home/../template/home.mtpl EDITPASSWORD := Secret
The Admin-GUI including the Spider, File-Indexer and HTTP-Indexer should now all work correctly if one pays attention not to moved the temp/ subdirectory to /myparser/ or the HTTP-Indexer might not work, so one better leaves it in its original location.
Main Page: User Documentation MainPage
« Previous Page: A first test of phpCMS | Top Page: Installation and configuration | Next Page: Upgrade phpCMS »
