Difference between revisions of "Security Checklist/Hosting and Server Setup"

From Joomla! Documentation

< Security Checklist
m (Typo.)
m (change category name)
(27 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{RightTOC}}
+
{{:Security Checklist/TOC}}
 
== Choose a Qualified Hosting Provider ==
 
== Choose a Qualified Hosting Provider ==
  
Line 9: Line 9:
  
 
===Avoid sloppy server configurations===
 
===Avoid sloppy server configurations===
: For a real eye-opener, [http://www.nexen.net/articles/dossier/php_configuration_statitstics.php read this report] on thousands of sites that allowed Google to index the results of phpinfo(). Don't make this mistake on your site! The report includes alarming statistics on the percentage of sites that use depreciated settings such as register_globals ON or that don't have open_basedir set at all: By the way, if ''phpini'' and ''register_globals'' are unfamiliar terms you are probably not ready to securely manage your own site.
+
: For a real eye-opener, [http://www.nexen.net/articles/dossier/php_configuration_statitstics.php read this report] on thousands of sites that allowed Google to index the results of phpinfo(). Don't make this mistake on your site! The report includes alarming statistics on the percentage of sites that use deprecated settings such as register_globals ON or that don't have open_basedir set at all: By the way, if ''phpini'' and ''register_globals'' are unfamiliar terms you are probably not ready to securely manage your own site.
  
 
==Configuring Apache==
 
==Configuring Apache==
Line 20: Line 20:
  
 
: Consider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.) </li>
 
: Consider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.) </li>
 +
 +
 +
=== PHP Being Run as an Apache Module. ===
 +
 +
This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.
 +
 +
The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page
 +
 +
[[Where can you learn more about file permissions?]]
 +
 +
Specific topics to read would be the following two:
 +
 +
[[How do UNIX file permissions work?|Unix Permissions Primer]]
 +
 +
and for information on phpSuExec and similar implementations:
 +
 +
[[Using phpSuExec]]
  
 
===Use Apache mod_security===
 
===Use Apache mod_security===
Line 35: Line 52:
  
 
===Use PHP5===
 
