Correctly set website file owner to prevent php website Trojans

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.

Core Summary: users used by php-fpm/apache processes cannot be website File owners. 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. Because of the server software or php
Vulnerabilities in the program are inevitable. in this case, if you can correctly set the Linux website directory and php process permissions, the website security can be guaranteed.

So,What is the cause 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, consider using
The iptables firewall limits the source IP address. However, in some scenarios, VPN may be required for remote maintenance. That is, the website maintainer needs to use FTP
When modifying the website file, you must log on to the VPN server of the IDC data center before performing 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. The php-fpm/apache/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.

◆ 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
The user will not be able to modify these files, and the contact person will be required to unbind them. after the php generates the file, you need to call chmod ("/somedir/somefile", 0777) to change the file permission
777, so that FTP users can modify the file.

◆ Developers often ask me to reset the permissions on files generated by php.

◆ If the php-fpm/apache/nginx process runs as the website file owner user, it means php-fpm/apache/nginx
The process has the write permission on the entire website directory, which begins with a nightmare.

However, we found that many system administrators set the php-fpm/apache/nginx
The process runs with the account of the website file owner. of course, this may be convenient for php developers (the php-fpm process has writable permissions for the entire website directory ).
The file system permission principle of the system will be broken, and all security measures will be ineffective. As you can imagine, in case of php
The program has vulnerabilities. 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 permission to 777.
Other files cannot be rewritten. isn't the website more secure?

Core Summary: users used by php-fpm/apache/nginx processes cannot be website File owners. 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 that many people were misled by these articles and directly asked
The php-fpm/apache/nginx process runs with the account of the website owner. for example, 52 in Zhang Yan's book "replacing apache with nginx with high-performance Web servers"
Page, the following settings exist:

 
 

  
  
  www  
  
  
  www  
 
 

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/usr/local/php/etc/php-fpm.conf, depending on the installation parameters), find the user,
Set the group parameter to "nobody" by default, and 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 is generally disabled for direct access, but discuz
Many js and css files are stored in this directory. we cannot simply reject users from accessing this directory. Obviously, all files in this directory cannot be directly handed over to php
Resolution, 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 needs to be implemented for writable directories. files with different performance should be treated differently, so that the system administrator can easily set up a 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 summary above,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 127.0.0.0: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 127.0.0.0:9000; 
  
  
.................... 
  
  
} 
  
  
 
 
 

Note that there are no statements in the location definition of the attachments directory. Location of the regular expression in nginx
The match has the highest priority. 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 then access security through the browser. we find that the browser prompts you to download the file.
The files in the attachments directory are treated as static files and are not handed over to php fastcgi.
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 php program has vulnerabilities, Trojan scripts can only be written to 777
If you use the strict directory permission control, the Trojan 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. This requires php
Developers and system administrators actively communicate with each other. 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.