move configuration.php and tmp above public_html

[greguy]

Hi,how do I move configuration.php and the tmp folder above public_html.I have access to root through wincp so I can manually move the folders up a level but what extra steps do I need for it to work with joomla 3.2?.

I have found instructions here
http://docs.joomla.org/Moving_sensitive ... e_web_root

But they don't seem relevant to joomla 3

Thanks Greg

[PhilD]

Did you see this warning? It is no longer recommended to move the configuration.php file.
http://docs.joomla.org/Moving_sensitive ... e_web_root

Moving the configuration.php from your root of your Joomla installation as described in the procedures below makes no sense at all if your website or server is insufficiently protected. Moving the file only prevents the viewing of the Joomla configuration file by the casual observer. It offers no protection if root access can be been gained to your domain in some fashion, nor does it prevent root access to your domain that is the result of security compromises in Joomla, from 3rd party extensions, or similar insecurities from access gained through badly configured/protected remote or local servers."

You should also be sure you are following the information and documentation posted here:
http://forum.joomla.org/viewtopic.php?f=621&t=582854

This will help keep your site secure. also consider moving to 2.5 or 3.0 of Joomla as 1.5.xx is at end of life with very limited (your basically on your own) support.

[sovainfo]

what makes you think it is not relevant for j3?

[mandville]

WARNING: Do not attempt this procedure unless you understand what you are doing and are willing to possibly break your site while testing. This is not for beginners or inexperienced persons, ensure you have a back up of your site and also of the files you will be modifying before attempting this modification.

Moving the configuration.php from your root of your Joomla installation as described in the procedures below makes no sense at all if your website or server is insufficiently protected. Moving the file only prevents the viewing of the Joomla configuration file by the casual observer. It offers no protection if root access can be been gained to your domain in some fashion, nor does it prevent root access to your domain that is the result of security compromises in Joomla, from 3rd party extensions, or similar insecurities from access gained through badly configured/protected remote or local servers."

[sovainfo]

In the post: Before you post, that PhilD referres to, the Vulnerable Extension List (VEL) is mentioned.
The way I read it it says the extensions have to be on that list. I think they meant to say that you need to investigate extensions that are on that list. Someone claims there is a problem with that extension. Look into it!

[mandville]

the post by phild was in the wrong topic, now moved to correct topic

[jdbdrwho]

... move configuration.php and the tmp folder above public_html.

The method of moving configuration.php above public_html can be done by tricking joomla by moving the configuration.php file into some directory or in the root for your hosting account. Problem is that if you have multiple joomla configuration files you would need to do something to identify each configuration.php file.

Renaming the configuration.php file to configuration.sitename.php and store it in a folder to hold all your site settings (For Example ~/sitesettings)

Then you would only need to create a configuration.php file with the contents:

Code: Select all

<?php
   include ("~/sitesetings/configuration.sitename.php");
// Or specify the full path.  However this doesn't really offer any protection
// as the hacker can read the include file and know where all your php config files
// are located.  So this is really of no benefit.
?>

Additional method you may find useful however would be to deny access to the configuration file for viewing from a browser by use a .htaccess command:

Code: Select all

<files "configuration.php">
  Order Deny,Allow
  Deny from all
</files>

The .htaccess configuraitons flow downward so if you put the code above in your public_html/.htaccess then you do not need to put this same command in your other directories for joomla. You can even create a .htaccess file in your home directory.

One of the best security measures you can take however with your joomla or other php scripts is to make sure that you always update your php scripts to the latest version. Never allow the setting 777 or 666 to be set on your files.

If you find that you have problems with file permissions and if you have access to SSH then try the following command from your public_html directory from the ssh prompt.

Find and fix directory permissions:

Code: Select all

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

Find and fix file permissions:

Code: Select all

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

You do need 755 on cgi scripts (.cgi, .pl, .pm, .plx...). You may need 755 on other extensions as well if the extension requires execute permissions however most files will be fine with 644.

You should also check Joomla's Security Check list:
o http://docs.joomla.org/Security_Checklist_7

You should always uninstall scripts that are no longer in use. As you may forget about these old folders that are not in use and then have a php weakness that never gets addressed until your site get hacked.

Always remove themes, plugins and components that are not in use. Keep your site as clean as possible. Clean from an wanted clutter.

You should also backup your websites. Do not rely on your hosting provider to backup your sites. If you value your website back it up and store that backup offline, some safe and not forgotten location.

[PhilD]

