Configure some server-side features of PHP to enhance PHP security

Shaun Clowes and rfp have previously introduced in detail the problems encountered by PHP and CGI programs during the programming process, and how to break through the system through application vulnerabilities. In this article, we will go through some of PHP's
server-side features To configure and enhance the security of php. When writing cgi scripts, we must pay attention to various security issues and strictly filter user input. However, how can we often walk on the shore without getting our shoes wet, and how can we eat sesame seeds without dropping sesame seeds? , even the famous phpnuke, phpMyAdmin and other programs have experienced serious problems problem, not to mention scripts written by gangsters like me. So now we assume that the php script has serious problems, such as a while ago There is a big problem with phpnuke being able to upload php scripts. How can we configure the server to prevent the script from breaking through the system if there is such a problem?

1. Pay attention to patching known vulnerabilities when compiling

Starting from 4.0.5, PHP’s mail function has added a fifth parameter, but it is not filtered properly, allowing PHP applications to break through the safe_mode restrictions. Excuting an order. So when using 4.0.5 and 4.0.6
Before compilation, we need to modify the ext/standard/mail.c file in the php source code package to disable the fifth parameter of the mail function or filter shell characters. In line 152 of the mail.c file, which is the following line:
if (extra_cmd != NULL) {
Add extra_cmd=NULL after
; or extra_cmd = php_escape_shell_cmd(extra_cmd);
Then compile php, then we will patch it found this vulnerability.

2. Modify the php.ini configuration file

Make modifications based on the php.ini-dist of the php distribution version.
1)Error handling and logging
You can make some settings in the Error handling and logging section. First find:
display_errors = On
php turns on the error message display by default, we change it to:
display_errors = Off

After turning off the error display, the php function execution error message will no longer be displayed to the user, so To a certain extent, it can prevent attackers from learning the physical location of the script and some other useful information from the error message, which at least creates certain obstacles for the attacker's black box detection. These error messages may be useful to ourselves. We can let it be written to the specified file, then modify the following:
log_errors = Off
Change to:
log_errors = On

And specify the file, find the following line:
;error_log = filename
Remove the previous; comment and change filename to the specified file, such as
/usr/local/apache/logs/php_error.log

error_log = /usr/local/apache/logs/php_error.log
All errors will appear like this Will be written to the php_error.log file.

2)Safe Mode

php’s safe_mode function limits or disables many functions, which can solve php’s security issues to a great extent. Find in the Safe Mode section:
safe_mode = Off
Change to:
safe_mode = On

This turns on the safe_mode function. Some functions like shell_exec() and `` that can execute system commands are prohibited, and some other execution functions such as: exec(), system(), passthru(), popen() will be restricted to executing programs in the directory specified by safe_mode_exec_dir. If you really want to execute some commands or programs, find the following:
safe_mode_exec_dir =
Specify the path of the program to be executed, such as:
safe_mode_exec_dir = /usr/local/php/exec

Then copy the program you want to use to/ usr/local/php/exec directory, so that restricted functions like the above can also execute programs in this directory.

For detailed information about restricted functions in safe mode, please see the instructions on the main php website:
[url]http://www.php.net/manual/en/features.safe-mode.php[/url]

3)disable_functions

If you are not clear about the harmfulness of some functions and do not use them, simply disable these functions. Find the following line:
disable_functions =
Add the functions to be disabled after "=", and separate multiple functions with ",".

3. Modify httpd.conf

If you only allow your php script program to operate in the web directory, you can also modify the httpd.conf file to limit the operation path of php. For example, if your web directory is /usr/local/apache/htdocs, then add these lines to
httpd.conf:


php_admin_value open_basedir /usr/local/apache /htdocs

In this way, if the script wants to read files other than /usr/local/apache/htdocs, it will not be allowed. If the error message is opened,

will prompt an error like this:
Warning: open_basedir restriction in effect. File is in wrong directory in /usr/local/apache/htdocs/open.php on line 4 and so on.

4. Compile the php code

Zend has made a great contribution to PHP. The PHP4 engine uses Zend, and it has also developed many PHP enhancement components such as ZendOptimizer and ZendEncode. The optimizer ZendOptimizer only needs to be registered at [url]http://www.zend.com[/url] to be free?...

ZendOptimizer-1[1].1.0-PHP_4.0.5-FreeBSD4.0-i386.tar.gz
ZendOptimizer-1[1].1.0-PHP_4.0.5 -Linux_glibc21-i386.tar.gz
ZendOptimizer-1[1].1.0-PHP_4.0.5-Solaris-sparc.tar.gz
ZendOptimizer-1[1].1.0-PHP_4.0.5-Windows-i386.zip


The installation of the optimizer is very convenient, and there are detailed instructions in the package. Taking the UNIX version as an example, check the operating system clearly and extract the ZendOptimizer.so file in the package to a directory, assuming it is /usr/local/lib. Add two sentences to php.ini:
zend_optimizer.optimization_level= 15
zend_extension="/usr/local/lib/ZendOptimizer.so"

That’s it. Use phpinfo() to see the following text on the left side of the Zend icon:
with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies

Then, the optimizer has been successfully attached.
But the compiler ZendEncode is not free. Here is a design by Ma Yong of [url]http://www.PHPease.com[/url] ... Mi Jiantao's Kangmo胗?/a> [url]http://www.zend.com[/url] Contact to obtain the license agreement.

After the PHP script is compiled, the execution speed of the script increases a lot. The script file can only see a bunch of garbled characters, which will prevent the attacker from further analyzing the script program on the server, and the password originally stored in clear text in the PHP script will also be lost. Got confidentiality, such as mysql password. However, it is more troublesome to change the script on the server side. It is better to change it locally and then upload it.


5. Permission settings for files and directories

Except for the upload directory, the permissions for other directories and files in the web directory must not allow the nobody user to write permissions. Otherwise, the attacker can modify the homepage file, so the permissions of the web directory must be set properly. Also, the owner of the php script must not be root, because files are read in safe_mode. The function is restricted so that the owner of the file being read must be the same as the owner of the currently executing script before it can be read. Otherwise, if the error display is turned on, an error such as the following will be displayed:

Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /etc/passwd owned by uid 0 in /usr/local/apache/htdocs/open.php on line 3
This way we can prevent many system files from being read, such as: /etc/passwd, etc.

The owners of the upload directory and the upload script must also be set to the same, otherwise errors will occur. Please pay attention to these in safe_mode.

6. Mysql startup permission settings


Mysql should be noted not to be started with root. It is best to create another mysqladm user. You can add a sentence to the system startup script such as /etc/rc.local:
su mysqladm -c "/usr/local/mysql/share/mysql/mysql.server start"

In this way, mysqladmin will be automatically used after the system restarts The user starts the mysql process.

7. Review of log files and upload directories and

Viewing logs has a lot to do with human laziness. Finding traces of attacks from such a large log file is like looking for a needle in a haystack, and there may not be one. The files in the directory uploaded by the web should also be checked frequently. There may be a problem with the program and the user has uploaded some illegal files, such as executing scripts.

8. Patches of the operating system itself

Same, patching known vulnerabilities in the system is the most basic responsibility of the system administrator, and it is also the last line of defense.


After the above configuration, although it cannot be said to be impregnable, it has also caused a lot of trouble for the attacker's testing to a certain extent. Even if there are serious vulnerabilities in the php script program, the attacker will not be able to cause actual damage.