Securing PHP Installations on Linux with Apache Best Practices

As we know that the vulnerabilities in PHP are increasing day by day there comes the need to secure the PHP installation to the highest level. Due to its popularity and its wide usage most of the developers and the administrators will be in trouble if they don't take appropriate steps on security issues during the installation.

First comes the question of choosing the platform for PHP! I have choosen Linux OS and Apache Web server to explain this because of its performance and security aspects. It depends on the developer's need whether he is going to install it as an Apache module or a CGI interpreter. When choosing to build PHP in either of the two ways, you should consider the advantages and drawbacks of each method.

Building as a shared object will mean that you can compile apache separately, and you don't have to recompile everything as you add to, or change PHP. Building PHP into apache staticly means that PHP will load and run faster.

Advantages

Server is more flexible. It can be run as SSL, mod_perl, or php with only one installation.
Servers can be extended with other modules even after installation.
Easier module development and testing as the compiling apache source is not required each time the module is changed.

Disadvantages

DSO is not supported on all platforms.
Startup of the server is 20% slower due to symbol resolving.
The server is approximately 5% slower at execution time under some platforms because position independent code (PIC) sometimes needs complicated assembler tricks for relative addressing which are not necessarily as fast as absolute addressing.
DSO can produce a slightly slower server depending on platform and address resolutioning.
DSO modules cannot be linked with other DSO modules. For example a.out-based platforms usually don't provide this functionality while ELF-based platforms do. You cannot use the DSO mechanism for all types of modules. This requires either the code be referenced directly through the Apache core, or that you compile Apache with chaining available.
Some platforms cannot force the linker to export all global symbols for linking DSO and Apache executables. This is overcome using the SHARED_CORE feature of Apache and is used by default on such platforms.

Advantages/Disadvantages of compiling PHP as a CGI interpreter

PHP can be compiled as a CGI binary, this allows a user to separate PHP from their web server entirely. Each PHP script that is written will need to contain a statement that points to the path of the PHP binary just as in PERL.

#!/usr/local/bin/php
CERT Advisory CA-96.11 advises against placing any type of interpreter in the CGI-BIN so it is a good idea to create an isolated directory where PHP can be run.
PHP has built in security measure to prevent malicious attacks of this type as well. In the configuration file for PHP, you can specify the following security features:
- doc_root This options only works when PHP is installed in Safe Mode. This specifies where the root document directory of PHP is. Scripts outside of this directory will not be interpreted.
- User_dir This option only works when PHP is installed in Safe Mode. This variable specifies user directories so that scripts outside of this directory cannot be executed.
- --enable-force-CGI-redirect This allows you to force redirection so that scripts cannot be access directly from the internet. Scripts are redirected to a URL, hiding their full path names.

Building as a CGI Binary means efficiency could be improved by having only a single Perl interpreter running in memory, and passing it the Perl scripts. This is where mod_perl comes in to the picture. It provides a single embedded Perl interpreter within the Apache web server. This can be either statically linked, or as a DSO module.

Some of the advantages of mod_perl are:

Able to write Apache modules entirely in Perl.
Having a persistent interpreter in the server saves on overheads due to starting a perl interpreter for each script.
Offers code caching, where the modules and scripts are being loaded and compiled only once.
Increased power and speed.
Full access to the web server.
Allows customized processing of URI to filename translation, authentication, response generation and logging practically no run-time overhead.
Improved performance of %200 - %2000 is apparently obtained.

One of the major drawbacks of a CGI interpreter is when PHP is compiled as a CGI. This means a lack of effieciency in handling high traffic applications.

PHP installation is very easy but installing PHP in a secured manner depends on your platform, installation type selection, and configuration options considered. Whatever method you choose please remember to follow the recommended PHP Configuration Options.

There are various options that can be set in PHP to increase the overall security of your server. We will discuss some of the most common and useful options.

Safe_mode

Safe mode is required for nearly all of the following options, safe mode allows PHP to impose more security restrictions than a normal configuration.

Safe_mode_exec_dir

Setting this variable helps you in forceing PHP to only execute scripts from a specified directory.

Open_basedir

