Security and Performance FAQs

This Article Needs Your Help

Getting Started

What is the Joomla! Administrator's Security Checklist?

The Joomla! Administrator's Security Checklist is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums.

What are the top 10 stupidest Joomla! security tricks?

A very good question, and sadly one that many did not ask in time. We proudly present the Top 10 Stupidest Administrator Tricks.

How do I choose a quality hosting provider?

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

• Choose *NIX: Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options. Due to zero licensing fees and lower administrative overhead, such offerings are sometimes less expensive as well.

• Use Secure FTP: Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

• Set PHP register_globals OFF: The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

• Seek PHP flexibility: Choose a host that allows you to use either PHP4 or PHP5.

• Stay up-to-date: Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and scripting languages.

• Avoid cheap shared servers: Be sure users on your shared server can't view each other's files and databases, for example through shell accounts and cpanels.

• Proactive server management: Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

• Require raw log access: Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

• Performance matters: Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

• Data center: Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

• Know your neighbors: Check that your host is not at risk of having its IP addresses blocked because it hosts porn or SMAM sites.

• Consider Recommendations: Check this list of recommended hosts.

• Grow with your site: As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) dedicated servers offer the best possible security and performance, but at the highest expense, 2) virtual servers offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

What are the best practices for site backups?

This Article Needs Your Help

One round of heavy editing completed. More careful word smithing needed...

There are three traditional backup types--full, cumulative and differential.

Full Backups A complete backup of all associated files at a known point in time.

Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

Cumulative Backups This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

Incremental Backups This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly can not be recreated or is too costly to recreate, once a night or more may be more effective.

If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

Data Protection Best Practice says

1. You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
2. A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
3. A good backup practice is to store backups away from the current data location, preferably off site.
4. Dynamic data should be backed up offline or hot to avoid fuzzy backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

Where can I learn about vulnerable extensions?

• See the Vulnerable Extensions List

Where can I learn more about file permissions?

• Unix Permissions Primer
• Windows Permissions Primer
• Using phpSuExec

How do I setup a powerful password scheme?

Overview

Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

Directions

• Level 5 (Public) - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

• Level 4 (Webmaster) - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

• Level 3 (Webmaster) - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

• Level 2 (Personal Data Access) - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

• Level 1 (Banking!) - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

Joomla! Core

How can I check my Joomla! installation's overall security and health?

Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

Project Home: http://joomlacode.org/gf/project/jts/

Why should I immediately change the name of the default admin user?

Overview

All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

Directions

1. Log into the Back End

2. Select User Manager

3. Select the 'admin' user record

4. Change the value in username. (Good user names contain a mix of letters and numbers.)

5. Save

6. Remember the new username!

How do I turn RG_EMULATION off?

Overview

PHP's register_globals option was a bad idea and has been depreciated. Although Joomla's RG_Emulation is safer than PHP register_globals, it's best not to allow any form of automatic variable assignments. Beginning with PHP6, this will not even be an option. Note that poorly-written extensions may fail with register_globals OFF. Best advise: Don't use such extensions!

Joomla! 1.0.13

Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

Joomla! 1.0.12 and earlier

Edit the file, globals.php, found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

to

define('RG_EMULATION',0)

What do Error 1, Error 2, and Error 3 mean?

Error 1 = FATAL ERROR: MySQL not supported...

You need to compile MySQL support into PHP or the MySQL server is down.

Error 2 = FATAL ERROR: Connection to database ...

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in configuration.php, or you are trying to access a database table with the wrong table prefix.

Error 3 = FATAL ERROR: Database not found...

The database cannot be found. Check the database settings in configuration.php