@jdbdrwho

1.)

You do need 755 on cgi scripts (.cgi, .pl, .pm, .plx...). You may need 755 on other extensions as well if the extension requires execute permissions however most files will be fine with 644.

this is not true in most cases files should be 644, directories should be 755, scgi scripts normally only need 700. You should always use the tightest permissions that can be used in a particular situation.
http://docs.joomla.org/Security_Checkli ... issions%3F
and
http://docs.joomla.org/Security_Checklist_7

2.) Making a "fake" or substitute configuration.php file is useless, as the first time someone saves the configuration file from the administrator back end it will be overwritten with the full configuration.php file.


The proper way would be to create overrides as described in the document the Op posted the link to.

To everyone.
Moving your configuration file to anywhere is useless and provides absolutely no more protection for anything than simply leaving it in it's default place. Moving the file outside of the public_html area is useless. Joomla has to read the config file in order to operate at all. By the way things work, Joomla is the httpd (usually apache) server, which is the world for all practical purposes. So if Joomla can read the file no matter where you locate it in order to operate, then so can a hacker if your site becomes hacked through any number of insecurities.
Quit wasting time on snake oil and make sure the sites are kept up to date, with proper permissions and enjoy Joomla.

[darb]

I think you also can chmod it to 444..

[tradetaxfree]

Secure access to files with .htaccess:

Code: Select all

<Files ~ "\.(tpl|bak|old|ini|htaccess|dist)$">
Order allow,deny
Deny from all
</Files>

<Files *.php>
deny from all
</Files>
<Files ~ "(^index.php|^index2.php)$">
allow from all
</Files>

[itoffshore]

If you don't mind manually editing configuration.php the following settings are quite secure:

Code: Select all

chmod 750 /path/to/public_html
chmod 444 index.php
chmod 440 configuration.php

configuration.php only needs to be readable by the user or group the webserver runs as. It does NOT need any permissions for world set (which is the last digit of the chmod command).

tmp & logs directories can be moved quite easily above public_html by editing configuration.php

You can tell also tell php to move the upload directory outside of public_html:

Code: Select all

php_admin_value[sys_temp_dir] = /tmp
php_admin_value[upload_tmp_dir] = /upload

[mandville]

tmp & logs directories can be moved quite easily above public_html by editing configuration.php

you obviously did not read anything in this ancient topic while valid your comments may be valid in this situation (joomla) read this topic several times
http://forum.joomla.org/viewtopic.php?p ... 5#p2940755

[itoffshore]

Many users do not adequately protect front end access to tmp & logs.

My comments close several attack vectors.

You should take your own advice.

[mandville]

My comments close several attack vectors.

as stated in

while valid your comments may be valid in this situation

You should take your own advice.

please indicate where and what you mean by that. for full reference here is the explanation on why your suggestion may break more than it solves. https://docs.joomla.org/index.php?title ... ldid=68318 on a proper set up server you dont need your suggestion

[itoffshore]

I do not suggest moving configuration.php outside of the webroot - it is sensible to change the file permissions to 440 so it is NOT readable by world (& not 444 as recommended above).

If front end access to most joomla directories are not blocked by the webserver configuration many more exploits become possible. The 755 permissions also recommended above could allow an attacker to execute a script in tmp if they are able to upload a file to the webserver (until recently this was possible by exploiting the simplepie library built into joomla). If tmp is located outside of the webroot with permissions of 750 or 770 this attack is not possible. The logs / tmp directories do not need any permissions for world wherever they are located.

The suggested secure htaccess file (or equivalent rules for nginx) - that limits front-end access to files & directories is essential to protect your website.

I reported the simplepie exploit recently & recommended additional information to the joomla docs which will prevent this type of attack from being possible under nginx.

Another possible method to protect configuration.php in the future would be for joomla to support using sql.safe_mode - then it would not matter if configuration.php was compromised - because there would not be any user or password in configuration.php - only the database name (this needs some work as joomla seems to expect to receive a user / password for the connection).

[mandville]

Right so in a 4 year old topic about the config file you mention tmp and log directories.

[Webdongle]

@itoffshore if a Hacker see the contents your configuration.php (when it is 444) then moving it to a higher folder wont help much.

[JAVesey]

@itoffshore if a Hacker see the contents your configuration.php (when it is 444) then moving it to a higher folder wont help much.

Nail. Hammer. Whack.

[itoffshore]

you are both ignorant - re-read what I have written

[Webdongle]

