Protect secret configuration file

I have a file isolated from the others called config.php. It stores information from 3 databases and some sensitive passwords, but necessary for the functioning of the system as a whole. I wanted to protect this file in some way, anyone who accesses my server and finds it will be able to read the information contained in it and disrupt my system afterwards. Is there any solution to this?

Author: Maniero, 2015-03-07

3 answers

If these passwords are necessary for the operation of the system, then they must be available in original format (or equivalent) to that system, either on disk or in memory. 100% protection is therefore impossible, but you can take some measures to limit your access.

First, make a list of who you trust and who you don't Trust:

  • who has physical access to the server, who has the root password, and who accesses the account that owns ( owner ) of this settings file, in these you need to trust - there is nothing you can do to make it impossible for these to access the file;
  • if you do not trust the other users of the server, protecting the file with chmod is a means of limiting its access (this is a good thing to do anyway). I suggest 600 - the owner can read and write, the group and the others can do nothing.
  • if you trust operators but want to avoid your accidental access to the data (e.g. they opened to solve a problem, and ended up seeing the password), you should encode them in some way, for example in base64.
  • in all cases, keep this file inaccessible via the internet - either outside the root of your website/application, or protected with access controls (e.g. .htaccess).

Finally, an option for more "paranoid" cases (may be necessary in case of extremely sensitive data, but most of the time it is exaggeration) is to encrypt this sensitive data, requiring a password for its decryption. Thus, by giving the boot into the system, the operator would enter this password, which would decrypt the remaining data and save it in memory only - and preferably in a memory region that does not undergo swap. The obvious disadvantage of this approach is that if the server needs to be restarted the password will have to be provided again-causing loss of availability if the authorised operator is not present.

A middle ground would be to use a hardware module to do this decryption, so the trust requirements boil down to who has physical access to the machine (i.e. neither the root could decrypt the sensitive data). It remains however the possibility of the user root to use one process to read the memory of another, but I can not say how feasible/likely this scenario is.

 5
Author: mgibsonbr, 2015-03-08 00:18:32

There is not much to do. You can protect from external access with traditional means and protect the entire server so that it does not have improper access but someone being on the server becomes complicated to protect this information.

Some will say to encrypt the file or at least the sensitive data. But with access to the server the decrypted data or the way to decrypt is available as well.

If the intention is to protect from external access can put the file outside the website area in a separate directory probably in a hierarchy below. This will do enough.

If your website is in /http/public, you can put it in /http.

If you cannot do this, you can configure .htaccess with:

<files config.php>
order allow,deny
deny from all
</files>

Another obvious way is to limit access with chmod permissions. Never put 777, probably a 400 will suffice. But this alone is not enough.

 5
Author: Maniero, 2015-03-08 00:35:08

One of the ways you can use to block access to this file would be through a rule via File .htaccess, specifying the file in the policy <Files>:

<Files "config.php">
  Order Allow,Deny
  Deny from all
</Files>

If you need to do the same with other files, you can use the <FilesMatch>, it does the same thing as <Files>, but accepts regular expressions.

<FilesMatch "config\.php|function\.php|include\.php">
  Order allow,deny
  Deny from all
</FilesMatch>
 3
Author: stderr, 2015-03-07 12:50:53