Support

I would hardly consider moving the configuration.php file a security measure by any means. Here's why.

Plan A. As an attacker, if I find a direct file inclusion vulnerability on your site, I can always dump the contents of your defines.php and see the new path. Exploiting the same vulnerability I can launch a second attack to dump the contents of the moved file. I have your database passwords.

Plan B. With a rogue upload vulnerability, I would be able to upload a small PHP script to include or scan defines.php, include the configuration.php file and var_dump an instance of it. I have your database passwords.

Plan C. With an arbitrary code execution attack vector (remote file inclusion, arbitrary eval(), etc) I can simply var_dump an instance of JConfig.

Making the point simpler: If Joomla! can read the file, anyone -except a totally stupid attacker- can read it, too.

My advice is to use sane security practices to minimise the possibility of an attack like the one I described. Admin Tools' Web Application Firewall and .htaccess Maker really help towards that goal. Updating your software as soon as a new release is out is also a much needed security practice. Protecting your administrator area with a password or a secret word is very important. Using a strong password (ideally: 14 or more characters with lowercase/uppercase letters, digits and symbols) is of paramount importance, i.e. there's no point moving your configuration.php file if your SA login is admin/admin ;) All and all I find that the myth of adding security by moving the configuration.php is worth of a Mythbusters-style bust.

That said, if you move your configuration.php file, the backup will be made successfully, but the restoration is another story. When you restore your site, the restoration script will write a (now unused) configuration.php file in your site's root. This means that Joomla! will still try to find the moved file. If it does, it will use that file's information which -if different than the file written by the restoration script, at least in the db connection fields- will lead to an error. If it the moved file no longer exists, tough luck, you will still get an error. As a result, after the restoration, you will have to manually create a new configuration.php file inside the location where you chose to move your configuration.php file. This beats the purpose of easy restoration, but is doable.

Dominic,

I would bet an arm and a leg that the attacker never got your database passwords. The easiest, fastest and least intrusive way of gaining access to a site or defacing it is to exploit SQL injection vulnerabilities, i.e. exploit a vulnerable extension to run arbitrary SQL commands against the site's database. If I find a vulnerable extension on your site I can grant myself Super Administrator privileges and log into your site in two minutes flat. It's that fast. You need to ensure that your extensions are not vulnerable. If unsure check the Vulnerable Extensions List. Items in red must be uninstalled ASAP. Items in green must be upgraded ASAP.

Regarding the attack scenarios I mentioned, the only thing you can do to mitigate one of those attacks is to disable URL fopen() wrappers in your php.ini. For everything else you need to follow the other security practices I mentioned.

The Web Application Firewall and .htaccess Maker are features of the (subscription based) Admin Tools Professional.