For the security configuration in Nginx/php-fpm/apache mod_php, refer to one of my previous articles:
"Correct setting Nginx/php-fpm/apache improve website security prevent being hanged Trojan"
http://zhangxugg-163-com.iteye.com/blog/1171572
First, basic knowledge preparation
Before any configuration starts, be sure to understand these concepts, and if these concepts are not thoroughly understood, it is impossible to comprehend the meaning of subsequent configurations, and experienced system administrators can skip them.
1. What is the site file owner account and what are the file permissions?
2.nginx, PHP-FPM, what account does Apache use to run?
3. What directories and documents on the website are writable? Here is the writable, refers to Nginx? PHP-FPM? or Apache?
4. How do I prohibit PHP code from being executed?
Linux has the most basic permissions are: The owner of the file, all the files they belong to have any permissions (unlimited root permissions), read and write execution permissions are identified as 4 2 1
What I see most is that some system administrators for the sake of convenience, let Php-fpm/apache to the site file owner, so that the PHP program to generate files in any location, but this configuration can cause serious security problems.
Reply to the above questions:
1. In the Linux directory, use the LS-L command to view the current directory owner, section 3, 4 columns of the user/group to which the files belong, shown, this is the list of files in the protected directory of the YII framework
As we can see, the file owners and groups are FTP, and the runtime directory permissions are for anyone who has read and write execution permissions.
2. The site, often need to write directory for the runtime to generate files (cache, static files, attachments upload, etc.), so this can be written for the PHP program itself, NGINX+PHP-FPM mode, Nginx is only responsible for forwarding the request to the PHP-FPM process, So the final generated file is generated by PHP-FPM. But Apache mod_php is different, mod_php as a module of Apache, its permissions inherit from Apache, it is said to be Apache writable directory, is not wrong.
You can use the command PS aux | Egrep ' nginx|php-fpm|apache ' view Nginx/php-fpm/apache run account
3. Communicate with developers about the writable directory and its significance
4. If PHP code is forbidden to be executed? may be due to program code vulnerability, Trojan files are uploaded to the attachment directory, you may think that in Linux to remove the permissions to execute this directory is OK?
chmod A-x-R uploadfile
However, this causes Apache to not be able to read the files in this directory, causing the attachment file to be inaccessible. On the other hand, this approach is also wrong. Even if the attachment file itself is removed from the execution of the permissions (the ordinary file itself, there is no execution permissions), it is not feasible, you should first understand the operation mechanism of PHP.
There are several common ways to run PHP:
A. Run in a nginx+php-fpm way
B. Run in Apache mod_php mode
C. command line, run using PHP mode
D. In the first line of the PHP script, add: #!/usr/local/php/bin/php, and add execute permission to this file, you can think of it as a shell script to run. This kind of file is not common.
In these ways, only the last way to execute permissions, in other ways, only in the PHP interpreter process to the PHP script has Read permission to run. For information on how to disable the execution of PHP scripts, refer to the author's above article.
Second, Safa_mode
PHP's security model is controversial because it involves system configuration, and it is using Windows configuration ideas that are not suitable for Linux environments. Simply put, when Safe_mode is turned on, the PHP process itself allows only open script files that belong to it. In other words, in a multi-site environment, we must establish a user for each site, and let the PHP process run with the corresponding account permissions, so that it can have the highest permissions on its own site files, but for other users of the file, there is no permissions. Sounds good, but in fact the amount of work that is configured is quite tedious and error-prone:
1. If a lot of sites, need to establish a large number of accounts, the site directory will be authorized to these users
2.PHP-FPM need to establish a large number of process pools, and specify different account identities, resulting in a huge waste of resources
3.APACHCE cannot configure multiple running accounts, only one can be specified.
4. Shared directories (such as/tmp,/DEV/SHM, etc. need to be specified separately), is not an easy task.
Visible, because the Safe_mode configuration is so cumbersome, the new version of PHP will be canceled safe_mode support, the PHP manual has been described very clearly:
5. If the site is to be migrated to another machine, the user account needs to be fully migrated, which is also a tedious effort.
Safe mode is obsolete from PHP 5.3.0 and will be removed from PHP 5.4.0.
Therefore, relying on safe mode, in the new version of PHP will not be supported, the author wrote this article, PHP 7.0.2 has been released.
Third, why to use Open_basedir
Open_basedir is used to limit the directory prefixes that PHP processes can open, and in general, PHP programs often use the/TMP/DEV/SHM directory in addition to reading the files on this site.
Assuming that the site is in/data/wwwroot/site.cn, use the/tmp,/DEV/SHM,/proc directory at run time, you can set this in php.ini
Open_basedir =/data/wwwroot/site.cn:/tmp:/dev/shm:/proc
If PHP uses include, require, fopen, gzopen and other functions to load other directory files, you will get an error:
Require_once (): Open_basedir restriction in effect. File (file.php) is not within the allowed path (s): (path)
Warning:require_once (file.php): Failed to open stream:operation not permitted in
Fatal error:require_once (): Failed opening required ...
This parameter can only be configured in php.ini when PHP 5.2.3, and cannot be configured at run time. PHP 5.2.3 can be set at any location.
Obviously, for a host with a large number of sites, using multiple php.ini, it is very difficult to configure. There are two ways of doing this:
1. In the php-fpm.conf configuration file, specify a different qualified directory for each process pool
[WWW]
Php_admin_value[open_basedir] =/var/www/www.example.com:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin
Php_admin_value refers to this value once set and cannot be modified at run time. But this method, but is not recommended, because each site needs to establish a process pool, there are 100 sites, you need to establish 100 process pools, and these PHP processes, can not use each other, only the site alone, resulting in a huge waste of resources.
2.nginx through the FASTCGI protocol and PHP-FPM Communication, you can specify a number of parameters to modify the PHP configuration parameters before the request begins, which is the most convenient and effective way to force the recommendation
Fastcgi_param php_admin_value "open_basedir= $document _root/:/tmp/:/proc/:/dev/shm";
This is a unique feature of PHP-FPM, which means that from the FASTCGI client can receive some parameters specified
Thanks to the introduction of the $document_root variable, we can configure it directly in bulk.
As a result, all sites can share the same process pool while addressing the problem of restricting access to the directory individually. We can add this command to the Nginx fastcgi_params configuration file, so that all sites take effect immediately and solve the problem
You can test it with the following PHP code
echo ini_get (' Open_basedir ');
Ini_set (' Open_basedir ', '/etc/');
echo ini_get (' Open_basedir ');
Visible is set to the desired limit and cannot be modified at run time. With this extrapolate, we can specify the various configurations of PHP in Nginx as needed.