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 had serious problems, not to mention scripts written by gangsters like me. So now we assume that serious problems have occurred in php scripts. For example, a while ago, phpnuke had a big problem with being able to upload php scripts. How can we configure the server to prevent the script from breaking through the system if such problems occur?
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 other execution functions such as: exec(), system(), passthru(), popen() will be restricted to only execute files in the directory specified by safe_mode_exec_dir. program. 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 Fetching files other than /usr/local/apache/htdocs will not be allowed. If the error message is displayed,
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 can be used free of charge by just registering at [url]http://www.zend.com[/url] ].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 [url]http://www.PHPease.com[/url] designed by Ma Yong... Mi Jiantao's Kangmo胗?/a > [url]http://www.zend.com[/url] Contact us 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 have 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 the file reading function under safe_mode is restricted to the fact that the owner of the read file must be the same as the owner of the currently executing script before it can be read, otherwise if an error message is displayed, Errors 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
In 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.