php禁止网页抓取(php-fpm子进程所使用的用户是什么？)

　　php禁止网页抓取(php-fpm子进程所使用的用户是什么？)

　　核心总结：php-fpm子进程使用的用户不能是网站文件的所有者。任何违反此原则的行为都不符合最小特权原则。

　　根据生产环境的不断反馈，发现php网站已经挂上了木马，大部分是权限设置不合理造成的。难免服务器软件或php程序存在漏洞。在这种情况下，如果Linux网站目录权限和php进程权限设置正确，那么网站的安全性其实是可以保证的。

　　那么，是什么原因导致木马被链接到网站？

　　1. ftp 连接信息被破解。为此，可行的方法是使用非常复杂的 FTP 用户名（不要使用常用的用户名）。如果是固定操作，可以考虑使用iptables防火墙来限制源IP。但是，在某些情况下，可能需要使用 VPN 进行远程维护。即当网站维护者需要使用FTP修改网站文件时，必须先登录IDC机房的VPN服务器，再进行后续操作。

　　2. 网站 服务器软件/配置/php程序存在漏洞被利用

　　在讨论这个问题之前，先解释一下文件和进程权限的几个概念：

　　A、FTP用户对网站目录有最大修改权限，所以网站的文件所有者必须属于FTP。这是毋庸置疑的，不然怎么修改文件呢？

　　B、php-fpm进程，nginx进程至少要有网站文件的读权限。比如下面的命令可以查看这两个进程使用的账号：

　　ps aux|grep nginx

　　ps aux|grep php

　　我们可以发现nginx和php-fpm的子进程账号是nobody。

　　让我们检查网站文件目录的权限：

　　发现文件网站的所有者是www帐号，即：

　　| nginx 和 php 对 网站 只有读访问权限，但没有写访问权限

　　l 如果php程序需要对网站的部分文件有写权限，需要手动修改文件或目录权限为777

　　l 因为php-fpm子进程以nobody运行，所以php-fpm生成的新文件的所有者也是nobody。这时候ftp用户是不能修改这些文件的，需要的人是需要解铃的人。php生成文件后，需要调用chmod("/somedir/somefile", 0777)修改文件权限为777，这样FTP用户也可以修改这个文件。

　　l 经常被开发者要求重置php生成的文件的权限。

　　l 如果php-fpm子进程以文件所有者网站的用户身份运行，说明php-fpm进程对整个网站目录具有可写权限，噩梦就开始了。

　　但是我们发现很多系统管理员为了省事，违反了最小化Linux权限的原则，将php-fpm进程设置为文件所有者的账户下运行。当然，这对于php开发者来说可能方便（php-fpm进程对整个网站目录都有可写权限），但是这样会破坏Linux系统的文件系统权限原则，所有安全措施将毫无用处。可以想象，如果PHP程序存在漏洞，攻击者可以通过上传木马来修改网站的所有文件，网站的首页被黑也就不足为奇了。

　　退一步说，如果我们设置更严格的权限，即使php程序存在漏洞，攻击者也只能篡改777权限的目录，其他文件无法改写。更安全吗？

　　核心总结：php-fpm子进程使用的用户不能是网站文件的所有者。任何违反此原则的行为都不符合最小特权原则。

　　看了网上关于nginx和php-fpm配置的文章教程和市面上的一些书籍，发现很多人被这些文章误导，直接让php-fpm子进程为网站所有者账号操作，例如张燕的《实用nginx替代apache的高性能web服务器》一书第52页，有如下设置：

　　万维网

　　万维网

　　在第 50 页，将 网站 文件的所有者设置为 www 用户：

　　chown -R www:www /data0/htdocs/blog

　　显然，本书的这一部分对初学者具有误导性。针对这个问题，我已经给本书作者发了邮件，希望他能在第二版中做一个重点说明，以免因为权限配置过于松散而造成一些问题。安全风险。

　　官方配置文件中php-fpm子进程使用nobody用户，完全合理，不需要修改。