This option allows you to control which directories PHP scripts are allowed to access files from. By default PHP will allow a script to access a file from anywhere so it is recommended that is option be set. By predefining valid directories, data can be protected.

Max_execution_time

This variable enables you to set a maximum execution time that a script can have. If a script runs longer than the allocated execution time, it will be terminated. This option will allow you to prevent attackers from tying up your web server with malicious scripts that could cause denial of service.

Memory_limit

This allows you to control the maximum amount of memory that a script can use. Using this will help to prevent buffer overflows which may lead to more serious threats.

Upload_tmp_dir

This designates where PHP will place files that are being uploaded.

We will discuss both cases here.

PHP AS AN APACHE MODULE:

Here Apache should run as an ordinary user with least privileges. Never run apache as a root user. Try to run Apache in a root jail. If you are running PHP as an Apache Module it is fine, means it provides maximum security. Following are the steps to install and configure the same.

gunzip apache_xxx.tar.gz
tar -xvf apache_xxx.tar
gunzip php-xxx.tar.gz
tar -xvf php-xxx.tar
cd apache_xxx
./configure --prefix=/www --enable-module=so
make
make install
cd ../php-xxx
./configure --with-mysql --with-apxs=/www/bin/apxs
make
make install
If you decide to change your configuration options after installation, you just have to repeat the last three steps. You also have to restart apache for the new module to take effect. A recompile of Apache is not needed.
cp php.ini-dist /usr/local/lib/php.ini
You can edit your .ini file to set PHP options. If you prefer this file in another location, use --with-config-file-path=/path in step 8.
Edit your httpd.conf or srm.conf file and check that these lines are present and not commented out:

AddType application/x-httpd-php .php
LoadModule php4_module libexec/libphp4.so

The path on the right hand side of the LoadModule statement must point to the path of the PHP module on your system. The above statement is correct for the steps shown above.

Different examples of compiling PHP for apache are as follows:

./configure --with-apxs --with-pgsql

This will create a libmodphp4.a library, a mod_php4.c and some accompanying files and copy this into the src/modules/php4 directory in the Apache source tree. Then you compile Apache using --activate-module=src/modules/php4/libphp4.a and the Apache build system will create libphp4.a and link it statically into the httpd binary. The PostgreSQL support is included directly into this httpd binary, so the final result here is a single httpd binary that includes all of Apache and all of PHP.

./configure --with-apache=/path/to/apache_source --with-pgsql=shared
./confgure --enable-debug=no Note: Will not disclose the physical path if some error occurs.
./confgure --enable-safe-mode

Banner Off in apache's configuration file httpd.conf, will not disclose the server's banner information. This makes attacks more difficult for would-be intruders.

Lets consider the second case...

PHP AS A CGI INTERPRETER:

Download the latest version of PHP from PHP: Downloads.

Extract the package

# tar zxvf php-x.x.x.tar.gz Where x.x.x. is the version number.
Change to the PHP directory

# cd php-x.x.x
Configure it with the various options present

#./configure --without-apache --without-apxs --enable-force-cgi-redirect

This is to tell PHP that it isis built without Apache support and as a CGI binary. You should get the binary in /usr/local/bin/php.

Now you know why it is compiled with the --enable-force-cgi-redirect option.

The CGI binary isn't compiled within Apache, it runs under a separate process and user. Hence the question comes of placing the CGI binary in a proper location. I would suggest that the CGI binary should be placed outside the web directory, as the risk would be greatly reduced and also make sure that you have enabled safe mode in the php.ini configuration file.

Most commonly attacks arise in the form of getting access to files. Therefore you can prevent the user from calling the CGI binary directly by forcing a CGI to redirect within Apache. For this, just add the following directives in Apache's httpd.conf file:

Action php-script /cgi-bin/php.cgi
AddHandler php-script .php

Now you will see that URL is rewritten

http;//test.com/application/test.htm

into:

Note: Ensure that you perform permission checks on the application/directory in the process.

This gives you the added benefit of making the URL a little shorter. Lastly, change your doc_root and user_dir options in the php.ini appropriately.

SUMMARY:

Here we have discussed the issues on how best the user can secure PHP installation considering both cases and I hope this will be helpful to all those who are keen in securing PHP and thus eliminating the many of the security risks involved.