The MySQL variables in configuration.php (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx

$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the $mosConfig_host to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

How do UNIX file permissions work?

This Article Needs Your Help

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

What do Unix permissions look like?

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

Owner (User) relates to username

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

Group relates to usergroup

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

Other relates to everyone else

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

  4+2+1 4+2+1 4+2+1
=   7     7     7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

How Does this Relate to Joomla?

Good question, well in the first instance this would be important during the Web-Installer process. If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term writable is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where write permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not writable.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer. So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the other permissions, may not be required, now you may only need to configure directories to be writable to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x 
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r-- 
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x 
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the configuration.php file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use caching the cache directory will need to be writable by the Web server user to allow it to write its temporary files.

What are the recommended file and directory permissions?

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

How can I avoid using chmod 0777 to enable installs?

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

Directions

1. Edit the Apache user.conf file and tell apache to run under the FTP account.
2. chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

Optional

1. chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
2. chmod the entire web space to 764 or 664 will be possible giving other users write access as well

Isn't locating all Joomla! files inside public_html a security risk?

Short answer

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

Long answer

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessable, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include andrequire. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

The incredible lightness of living outside the fence

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

Joomla! defense

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

The challenge

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you can not forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:

1. First allow all access, then deny any username/password combination that DOES NOT match the approved list.
2. First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

The good news

1. In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
2. Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation. Below is the relevant code from /includes/defines.php.

Defines

define( 'JPATH_ROOT' , implode( DS, $parts ) );

define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

3) Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

How do I move confidential files outside of public_html?

One challenge in Joomla! is ensuring that certain PHP files in public_html containing executable code or confidential data are protected from direct Internet access.

There are various ways to protect such files, but most are not optimal. Many users and developer groups, such as Gallery2 and Apache.org strongly recommend against keeping vulnerable files and confidential data inside public_html.

The following method seems to be the simplest and most elegant way to protect read-only files that, for whatever reason, must be stored in public_html. In this example, we protect configuration.php, perhaps the most confidential file of any Joomla! site.

Note: Using this method, even if the Web server somehow delivers the contents of PHP files, for example due to a misconfiguration, nobody can see the contents of the real configuration file.

Directions

1. Move configuration.php to a safe directory outside of public_html and rename it whatever you want. We use the name joomla.conf in this example.

2. Create a new configuration.php file containing only the following code:

<?php
require( dirname( __FILE__ ) . '/../joomla.conf' );
?>

Important!

Do not include blank lines or any characters (including blank spaces) before the php start tag or after the php end tag. If you make this mistake, you very likely see the following error.

Warning: Cannot modify header information - headers already sent by (output started at  
/home/xxxxx/public_html/configuration.php:2) in /home/xxxxx/public_html/index.php on line 250

3. Make sure the new configuration.php file is not writable, so that it can not be overwritten by the Joomla! Web admin interface.

4. If you need to change configuration settings, do so manually in the relocated joomla.conf.

How do I recursively adjust file and directory permissions?

Using Joomla! Administration

In the Back-end, go to Site --> Global Configuration --> Server.

Using the UNIX shell

Note: The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

Notes:

1. Test all third party extensions after changing permissions.
2. You may need to reset write permissions to install more extensions.

How can I set the administrator directory to use an SSL server (https)?

Use Joomla version 1.5

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are depreciated, and will not work with current Joomla! versions due to increased security enhancements.

More Help

1. Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website

Apache Server

How can I change PHP settings using .htaccess?

Introduction

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

Directions

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

• php_flag register_globals off

• php_flag allow_url_fopen off

• php_flag magic_quotes_gpc on

Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

Recovery

How do I reset an administrator password

Introduction Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

Joomla! 1.0.13 Enhanced Password System Initial tests indicate that the method described here also works with Joomla! 1.0.13 salt-enhanced passwords. This is because Joomla! automatically updates password data from earlier versions to the 1.0.13 format.

Directions

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account.

4. Copy and paste a known MD5 hash, such as one of the samples provided with this FAQ, into the password field. Warning: You must paste the password's hash value, not the password itself. You can use any of the following password = hash pairs, or create your own using one of the tools listed below.

• password = "MD5 hash of password"

---

• admin = 21232f297a57a5a743894a0e4a801fc3
• secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
• OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the record.

6. Point your browser to your site and log as the administrator using your new password.

7. Once logged in, you should change the password again to one that only you know.

Generating your own MD5 hash from a password of your choice

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

Online MD5 hash creation tools

• JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
• MD5er - http://www.md5er.com/

Free MD5 utilities for download

• MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
• SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

Other MD5 tools

• There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"