Joomla! Discussion Forums

The learned mr rliskey quotes:




Which ?critical? Joomal! directories would you suggest relocating? Which individual files also make the short list?

I had a crack earlier this evening at placing my configuration.php above public_html and it worked fine for the front end but in my 20 minute attempt (I wasn't very dedicated I know) I couldn't get the admin working.

Thoughts please... about to go live.

Thanks

Hey there. The correct title is, "The slowly learning mr rliskey". We're all on the path.






I was referring to directories, NOT the configuration file. I agree completely that configuration.php has no business in public_html, but moving it requires hacking a bunch of core files, so I've been told it's probably not worth the effort, and that this will be easier in 1.5. I'm trying to hold out for that before I do any major hacking.

In my apparently not-so-humble-seeming opinion, the only files that SHOULD be in public_html are the ones that MUST be there, such as index.php and index2.php. Some time soon, hopefully in 1.5, I'm going to try to move everything else out.

There are a lot of much more experienced Joomla developers that don't agree that getting things out of public_html is so important. I really don't understand that perspective, but that doesn't make them wrong.

Here are a few directories that I know about that can be moved by setting params (no hacking required):

• In the backend Administrator, Global Configurations: Set the path for the cache directory
• DocMan: Set the path for the docs directory
• Gallery2: They strongly recommend setting the path to the image storage directory outside of public_html

Good idea, so that nobody can guess the names of cache files, any like this maybe access confidential cached information.



Important to make sure no "executable" files (e.g. php, perl) can be uploaded, just in case the uploader does not check this good enough.


Another thing I do on my sites is to move the configuration.php out of the web root.

I replace it with a file with these contents:
[code=configuration.php]
require( dirname( __FILE__ ) . '/../joomla.conf' );
?>
[/code]

Then I make sure that this new configuration.php is not writable at all, so that it can not be overridden by com_config. If I need to change some settings, I do it manually in the relocated joomla.conf. Even if the web server maybe delivers the content of PHP files at some time (due to e.g. a misconfiguration), nobody is able to see the contents and passwords in the real configuration file.

Very slick...  that should be added to the security checklist.  I'll have to try that out.  Thanks for posting that. 

[EDIT: Updated link to the new FAQ section of the Help site]
Absolutely! Here's the new FAQ: http://help.joomla.org/component/option ... temid,268/

mr rlinsky,

I have again been reminded to use emoticons. 

I was paying you a compliment.. I apologise for the grief.


Thank you for our suggestions.

davedbk

friesengeist,

Nice solution.



As am a little green, couldn't get your syntax to work - it was appending the live_site var to the front of the path... so I hardcoded the full path.




Any issues with this?

Thanks,
davedbk

That's fine as well

To what should the permission on this file be set?  Is 644 okay?  Anything else you do to make sure this file isn't writable?

444 is better if your system allows it.

I did some additional reading and determined that this depends on how the webserver is setup (The webserver may, or may not, run under its own user account.)  In my case, it's a shared hosting environment; so the webserver is setup to run under MY account.  That means that I must allow owner read permission, otherwise the webserver will not be able to access the file.

If 0400 works, I would use that, next best thing is 0440, and last option 0444. When the configuration file is set to 0444, usually everyone hosted on that server (unless your host has taken some precautions against others seeing your files) can see your DB password. So, the less permissions, the better it is.

require( dirname( __FILE__ ) . '/home/basket/resource4sports.conf' );
?>

I hav tried to install this security but it shows this error

Warning: main(/home/basket/public_html/resource4sports/home/basket/resource4sports.conf) [function.main]: failed to open stream: No such file or directory in /home/basket/public_html/resource4sports/configuration.php on line 2

Fatal error: main() [function.require]: Failed opening required '/home/basket/public_html/resource4sports/home/basket/resource4sports.conf' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/basket/public_html/resource4sports/configuration.php on line 2

Any suggestions????

By this your asking for resource4sports.conf file in http://www.yourdomain.com/home/basket/r ... onf.  You should be able to use the original string:

require( dirname( __FILE__ ) . '/../resource4sports.conf' );

or:

require( '/home/basket/resource4sports.conf' );

The way you were attempting to use it actually keeps it in public html as you were combining the two choices--sort of. 

Hope that helps, good luck!

Still it gives this error


Warning: main(/home/basket/public_html/resource4sports/../resource4.conf) [function.main]: failed to open stream: No such file or directory in /home/basket/public_html/resource4sports/configuration.php on line 2

Fatal error: main() [function.require]: Failed opening required '/home/basket/public_html/resource4sports/../resource4.conf' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/basket/public_html/resource4sports/configuration.php on line 2


My System uses

Apache version  1.3.36 (Unix)
PERL version 5.8.7
Path to PERL /usr/bin/perl
Path to sendmail /usr/sbin/sendmail
Installed Perl Modules Click to View
PHP version 4.4.4
MySQL version 4.1.21-standard

Thank you

the new configuration.ph is set to 444
i would like to ask what is the permission for the resource4sports.conf??

(/home/basket/public_html/resource4sports/../resource4.conf) should actually be
(/home/basket/public_html/resource4sports/../../resource4.conf).

This would place the conf file here:

/home/basket/resource4.conf

I should have noticed you were in a subdirectory of your public_html folder. 

On permissions, there are a couple ways to go.  You can upload with FTP in which the owner and group would be different than the Apache user and group.  This would require at least world readable, 664, for example.  If you uploaded with Apache, then you could do 400 or 600, owner readable or owner read + write.  The other way around this if you have to use FTP and don't like world readable is to upload with FTP, rename, and the copy the renamed file back to the original with Apache/PHP.  This will make the owner of the copy the Apache user.  I uploaded a component a couple weeks ago to the extension directory to allow you to perform these actions.  As far as I know Joomla! Explorer will not traverse past the web root, but I could be mistaken.

If you are still having difficulties, I would encourage you to just try it with an absolute path, example:


require( '/home/basket/resource4sports.conf' );

and of course place this file in that location.

Sorry about the confusion, let me know if I can help anymore! 

My GOD Thanx, I am rebuilding my website for the 3 time now, because of hackers and crackers.....

Any suggestions on which files to extensions should be handled in this manner to improve security???

I am not a webmaster just a former athlete trying to do some good...

Thank you for your support...

Harvey

Since you are posting here I assume you've read the admin security check list:

http://forum.joomla.org/index.php/topic,81058.0.html

It gets kinda weird when you start moving filed outside of web root.  For any included file, this same technique could be applied, but that would be extremely tedious.  I have not looked too much into applying this to other extensions as most of them do not or should not have sensitive information such as the SQL connector or file system details in them.  I would not look too much into using this technique for extensions as I would try to enforce file permission security.  Using the admin back end is a nice way to do this.  If it doesn't need to be world readable, then don't make it if you are concerned.  Mostly I would say using least the least privileges with file permissions and sound .htaccess usage are the best ways to go.  Oh and of course if you don't use an extension, get rid of it.

If you are having these hacking problems, you might want to double check all your extensions for updates and prune what you don't need.  Also if you are on shared hosting, try to avoid world writable as much as possible.  I'm complaining to my host right now because I was able to  traverse the directories of other hosting customers on the server and read files. This is very, very bad.  It would make someone able to read my configuration or .conf file if i had it set to 444.  Which is why I said use the least privilege necessary.  If you know only apache needs access to a file and you are concerned about it's contents, don't make it world readable.  Group typically is unique for each user, i.e. httpd:httpd, but it is good practice to make owner permissions unique.  In other words, 744 and 644 rather than 774 and 664.

Thank you for your time and effort...

Sincerely yours Harvey

Excuse my ignorance, but whats makes a folder public html?

Thanks
Matthew

Anything that is directly visible by the public, i.e. http://www.yourdomain.com/yourfile will reside in some folder such as /home/www/public_html/yourfile.

hi jefe,

i am having problem using the method above, any idea how i can fix this?

returning

Warning: main(): open_basedir restriction in effect. File(/../joomla.conf) is not within the allowed path(s): (/var/www/vhosts/******.net/httpdocs:/tmp) in /var/www/vhosts/******.net/httpdocs/configuration.php on line 2

Warning: main(/../joomla.conf): failed to open stream: Operation not permitted in /var/www/vhosts/******.net/httpdocs/configuration.php on line 2

Fatal error: main(): Failed opening required '/../joomla.conf' (include_path='.:') in /var/www/vhosts/******.net/httpdocs/configuration.php on line 2

For more info:

http://us3.php.net/features.safe-mode

But basically I would try just using an absolute path rather than remapping with the relative path.  For example:

require ( '/var/www/vhosts/******.net/httpdocs/configuration.php' );

Also, it seems that you are still keeping it in the web_root?  You may want to try this or something similar if you can:

require ( '/var/www/vhosts/yoursite_joomla.conf' );

You don't have to use the .conf extension, it is just nicer since it prevents it from being interpreted directly by the PHP engine, (due to MIME types).  That should fix the problem, but you may have Safe Mod on...a not-so-great security tool that will be deprecated as of PHP 6.  Anyway, try using the absolute path instead and see what you get.

Good luck. 
Jeff McCoy

make sure to remove any blank lines in your new configuration.php file.

having blank lines outside the "" tags will cause 'headers already sent' errors. maybe it'll mess up some other stuff, too.

I'd like to hear some thoughts, besides changing hosts, on what to do when the only accessible directory is public_html?

I'm assuming this means you're on a shared server, which means all your directories are potentially vulnerable anyway if another site on your server is compromised. (BTW: I use shared servers too. Not trying to knock them, just not pretending they are really secure.)

My thoughts (for whatever they're worth) are:
1. If you use a shared server, be sure you have a great host who cares about your security. There's a list of good hosts on this forum.
2. Files in public_html can be relatively safe if file permissions are carefully set, i.e., avoid settings such as 777.
3. Expect to get cracked someday, and have a strong backup and recovery process in place. (Good rule for all of us.)
4. Do step 3 BEFORE you need it.

Thanks for the reply. I considered the likelyhood of being cracked too unpleasant and opted to change hosts!! 

You can often get around open_basedir restrictions by creating another directory at a parallel position in the directory tree, and with a similar name. Here's an example:



The trick is to concatenate to the allowed directory name when creating the new private directory. This works if the open_basedir setting does not end with a slash. Luckily, as in the example above, they often don't.

Nothing appears. Blank page.