===Use PHP5===
: Currently, both PHP4 and PHP5 are maintained, and both are often available on servers. Before PHP4 becomes obsolete, upgrade your custom scripts to PHP5. Don't worry about core Joomla code; all current versions are PHP5 compatible. (See [http://www.php.net/ PHP News])
+
PHP 4 is deprecated and has become obsolete. Some hosting providers still have both available on servers to support outdated scripts. Joomla requires PHP5. (See [http://www.joomla.org/technical-requirements.html/ Joomla Requirements])
  
 
===Use local php.ini files===
 
===Use local php.ini files===
Line 43: Line 60:
  
 
# Local ''php.ini'' files '''''only''''' have an effect if your server is configured to use them. This includes a ''php.ini'' file in your ''http_root'' directory. You can test whether or not these file affect your site by setting an obvious directive in the local ''php.ini'' file to see if it affects your site.
 
# Local ''php.ini'' files '''''only''''' have an effect if your server is configured to use them. This includes a ''php.ini'' file in your ''http_root'' directory. You can test whether or not these file affect your site by setting an obvious directive in the local ''php.ini'' file to see if it affects your site.
# Local ''php.ini'' files only effect ''.php'' files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a ''php.ini'' file. They are your ''http_root''(your actual directory name may vary), which is where Joomla's Front-end ''index.php'' file is located, and the Joomla! ''administrator'' directory, which is where the Back-end administrator ''index.php'' file is located. Other directories that don't have files called via the Web do not need local ''php.ini'' files.
+
# Local ''php.ini'' files only affect ''.php'' files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a ''php.ini'' file. They are your ''http_root''(your actual directory name may vary), which is where Joomla's Front-end ''index.php'' file is located, and the Joomla! ''administrator'' directory, which is where the Back-end administrator ''index.php'' file is located. Other directories that don't have files called via the Web do not need local ''php.ini'' files.
 
# If you have a ''php.ini'' file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the ''php.ini'' files in ''http_root'' and the ''administrator'' directories.
 
# If you have a ''php.ini'' file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the ''php.ini'' files in ''http_root'' and the ''administrator'' directories.
  
Line 51: Line 68:
 
       disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
 
       disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
  
===Use PHP open_basedir===
+
===Consider Using PHP open_basedir===
: ''open_basedir'' should be enabled and correctly configured. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.  
+
: You ''might'' consider enabling ''open_basedir''. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.  
  
 
: The restriction specified with open_basedir is a prefix, not a directory name. This means that ''open_basedir = /dir/incl'' allows access to ''/dir/include'' and ''/dir/incls'' if they exist. To restrict access to only the specified directory, end with a slash. For more information, see [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode PHP Security and Safe Mode Configuration Directives].
 
: The restriction specified with open_basedir is a prefix, not a directory name. This means that ''open_basedir = /dir/incl'' allows access to ''/dir/include'' and ''/dir/incls'' if they exist. To restrict access to only the specified directory, end with a slash. For more information, see [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode PHP Security and Safe Mode Configuration Directives].
  
 
     open_basedir = /home/users/you/public_html
 
     open_basedir = /home/users/you/public_html
 
: In some system configurations, at least with PHP 4.4.8, the use of the trailing slash to restrict the access to only the specified directory may cause Joomla to warn ''JFolder::create: Infinite loop detected'' when saving the Back-End Global Configuration. This warning is triggered because PHP ''file_exists()'' function fails, for example, when asked if ''/home/user/public_html/joomla_demo'' exists and ''open_basedir'' is set to ''/home/user/public_html/joomla_demo/'' (see the trailing slash).
 
  
 
: Additionally, if ''open_basedir'' is set it may be necessary to set PHP ''upload_tmp_dir'' configuration directive to a path that falls within the scope of ''open_basedir'' or, alternatively, add the ''upload_tmp_dir'' path to ''open_basedir'' using the appropriate path separator for the host system.
 
: Additionally, if ''open_basedir'' is set it may be necessary to set PHP ''upload_tmp_dir'' configuration directive to a path that falls within the scope of ''open_basedir'' or, alternatively, add the ''upload_tmp_dir'' path to ''open_basedir'' using the appropriate path separator for the host system.
Line 67: Line 82:
  
 
===Adjust magic_quotes_gpc===
 
===Adjust magic_quotes_gpc===
 +
: ''' <small>''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0''</small>'''
 +
 
: Adjust the ''magic_quotes_gpc'' directive as needed for your site. The recommended setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions. The safest method is to turn ''magic_quotes_gpc'' off and avoid all poorly-written extensions, period.  
 
: Adjust the ''magic_quotes_gpc'' directive as needed for your site. The recommended setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions. The safest method is to turn ''magic_quotes_gpc'' off and avoid all poorly-written extensions, period.  
  
 
: Joomla! 1.5 ignores this setting and works fine either way.  
 
: Joomla! 1.5 ignores this setting and works fine either way.  
 
For more information, see either [http://docs.joomla.org/Magic_quotes_and_security Magic quotes and security] or  
 
For more information, see either [http://docs.joomla.org/Magic_quotes_and_security Magic quotes and security] or  
[http://us3.php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].
+
[http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].
  
 
       magic_quotes_gpc = 1
 
       magic_quotes_gpc = 1
  
 
===Don't use PHP safe_mode===
 
===Don't use PHP safe_mode===
: Avoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper problem and provides a false sense of security. See the official PHP site for an explanation of this issue.
+
: ''' <small>''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0''</small>'''
 +
 
 +
: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper problem and provides a false sense of security. See the official PHP site for an explanation of this issue. http://php.net/manual/en/features.safe-mode.php
  
 
       safe_mode = 0
 
       safe_mode = 0
  
 
===Don't use PHP register_globals===
 
===Don't use PHP register_globals===
: Automatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have depreciated this 'feature'.  
+
: ''' <small>''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0''</small>'''
 +
 
 +
: Automatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have deprecated this 'feature'.  
  
 
: If your site is on a shared server with a hosting provider that insists ''register_globals'' must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server. For more information, see [http://www.zend.com/manual/security.globals.php ZEND Chapter 29. Using Register Globals].
 
: If your site is on a shared server with a hosting provider that insists ''register_globals'' must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server. For more information, see [http://www.zend.com/manual/security.globals.php ZEND Chapter 29. Using Register Globals].
Line 92: Line 113:
  
 
       allow_url_fopen = 0
 
       allow_url_fopen = 0
 +
 +
==File permissions==
 +
If a joomla installation is hosted on apache with mod_php, then all virtual hosts on that server run in the same context as your joomla code.  If the files are owned by some other user than 'nobody' or 'wwwrun', the safest permissions are those which '''prevent''' changes to the joomla code, unless via an authorised channel (e.g. FTP):
 +
*DocumentRoot directory: 750 (e.g. public_html)
 +
*Files: 644
 +
*Directories: 755 (711 if you are paranoid, but not for directories which need to be listed) (owner: some user)
 +
 +
With these permissions set, you will need to use FTP to update your Joomla installation.  Not all modules support this.  Remove modules which do not support FTP upgrades.
 +
Other processes running under mod_php can read '''your''' configuration.php.  You can frustrate automated hacks by renaming this file.  You should not store your FTP password in your configuration file on such hosts, as your account ''will'' be compromised.
 +
 +
If a joomla installation is hosted on apache with fast-cgi, suphp or cgi that runs as a different user, then you should set your permissions as follows:
 +
* DocumentRoot directory: 750 (e.g. public_html)
 +
* PHP files: 600 (400 if you are truly paranoid)
 +
* HTML and image files: 644 (444 if you are truly paranoid)
 +
* Directories: 755 (711 if you are paranoid, but not for directories which need to be listed)
  
 
==Setup a backup and recovery process==
 
==Setup a backup and recovery process==
Line 102: Line 138:
 
# Authoritarian government intervention. (More common than some think.)
 
# Authoritarian government intervention. (More common than some think.)
 
# Needing to quickly relocate to a new server or hosting provider.
 
# Needing to quickly relocate to a new server or hosting provider.
 
 
== Choose A Checklist==
 
# [[Security Checklist 1 - Getting Started|Getting Started]]
 
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
 
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
 
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
 
# [[Security Checklist 5 - Site Administration|Site Administration]]
 
# [[Security Checklist 6 - Site Recovery|Site Recovery]]
 
 
== Edited by==
 
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]
 
 
  
 
<!-- KEEP THIS AT THE END OF THE PAGE -->
 
<!-- KEEP THIS AT THE END OF THE PAGE -->
 
[[Category:Security Checklist]]
 
[[Category:Security Checklist]]
 +
[[Category:Server configurations]][[Category:Server setup hosted]]

Revision as of 17:22, 18 October 2012

Choose a Qualified Hosting Provider[edit]

The most important decision[edit]

Probably no decision is more critical to site security than the choice of hosts and servers. However, due to the wide variety of hosting options and configurations, it's not possible to provide a complete list for all situations. Check this unbiased list of recommended hostswho fully meet the security requirements of a typical Joomla site. (FAQ)

Shared server risks[edit]

If you are on a tight budget and your site does not process highly confidential data, you can probably get by with a shared server, but you must understand the unavoidable risks. Most of the tips listed below are appropriate for securing sites on shared server environments.

Avoid sloppy server configurations[edit]

For a real eye-opener, read this report on thousands of sites that allowed Google to index the results of phpinfo(). Don't make this mistake on your site! The report includes alarming statistics on the percentage of sites that use deprecated settings such as register_globals ON or that don't have open_basedir set at all: By the way, if phpini and register_globals are unfamiliar terms you are probably not ready to securely manage your own site.

Configuring Apache[edit]

Use Apache .htaccess[edit]

See also .htaccess examples

Block typical exploit attempts with local Apache .htaccess files. This option is not enabled on all servers. Check with your host if you run into problems. Using .htaccess, you can password protect sensitive directories, such as administrator, restrict access to sensitive directories by IP Address, and depending on your server's configuration, you may be able to increase security by switching from PHP4 to PHP5.
Joomla ships with a preconfigured .htaccess file, but *you* need to choose to use it. The file is called htaccess.txt. To use it, rename it to .htaccess and place it in the root of your site using FTP. One important point to note is that as the distributed file is called htaccess.txt and the live file on your site is called .htaccess, the file your site actually uses is NOT updated when you update your site to use to a new version of Joomla. You must manually make the changes to use the new file version. There are significant changes in the file distributed with 1.5.23 onwards and 1.6.2 onwards.
Consider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)


PHP Being Run as an Apache Module.[edit]

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

Where can you learn more about file permissions?

Specific topics to read would be the following two:

Unix Permissions Primer

and for information on phpSuExec and similar implementations:

Using phpSuExec

Use Apache mod_security[edit]

Configure Apache mod_security and mod_rewrite filters to block PHP attacks. See Google search for mod_security and Google search for mod_rewrite. (Note: These are advanced methods that usually require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)

Configuring MySQL[edit]

Secure the database[edit]

Be sure MySQL accounts are set with limited access. The initial install of MySQL is insecure and careful configuration is required. (See the MySQL Manuals) Note: This item applies only to those administering their own servers, such as dedicated servers. Users of shared servers are dependent on their hosting provider to set proper database security.)

Configuring PHP[edit]

Understand how PHP works[edit]

Understand how to work with the php.ini file, and how PHP configurations are controlled. Study the Official List of php.ini Directives at http://www.php.net, and the well-documented default php.ini file included with every PHP install. Here is the latest default php.ini file on the official PHP site.

Use PHP5[edit]

PHP 4 is deprecated and has become obsolete. Some hosting providers still have both available on servers to support outdated scripts. Joomla requires PHP5. (See Joomla Requirements)

Use local php.ini files[edit]

On shared servers you can't edit the main php.ini file, but you may be able to add custom, local php.ini files. If so, you'll need to copy the php.ini files to every sub-directory that requires custom settings. Luckily a set of scripts at B & T Scripts and Tips can do the hard work for you.
There are a few important things to keep in mind.
  1. Local php.ini files only have an effect if your server is configured to use them. This includes a php.ini file in your http_root directory. You can test whether or not these file affect your site by setting an obvious directive in the local php.ini file to see if it affects your site.
  2. Local php.ini files only affect .php files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a php.ini file. They are your http_root(your actual directory name may vary), which is where Joomla's Front-end index.php file is located, and the Joomla! administrator directory, which is where the Back-end administrator index.php file is located. Other directories that don't have files called via the Web do not need local php.ini files.
  3. If you have a php.ini file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the php.ini files in http_root and the administrator directories.

Use PHP disable_functions[edit]

Use disable_functions to disable dangerous PHP functions that are not needed by your site. Here is a typical setup for a Joomla! site:
     disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

Consider Using PHP open_basedir[edit]

You might consider enabling open_basedir. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.
The restriction specified with open_basedir is a prefix, not a directory name. This means that open_basedir = /dir/incl allows access to /dir/include and /dir/incls if they exist. To restrict access to only the specified directory, end with a slash. For more information, see PHP Security and Safe Mode Configuration Directives.
    open_basedir = /home/users/you/public_html
Additionally, if open_basedir is set it may be necessary to set PHP upload_tmp_dir configuration directive to a path that falls within the scope of open_basedir or, alternatively, add the upload_tmp_dir path to open_basedir using the appropriate path separator for the host system.
    open_basedir = /home/users/you/public_html:/tmp
PHP will use the system's temporary directory when upload_tmp_dir is not set or when it is set but the directory does not exist, therefore it may be necessary to add it to open_basedir as above to avoid uploading errors within Joomla.

Adjust magic_quotes_gpc[edit]

This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0
Adjust the magic_quotes_gpc directive as needed for your site. The recommended setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions, period.
Joomla! 1.5 ignores this setting and works fine either way.

For more information, see either Magic quotes and security or PHP Manual, Chapter 31. Magic Quotes.

     magic_quotes_gpc = 1

Don't use PHP safe_mode[edit]

This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0
Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper problem and provides a false sense of security. See the official PHP site for an explanation of this issue. http://php.net/manual/en/features.safe-mode.php
     safe_mode = 0

Don't use PHP register_globals[edit]

This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0
Automatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have deprecated this 'feature'.
If your site is on a shared server with a hosting provider that insists register_globals must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server. For more information, see ZEND Chapter 29. Using Register Globals.
     register_globals = 0

Don't use PHP allow_url_fopen[edit]

Don't use PHP allow_url_fopen. This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers. Note: This can only be set in php.ini due to security reasons.
     allow_url_fopen = 0

File permissions[edit]

If a joomla installation is hosted on apache with mod_php, then all virtual hosts on that server run in the same context as your joomla code. If the files are owned by some other user than 'nobody' or 'wwwrun', the safest permissions are those which prevent changes to the joomla code, unless via an authorised channel (e.g. FTP):

  • DocumentRoot directory: 750 (e.g. public_html)
  • Files: 644
  • Directories: 755 (711 if you are paranoid, but not for directories which need to be listed) (owner: some user)

With these permissions set, you will need to use FTP to update your Joomla installation. Not all modules support this. Remove modules which do not support FTP upgrades. Other processes running under mod_php can read your configuration.php. You can frustrate automated hacks by renaming this file. You should not store your FTP password in your configuration file on such hosts, as your account will be compromised.

If a joomla installation is hosted on apache with fast-cgi, suphp or cgi that runs as a different user, then you should set your permissions as follows:

  • DocumentRoot directory: 750 (e.g. public_html)
  • PHP files: 600 (400 if you are truly paranoid)
  • HTML and image files: 644 (444 if you are truly paranoid)
  • Directories: 755 (711 if you are paranoid, but not for directories which need to be listed)

Setup a backup and recovery process[edit]

The most important rule:'[edit]

Thou shalt at all time be able to return your site to a previous working state through regular use of a strong, off-site backup and recovery process. Be sure your backup and recovery process is in place and tested BEFORE you go live. This is the single best way (and often the only way) to recover from such inevitable catastrophes as:
  1. A compromised/cracked site.
  2. Broken site due to a faulty upgrade.
  3. Hardware failure, such as dead hard drives, power failures, server theft, etc.
  4. Authoritarian government intervention. (More common than some think.)
  5. Needing to quickly relocate to a new server or hosting provider.