　　那么如何合理设置nginx子进程的用户呢？我的建议是也用nobody（对错误日志写入等没有影响），设置方法如下：

　　将nginx.conf文件第一行设置为用户nobody;，然后执行nginx -s reload。

　　php-fpm子进程用户设置方法：

　　编辑php-fpm.conf文件（一般在/usr/local/php/etc/php-fpm.conf，根据安装参数），找到user和group两个参数的定义，设置为nobody （默认已经是nobody），然后重启php-fpm进程。

　　网站可写目录的特别说明

　　这里能写的都是相对于php-fpm子进程的。一个网站 最容易出现安全问题的是可写目录。如果能严格控制可写目录的权限，安全系数将大大提高。

　　我们认为一个网站可写目录主要分为以下几种：

　　1. php数据缓存目录，比如discuz的forumdata目录，存放着大量的数据缓存文件。这样的目录一般禁止用户直接访问，但是discuz在这个目录下存放了很多js和css文件。我们不能简单地拒绝用户访问此目录。显然，这个目录下的所有文件都不能直接交给php进行分析。我们稍后会给出解决方案。

　　2. 附件上传目录。很明显，这样的目录需要打开才能访问，但是php引擎无法解析（即把这个目录下的所有文件都当作普通的静态文件）。

　　3. 静态文件生成目录，该类中的所有文件都应视为静态文件。

　　4. 日志目录通常会拒绝用户直接访问它。

　　也就是说，对于网站的开发者来说，需要将可写目录的动态和静态分开。不同性能的文件要区别对待，方便系统管理员设置合理的nginx规则，提高安全性。

　　简单的去掉php文件的执行权限并不会阻止php-fpm进程解析它。

　　接下来，根据以上总结，系统管理员如何配置nginx目录规则更安全呢？

　　1. 数据缓存目录/cache/

　　这个目录的特点是需要777权限，不需要提供给用户访问，所以可以按照下面的参考配置nginx

　　位置~“^/缓存”{

　　返回403；

　　}

　　位置 ~ ”\.php$” {

　　fastcgi_pass 127.0.0.0:9000;

　　……………………

　　}

　　此时，任何用户都将无法访问 /cache/ 目录的内容，即使

　　2.附件上传目录附件

　　该目录的特点是需要开放访问权限，但所有文件都无法被php引擎解析（包括后缀为gif的木马文件）

　　位置~“^/附件”{

　　}

　　位置 ~ ”\.php$” {

　　fastcgi_pass 127.0.0.0:9000;

　　……………………

　　}

　　注意上面的附件目录的位置定义中没有声明。nginx 对正则表达式位置匹配的优先级最高。任何正则表达式定义的位置，只要匹配一次就不会匹配其他正则表达式定义的位置。

　　现在，请在附件目录中创建一个 php 脚本文件，然后通过浏览器访问安装程序。我们发现浏览器提示下载，这意味着nginx将attachments目录下的文件当做静态文件处理，并没有交给php fastcgi进行处理。这样，即使可写目录被植入木马，网站也更安全，因为它无法执行。

　　显然，重要的php配置文件不应该放在这样的目录中。

　　3. 静态文件生成目录 public

　　这些目录一般是php生成的静态页面的存放目录。显然，它们类似于附件目录。只需根据附件目录的权限设置它们。

　　可以预见，如果我们设置了严格的权限，即使网站php程序存在漏洞，木马脚本也只能写入权限为777的目录。如果配合上述的严格目录权限控制，木马无法触发运行，整个系统的安全性明显提升。

　　但是，只有开发者知道网站 可写目录的功能和权限。这方面需要php开发人员和系统管理员之间的积极沟通。我们采用的方法是：在项目上线前，开发者以文档的形式提供网站可写目录的角色和权限，系统管理员设置不同目录的权限。任何一方修改了网站的目录权限，但在文档中没有体现。我们认为这违反了工作流程