No it is you that is ignorant in that you are lacking the knowledge that JAVesey and I have. I will try and explain it as simply as possible.

Yes there are exploits that occur from time to time and yes there are other reasons that hackers are able to access your server.

If a hacker has access to your server then it does not matter that they can read your configuration.php file because they already have control over your server and everything on it. Thus moving the configuration.php to a higher folder won't help because they can also read it there. Once a hacker has access to your server (whichever method they use) then they can do anything to the files that you can do.

In other words they can read the configuration.php wherever you put it. But they have that much control over your server and site that they don't need to read it.

[itoffshore]

your recommendation for configuration.php to be world readable is just plain stupid.

[deleted user]

Yes, 440 permissions would be optimal. However, as pointed out, if your site is hacked and someone is able to execute scripts on your server, it doesn't matter where that configuration.php file is as it can be read by that script. So don't think just because you restricted the permissions massively that you're in the clear.

Also, if you really have a concern on that last digit's value, there is a serious server misconfiguration issue on your hands. A well configured server won't let users into the home directories (talking normal cPanel type stuff now) of other users, let alone read their files.

[Webdongle]

your recommendation for configuration.php to be world readable is just plain stupid.

You are misinterpreting the meaning of the 'Read' value. It does not mean that it can be read by a visiting Browser ... it means that it can be read by a script that is on your server. And as previously stated if a hacker (by whatever means) has access to your server then he can read the configuration.php because the hacker will be treated as 'Owner'. The hacker can upload files to your server, edit files that are on your server and change folder/file Permissions of folders/files on your system. If the hacker can access the contents of the configuration.php file then they have 'Owner' Permissions on your server.

[sovainfo]

your recommendation for configuration.php to be world readable is just plain stupid.

You are absolutely right. Embarrassing to see that many cowboys here ridicule it. Although several already have proven not to have the proper reading skills advice them read up on the unix filesystem security.

As far as the webserver is concerned owner or group access is the only thing needed. It depends on your configuration of the webserver. Assuming you don't want anyone outside your group to have any access the 0 in the last position is correct. That applies to anything in your webspace. Obviously you may restrict it to that what contains sensitive data, but what stops you from applying it to everything.

[fcoulter]

To those participating in this discussion, I would like to remind you of the forum rules: viewtopic.php?t=65

particularly the one that says:

Keep all commentary civil, and be courteous at all times. Constructive criticism is welcome, but insults directed towards other users or the site admins will not be tolerated. Coarse/insulting language will not be tolerated.

It seems to me that there is room for a difference of opinion on this topic.

[sovainfo]

Because you just posted after me, I have to ask.

Do you consider the facts I reported in breach of those rules or are you referring to the patronizeng responses of mandville, webdongle and JAvesey ?

[Webdongle]

@fcoulter

I would like to point out that there are no insults. The word 'ignorant' means "lacking knowledge or awareness." and is not an insult. Also that describing an action as stupid is not an insult. It is obvious that itoffshore feels strongly about this topic and is frustrated because he thinks others are not understanding his point. Those of us replying to this post are trying to help him understand why he has a misconception of the configuration.php being 'readable'.

[fcoulter]

My comment was deliberately not aimed at anyone in particular, but was a general appeal for courtesy in the discussion, which I think has been rather lacking.

If you have to explain why something is not an insult, it suggests to me that it probably is.

[sovainfo]

It seems to me that there is room for a difference of opinion on this topic.

Agree with that there is room for differences of opinion.

Sofar a number of people that know what they are talking about explained or referred to valid documentation about filesystem security. Consider telling them they are wrong just stupid. That is not a matter of opinion, it is just not accepting the facts.

Whether you require strict security applied I do consider a matter of opinion. So, if you don't care who sees what in your webspace set world access higher than zero. Security minded people use zero in world access.
You may hope the webserver is properly protected, don't circumvent that security by providing world access.

So, there can be differences of opinion about what Joomla should do. And I support the opinon that a database password has no place in a world readable file! It is futile to improve security in other aspects (password & utf8mb4) when you leave the door open on the filesystem.

[Webdongle]

...
If you have to explain why something is not an insult, it suggests to me that it probably is.

No ... it means that I am familiar with how people misinterpret phrases. And as a result I could quickly Identify your misconception that caused you to post your incorrect off topic assumption.

Now can we please get back on topic as to necessity or not as to the value of the last Permission bit for the configuration.php ? What is your opinion on that ?