Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By ntg on
Hello,
I am interested in making my Drupal 6 installation more secure. I've googled and searched in the drupal.org site but did not manage to find any security tips.
I was thinking of putting the settings.php file outside/above the public_html directory.
I made a test drupal 6 installation, opened the settings.php file and replaced the line of code containing the database username and password with this one:
include('/home/username/my_site_settings.php');
Then I created another php file called "my_site_settings.php", I pasted there the line of code with the database credentials and uploaded it on the /home/username/ directory (above the public_html).
My drupal 6 site works fine so far. But my question is:
Does this 'modification' of mine make Drupal more secure?
Thank you for your replies.
Comments
Id be interested in knowing
Id be interested in knowing more about this as well.
Interesting approach.
Subscribing to learn more.
bump Any suggestions/ideas
bump
Any suggestions/ideas about that?
Why?
Fine.
So that works.
So, um, in what way is that any more secure than anything?
settings.php (and in fact all code) should be set read-only from the server daemon user, and Drupal will bitch about it if it's not so, so here's no security hole from that vector.
OTOH, If someone gets access to write to your web code files, you are already broken.
settings.php does contain your database password in plaintext, yes, but what you've just done hasn't done anything to hide that. The Web user can still access those details if they are able to run php on the server, (or even if they are running a different website on the same machine as you on some hosts).
OTOH, If they can run php on the server as you, you are already broken.
I don't think that this particular exercise you've described here does anything effective. Whatever you think you are protecting against is probably still a threat.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Hi Dan, Thank you for your
Hi Dan,
Thank you for your reply.
I had created some websites using Wordpress and one of the practices to increase the security of the installation, was to move the config file outside the root so that the file is not accessible by a web browser.
That's how I came up with the idea of doing the same with my Drupal site. It's not that there is a threat that I am trying to protect my Drupal site from.
But why does the above practice make a Wordpress site safer and not a Drupal one?
I am not very familiar with all this, so I would appreciate any explanation.
Thanks
ntg
speculation
Speculating here, but worst-case scenario (and one I have managed to do - temporarily - on test sites) is that
If your server became unconfigured and stopped executing PHP scripts correctly (through a botched upgrade or root configs being deleted accidentally) then *.php files may end up being served through the webserver in plaintext.
That could conceivably mean that your database password could be publicly viewable.
In such a situation, you'd have big bad problems that would have to be fixed up anyway, but it's a slightly scary thought. Any robust server would not have that happen in the normal course of events. It's not a sane fear.
What the probable 'logic' is may be along the lines of "if the file can be accessed under web directory, it can be read" ... which sounds like a worry, but is not altogether true.
A slightly bigger danger is that other users with the same permissions as you on the web server (neighbors on a shared host) can - if they are clever - sometimes read your config files. This would be something to avoid, but shifting the file to another folder does nothing to really prevent that, as the server daemon with the same permissions still has (has to have) read-access to the file wherever you put it. So you've only added a little bit of obscurity to the default install. This may be enough to confuse a web worm - but only by accident.
There are other better best-practices to try if you want to harden your site. Starting with ensure your database password is not the same as your drupal login or your account password, ensure your code files are not web-writable and other such ideas.
What you've described here is mostly voodoo unless you've got a rationale for it. IMO.
I'd trust that the hundreds of current users and developers of Drupal have seen and tried and fixed a lot more exploits than any one individual can imagine, and we are still using settings.php on real sites, so ...
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Thanks again
Hi Dan,
Thank you for your help. I appreciate it.
Now things are more clear to me.
By the way, I've already followed the "best-practices" you mentioned.
Kind regards
ntg
More details
dan,
I'm just a novice when it comes to server config but have wondered about this question as to whether or not moving files out of the public_html folder makes the site more secure and appreciate the details you provided.
Here is an article that describes the how to with symlinks in great detail
http://justinhileman.info/articles/a-more-secure-drupal-multisite-install
It doesn't really answer why this is more secure but restructuring a site with symlinks like this can allow for separate .htaccess files for each site which in itself can be very useful.
Izzy
That huge effort described
That huge effort described there seems to mainly be because of the problem (?) of allowing access to http://site1.example.com/files/site2/image.jpg
... which is true, and a bit odd, but not what I'd call a security issue.
Different .htaccess rules in one file can be done with logic in the Apache directives if you really want them.
That write-up is basically about keeping multi-sites insulated from each other, not about 'security' from outside. If you are going to go to that much work to mesh up an install, you may as well run two drupal codebases, IMO.
The only nod to an imagined security improvement is when he mentions in the comments that editing with pico may leave a settings.php~ file behind and that may become readable. That's conceivable if your command editor crashes in mid-type and if it doesn't save those temp files with even moderately safe permissions (which I'm pretty sure it should) and if Apache hasn't been told to not let that though (which it could be ... but normally isn't)
So yeah, I appreciate why someone would want to consider the possibilities, but it's not something I'd lose sleep over, and certainly not something I'd mess up a drupal install this much for. Imagine the maintainer that comes after him trying to untangle a set-up like that!
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Thanks for your thoughts
Thanks for your thoughts
A simple solution
Just had a client that requested the same thing (they were concerned that PHP parsing should for some reason stop working and their settings.php file with username and password to the databasen would be visible. So I've been thinking about this for a couple of minutes and I think I came up with a simple but powerful solution. The whole problem is that settings.php needs to be outside the Apache documentroot. I see people are talking about symbolic links which won't help at all :) The only think you need to do it move the settings.php file outside documentroot and include it from the original settings.php file.
In example:
/home/settings.php <- The actual settings.php file with real values. Outside of documentroot.
/home/drupal/sites/default/settings.php <- A simple php file that contains only include_once('../../../settings.php');
(in this case documentroot is set to /home/drupal)
So if PHP parsing in Apache for some reason should stop working and someone types in the settings.php url in their browser, all their going to see is the include_once statement. All though they can see the path of the actual settings.php file they can never reach it as it's outside the actual documentroot.
----------------------------------------------------------------------------
Thomas Kulvik
Partner / Manager @ Ny Media AS
Website: http://nymedia.no | Email: thomas@nymedia.no
Phone: +47 4000 7955 | Mobile: +47 920 28 082
----------------------------------------------------------------------------
The settings.php file is not
The settings.php file is already inaccessible in sites/default/settings.php, so why change the location ?