"Go" correctly set PHP-FPM child process user, improve website security anti-hanging horse

Original address: http://www.myhack58.com/Article/60/61/2013/37209.htm

According to the production environment constantly feedback, found that there are constantly PHP website is hanging Trojan, most of the reason is due to unreasonable permissions settings. Because the server software, or PHP programs in the presence of loopholes are unavoidable, in this case, if you can correctly set the Linux Site Directory permissions, PHP process permissions, then the security of the site can actually be guaranteed.

So, what causes the website to be hanged Trojan?

FTP connection information is cracked, for this reason, the possible way is to use a very complex FTP user name (do not use the common user name), if it is a fixed job, you can consider using the Iptables firewall to restrict the source IP.　However, in some scenarios, you may need to use a VPN for remote maintenance. That is, the site maintainer needs to use FTP to modify the Web site files, you must first log in to the IDC room VPN server, and then do the subsequent operations.

The Web server Software/configuration/php program has a vulnerability and is exploited to describe several concepts of file and process permissions before discussing this issue:

FTP user to the Site directory has the most modify permissions, then the site's file owner must belong to FTP, this is no doubt, otherwise how to modify the file?

PHP-FPM process, the Nginx process must have at least Read permission to the Web site file, for example, the following command to view the accounts used by the two processes:

Through, we can find that Nginx and PHP-FPM sub-process account is nobody.

We then check the permissions of the Web site file directory:

Find website file owner is www account, that means:

• Nginx and PHP have only read access to the Web site, no write permission
• if the PHP program requires write access to certain files on the site, you need to manually modify the file or directory permissions to 777
• because the PHP-FPM child process is run as nobody , then the PHP-FPM generated by the new file owner is also nobody, then the FTP user will not be able to modify these files, the call to ring people, when PHP generated files, need to invoke chmod ("/somedir/somefile", 0777) to modify the file permissions to 777 So that the FTP user can also modify the file.
• There are often developers who ask me for permission to reset PHP-generated files.
• If the PHP-FPM child process runs as a Web site file owner user, it means that the PHP-FPM process has writable permissions to the entire site directory, and the nightmare begins.

But we found that there are a lot of system administrators in order to save trouble, violating the principle of Linux minimize permissions, set the PHP-FPM process to run as a website file owner account, of course, this may be convenient for PHP developers (PHP-FPM process for the entire site directory has writable permissions), but this way, The Linux system's file system privilege principle will be broken, and all security measures will be in the form of a dummy. As you can imagine, if there is a loophole in the PHP program, the attacker can upload a Trojan horse, it will be able to modify all the files on the site, the homepage is black, it is not surprising.

Step back, if we set stricter permissions, even if there is a bug in the PHP program, then the attacker can only tamper with the permissions of 777 of the directory, the other files can not be rewritten, the site is more secure?

Core Summary: The user that the PHP-FPM child process uses cannot be the site file owner. Any violation of this principle does not conform to the principle of least privilege.

After I see online about Nginx, PHP-FPM configuration of the article tutorial and some books on the market, found that many people are misled by these articles, directly let the PHP-FPM sub-process to run as a website owner account, such as Zhang Yi "real Nginx to replace Apache's high-performance Web server" 52 pages of a book, the following settings exist:

www www

In the official provisioning profile, the PHP-FPM child process uses the nobody user, which is entirely reasonable and does not need to be modified.

So nginx child process user, how to set reasonable? My advice is also to use nobody (no impact on error log writes, etc.), set the method as follows:

The first line of the nginx.conf file is set to user nobody; , and then execute nginx-s reload.

PHP-FPM Child Process User Setting method:

Edit the file php-fpm.conf (typically located in/usr/local/php/etc/php-fpm.conf depending on the installation parameters), find the user, group two parameters defined, set it to nobody (default is already nobody), and then restart PHP-FPM process can be.

Special attention to the website's writable catalogue

Here the writable, is relative to the PHP-FPM sub-process. A Web site is the most vulnerable to the security problem is the writable directory, if the writable directory permissions can be controlled strictly, the safety factor will be greatly improved. We believe that a Web site writable directory is divided into the following categories:

1. the PHP data cache directory, such as the Forumdata directory of Discuz, stores a large number of data cache files. Such directories will generally prohibit users from direct access, but discuz in this directory and stored a lot of JS, CSS files, we can not simply deny users access to this directory. Obviously, all the files in this directory cannot be given directly to PHP, and we'll give you a solution later. The
2. attachment uploads the directory. It is clear that such directories require access but cannot be parsed by the PHP engine (that is, all files in this directory are treated as normal static files). The
3. static file generates the directory, and the files in such directories should all be treated as static files. The
4. log directory generally denies direct access to the user.

That is to say, for Web site developers, the need for writable directory to achieve static and dynamic separation, different performance of the file, should be treated differently, so it is convenient for system administrators, set reasonable nginx rules to improve security.

Simply removing the php file execution permission does not prevent the PHP-FPM process from parsing.

Next, based on the above summary, how can the system administrator configure Nginx directory rules to be more secure?

Data cache directory/cache/, this directory is characterized by the need for 777 of permissions, no need to provide users access, then you can configure Nginx as the following reference

Location ~ "^/cache" {return 403;} Location ~ ". php$" {Fastcgi_pass 127.0.0.0:9000;.........}

At this point, any user will not be able to access the/cache/directory contents.

Attachment Upload Directory Attachments

This directory is characterized by the need for open access, but all files cannot be parsed by the PHP engine (including the suffix name to gif trojan file)

Location ~ "^/attachments" {}location ~ ". php$" {Fastcgi_pass 127.0.0.0:9000; ..........}

> Note that there is no statement in the location definition for the attachments directory above. Nginx has the highest priority for the location matching of regular expressions, and any location defined with a regular expression, once matched, will no longer match the location defined by other regular expressions.

Now, please create a PHP script file in the attachments directory, and then visit Ann through the browser, we found that the browser prompts to download, which indicates that Nginx attachments directory files as a static file processing, and did not give PHP fastcgi processing. So even if the writable directory is planted Trojan, but because it can not be executed, the site is more secure.

Obviously, important PHP configuration files should not be placed under this category.

Static file generation directory public

These directories are usually saved directories of the static pages generated by PHP, apparently similar to the attachments directory, by the permissions set in the attachment directory. It can be foreseen that if we set stricter permissions, even if the website PHP program has a loophole, Trojan script can only be written to the permissions of 777 of the directory to go, if combined with the above strict directory permissions control, Trojan can not be triggered to run, the overall system security will obviously be significantly improved.

But the site can write the role of directory and permissions, only developers are most clear. This requires active communication between PHP developers and system administrators. The way we use it is: Before the project goes live, the developer provides the role and permissions of the Web site writable directory as a document, and the system administrator sets the permissions for the different directories. Either party modifies the site Directory permissions, but does not reflect the documentation, which we consider to be a violation of the work flow.

"Go" correctly set PHP-FPM child process user, improve website security anti-hanging horse