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

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

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

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?

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.

Website server software/configuration/php programs have vulnerabilities and are exploited. Before discussing this issue, describe the concepts of file and process permissions:

If an FTP user has the maximum modification permission on the website directory, the file owner of the website must belong to FTP, which is beyond doubt. Otherwise, how can I modify the file?

The php-fpm process and Nginx process require 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.
• If the php program requires write permission on some files on the website, you must manually change the file or directory permission to 777.
• Because the php-fpm sub-process is running in nobody, the new file owner generated by php-fpm is also nobody. In this case, the ftp user cannot modify these files, and the bell handler is required to unrebind the files, 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.
• Developers often ask me to reset the permissions on files generated by php.
• 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:

Www

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 (typically located at/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. Static files generate directories. All files in these directories should be regarded as static files.
4. Log directory, which is usually rejected by users.

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?

Data cache directory/cache/, which requires 777 permissions and does not need to be provided for user access, you can configure nginx according to the following reference

location ~ “^/cache” {return 403;}location ~ “.php$” {fastcgi_pass 127.0.0.0:9000;………………..}

At this time, no user can access the/cache/directory content.

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 127.0.0.0: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.

Static file generation directory public

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.