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

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

Disadvantages

1. DSO is not supported on all platforms.
2. Startup of the server is 20% slower due to symbol resolving.
3. 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.
4. DSO can produce a slightly slower server depending on platform and address resolutioning.
5. 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.
6. 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

1. 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

2. 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.
3. 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.

     http://yoursite/test.php#test.cgi

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_exec_dir

Open_basedir

Max_execution_time

Memory_limit

Upload_tmp_dir

We will discuss both cases here.

PHP AS AN APACHE MODULE:

1. gunzip apache_xxx.tar.gz
2. tar -xvf apache_xxx.tar
3. gunzip php-xxx.tar.gz
4. tar -xvf php-xxx.tar
5. cd apache_xxx
6. ./configure --prefix=/www --enable-module=so
7. make
8. make install
9. cd ../php-xxx
10. ./configure --with-mysql --with-apxs=/www/bin/apxs
11. make
12. 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.

13. 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.

14. 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:

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.

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:

1. Extract the package

   # tar zxvf php-x.x.x.tar.gz Where x.x.x. is the version number.

2. Change to the PHP directory

   # cd php-x.x.x

3. 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:

Now you will see that URL is rewritten

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:

Article By:

Only registered users can write comments.
Please login or register.

Powered by AkoComment!