[Security] Securing Configuration Files

This is a continuation of our Security Guide see the previous post.

Keeping the scripts on your account up-to-date is a good way to protect your account from hacking and exploiting attempts. There are some other things you can do to insure better security.

Database Passwords
This is a common issue and is mentioned a lot in security circles when it comes to securing your account. Never re-use a password for something else. Ideally all of your passwords would be unique and all aspects of your operation would have their own separate login with unique passwords. This is true for scripts that require databases.

Most scripts have some dynamic aspect to them, which requires the use of a database, typically a MySQL database. While it is a good idea to use unique passwords for different aspects of your day-to-day operation, it is imperative that you use a unique database username and password for the scripts on your hosting account.

As a general rule, any time you are going to be using a database on your hosting account, you should set up at least one database username with a unique password. You never want to use your main account username and password in your script for accessing the database. While this username and password combination will work, it is not recommended.

Consider this. You install a WordPress script on your account. You create a new database to host the WordPress data, but you do not create a new database username to access this database or you reuse your account password as the password for the database username.

Now, if this WordPress script gets exploited or hacked, the hacker could conceivably read your WordPress configuration file:

define('DB_NAME', 'username_wp');    // The name of the database
define('DB_USER', 'username');     // Your MySQL username
define('DB_PASSWORD', 'p@$$w0rd'); // ...and password

Now the hacker has full access to your account. They can log into your account’s cPanel or FTP and cause even more damage.

Just to be clear, if a hacker has hacked your script and is able to read its configuration files, then that is a problem. However, by using a separate database username and unique password you are at least preventing the hacker from easily being able to take over your whole account.

Secure Permissions on Config Files
File system permissions may not be something you are familiar with. As a general rule, any time you see files or directories set with permissions of 666 or 777 this is bad. Without going into all of the complexities of file system permissions, just know that 666 and 777 permissions means that the files or directories are open, they are unrestricted. On our servers, directories should hold a permission setting of 755. HTML files should have permissions of 644. PHP files should have permissions of 644 or 600. CGI file scripts (not PHP scripts) should have permissions of 755. And ideally, PHP configuration files, files that contain login information that a PHP script would use to access the database server or any service that requires authentication should have permissions of 600.

Our servers have a process that goes through and attempts to insure that the permissions on these configuration files is correct. However the process is not without flaws, it cannot catch every PHP configuration file.

To insure that your configuration file is safe, you should consider changing the permissions on the configuration file to 600 after you have installed a script. The configuration file would be the file that you edit to add your database login information. You can change the permissions of a file with most FTP clients, just log into your account via FTP and select the configuration file and change its permission to 600.

Configuration File Placement
In addition to using secure permissions on your PHP configuration files, you can further secure the scripts on your account by placing the configuration files outside of your DocumentRoot.

This option really only works for custom written scripts and the like. Premade scripts, such as WordPress or Joomla, will depend on the configuration file being in a certain location, relative to its installed location. For this reason, placing the configuration file outside of your hosting account’s DocumentRoot will not work for those scripts. This is something that can really only apply to custom written PHP script where you have the ability to hardcode include statements into your scripts.

The DocumentRoot of your account refers to the public_html folder of your hosting account. Anything inside your public_html folder is considered to be web accessible and is thus referred to as your DocumentRoot. When you are in the directory above your public_html folder, your account’s home directory, then you are outside your DocumentRoot. Typically when you log into your account via FTP you are logged into your home directory. Here you will see other folders concerning your account: mail, etc, tmp, public_html. You can create a new directory in your home directory to place your configuration files into or you can just place your configuration files directly into your home directory. The main point being that if your PHP configuration files (files with database login information) are not inside your DocumentRoot then it is more difficult for hackers to read this information should your account be hacked into.

Steven

Next Post Fighting Malware