Correctly set the php-fpm sub-process to improve website security and prevent Trojans

Source: Internet
Author: User
Tags ftp connection website server

Core Summary: The user used by the php-fpm sub-process cannot be the website file owner. Any violation of this principle does not comply with the minimum permission principle.

According to continuous feedback in the production environment, php websites are found to be infected with Trojans, most of which are caused by improper permission settings. It is inevitable that vulnerabilities exist in server software or php programs. In this case, if you can correctly set the Linux website directory permission and php process permission, therefore, the security of the website can be guaranteed.

So what are the causes of website Trojans?

1. the ftp connection information is cracked. the feasible method for this reason is to use a very complex FTP User Name (do not use a common user name). If it is a fixed job, you can use iptables firewall to restrict source IP addresses. However, in some scenarios, VPN may be required for remote maintenance. That is to say, when the website maintainer needs to use FTP to modify the website file, he must first log on to the VPN Server of the IDC data center and then perform subsequent operations.

2. vulnerabilities in website server software/configuration/php programs are exploited.
Before discussing this issue, describe the concepts of file and process permissions:
A. If an FTP user has the maximum permission to modify the website directory, the file owner of the website must belong to FTP. This is beyond doubt. Otherwise, how can I modify the file?
B. For the php-fpm process, the nginx process requires at least the permission to read the website files. For example, run the following command to view the accounts used by the two processes:

We can find that the nginx and php-fpm sub-process accounts are nobody.

Then we can view the website file directory permissions:

If you find that the website file owner is a www account, the description is as follows:
| Nginx and php have only the read permission and no write permission on the website.
L if the php program requires write permission on some files on the website, you need to manually change the file or directory permission to 777
L because the php-fpm sub-process is running in nobody, the new file owner generated by php-fpm is also nobody. In this case, ftp users will not be able to modify these files, and you need to ring the bell for unling, after php generates a file, it needs to call chmod ("/somedir/somefile", 0777) to change the File Permission to 777, so that FTP users can also modify the file.
L developers often ask me to reset the permissions on the files generated by php.

L if the php-fpm sub-process runs as the user of the website file owner, it means that the php-fpm process has writable permissions on the entire website directory. This is the nightmare.

However, we found that many system administrators set the php-fpm process to run with the account of the website file owner in order to save trouble and violate the principle of minimizing Linux permissions, of course, this may make it easier for php developers (the php-fpm process has writable permissions on the entire website directory). However, in this way, the file system permission principle of the Linux system will be broken, all security measures will be ineffective. As you can imagine, in case of a vulnerability in the php program, attackers can upload Trojans to modify all the files on the website, and the homepage is hacked.

Step back, if we set strict permissions, even if there is a vulnerability in the php program, attackers can only tamper with the directory with the permission of 777, and other files cannot be rewritten, isn't the website more secure?

Core Summary: The user used by the php-fpm sub-process cannot be the website file owner. Any violation of this principle does not comply with the minimum permission principle.

After reading articles and tutorials on nginx, php-fpm configuration, and some books on the market, I found many people were misled by these articles, directly run the php-fpm sub-process with the account of the website owner. For example, the following settings exist in the 52 pages of Zhang banquet's book "replacing apache with nginx with high-performance Web servers:

On the seventh page, set the website file owner to a www User:
Chown-R www: www/data0/htdocs/blog
Obviously, this Part of this book is misleading to beginners. To address this issue, I have sent an email to the author, hoping that it will emphasize the statement in the second edition, to avoid some security risks caused by excessive loose permission configuration.

In the official configuration file, the php-fpm sub-process uses the nobody user, which is completely reasonable and does not need to be modified.

In this case, how do I set nginx sub-process users reasonably? I recommend that you use nobody (which has no impact on writing error logs) as follows:
Set the first line of the nginx. conf file to user nobody, and then run nginx-s reload.

Php-fpm sub-process user setting method:
Edit the file php-fpm.conf (usually located in the/usr/local/php/etc/php-fpm.conf, depending on the installation parameters), find the definitions of the user, group parameters, set it to nobody (the default value is already nobody), and then restart the php-fpm process.

Special notes on website Writable Directories
The writeable here is relative to the php-fpm sub-process. The easiest security problem for a website is the writable directory. If the permission for the writable directory is strictly controlled, the security factor will be greatly improved.
We believe that a website can be written into the following directories:
1. the php data cache directory, such as the discuz forumdata directory, stores a large number of data cache files. This type of directory generally prohibits direct access by users, but discuz stores many js and css files in this directory, so we cannot simply deny access to this directory. Obviously, all files in this directory cannot be directly handed over to php for parsing. We will provide a solution later.
2. Attachment upload directory. Obviously, access to these directories must be enabled, but cannot be parsed by the php engine (that is, all files in this directory are considered normal static files ).
3. Directory generated by static files. All files under such directories should be regarded as static files.
4. Log directories usually reject direct access.

That is to say, for website developers, static and static separation should be implemented for Writable Directories. Files with different performance should be treated differently, so that the system administrator can easily set reasonable nginx rules, to improve security.

Simply removing the execution permission of the php file does not prevent the php-fpm process from parsing.

Next, based on the above summary, how does the system administrator configure nginx directory rules to ensure better security?
1. data cache directory/cache/
This directory requires 777 permissions and does not need to be provided for user access. You can configure nginx as follows:
Location ~ "^/Cache "{
Return 403;

Location ~ ". Php $ "{
Fastcgi_pass 9000;

At this time, no user can access the/cache/directory content, even if
2. attachments
This directory requires open access, but all files cannot be parsed by the php engine (including trojan files whose suffix is changed to gif)
Location ~ "^/Attachments "{


Location ~ ". Php $ "{
Fastcgi_pass 9000;

Note that there are no statements in the location definition of the attachments directory. Nginx has the highest priority in matching the location of a regular expression. Any location defined by a regular expression will no longer match the location defined by other regular expressions once it is matched.

Now, create a php script file in the attachments directory and access the file security in the browser. We find that the browser prompts you to download the file. This indicates that nginx treats the file in the attachments directory as a static file, php fastcgi is not handed over for processing. In this way, even if the writable directory is implanted with a Trojan, the website is safer because it cannot be executed.

Obviously, do not place important php configuration files in this directory.

3. public directory for generating static files
These directories are generally saved directories of static pages generated by php. Obviously, they are similar to the attachment directory. You can set them according to the permission of the attachment directory.
It is foreseeable that if we set strict permissions, even if the website's php program has vulnerabilities, Trojan scripts can only be written to a directory with a permission of 777, with the strict directory permission control, Trojans cannot be triggered, and the security of the entire system is obviously improved.

However, developers are the only one who knows the role and permissions of the website's writable directory. In this regard, php developers need to actively communicate with the system administrator. Before a project is launched, developers can provide the function and permissions of website writable directories in the form of documents. The system administrator can set permissions for different directories. If either party modifies the website directory permission but is not reflected in the document, we believe it is against the workflow.
Original article:

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.