Hardening PHP

Attempting to secure PHP

This is a serious task. The goal is to have PHP as secure as possible, without restricting functionality beyond usability. What that means will depend on your needs. Below are principles for responsible system administrators to consider.

It is always good practice to test any new build to be sure your unique requirements are still functioning properly under a given set of build parameters.

Understand what you are building

When you’re getting ready to build PHP, do not blindly check and uncheck options without understanding the implications of doing so.

Understand what functionality each option will enable and the implications it has for the way you are running PHP. You can be sure that hackers will know how to use various PHP flaws and how to check for them. You should take the time to read the documentation and do some research.

For example, many experts recommend that the register globals and magic quotes options be avoided. If scripts require them, you need to consider finding new scripts. If you do not understand why that is the case, take some time to research them.

Master your php.ini

One excellent way to start hardening PHP is by using your php.ini file wisely. Look up "custom php.ini" in a search engine, and you will find many excellent articles. However, be sure you understand how different changes will impact users' scripts.

For example, disabling the mail() function will stop many spammers from exploiting popular scripts; however, in that scenario, no scripts using this function would be able to send mail. This illustrates an important principle: an effective server administrator must balance security with functionality.

Examples of locking down these functions:

1. Use you preferred text editor to open the following file for edit:
   • /usr/local/lib/php.ini
2. Locate the line that starts with disable_functions.
3. Consider editing the disable_functions line to reflect the following:

disable_functions = exec, shell_exec, system, passthru, popen, virtual, show_source, readfile, pclose

This will directly help keep exploiters from being able to use less insecure our outdated CMS systems to gain access to your system through exec calls and tools like PHP shells.

Run scripts as the user instead of “nobody”

PHP runs as part of the web server so that, among other things, certain tasks can be done once and held in memory instead of repeated with each request. This helps to speed the server’s performance, and requires that PHP run as the web server's user "nobody.”

Since that is the case, PHP and directory permissions generally need to be very loose, so PHP can manipulate things. This can allow any user to employ a PHP script to read and write other users' data. At times, a flaw in PHP can even allow a PHP script to gain root access or take over data in requests on other users’ PHP scripts.

You can run PHP as the user (like CGI scripts do with Apache's suEXEC), with EasyApache's PHP As User option. This will enable suPHP, greatly improving the permissions situation. Vulnerable scripts will be limited to the user in question, and are less likely to affect other users. It also changes how PHP interacts with Apache; for example, directives like php_$value are not valid for mod_suphp.

Note: mod_suphp is considerably slower than mod_php.

Other options exist to run PHP as the user; see Apache PHP Request Handling for more information.

Use hardening tools, like Suhosin®

The Suhosin extension "was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core." Visit the FAQ and other resources at the Suhosin website to find out whether this particular tool is right for you.

Perhaps more importantly, the Suhosin community would be an excellent starting point for learning about flaws in PHP, as well as other extensions, configurations, and techniques you can use to protect your server.

Since many popular scripts are not compatible with Suhosin's restrictions (depending partially on how you configure it, of course), we highly recommend that you test Suhosin before implementing it on a production server.

Do not allow insecure scripts

This might seem obvious, but it requires diligence. It is a very nebulous concept which can range from adjusting settings or policies, to looking for and removing known problem scripts, and even going as far as recommending non-PHP alternatives.

We strongly advise that you keep up with known vulnerabilities. Here are some examples of sites that regularly post an updated list of isolated vulnerabilities:

• Milw0rm
  • Milw0rm on Twitter.
• Government Security

One of the most common methods an attacker will use is to use a search engine to isolate sites running content management systems with known security holes and using the known exploit to gain access to your system. Keeping a watchful eye on matters such as this is a very important task as system administrator.