核心總結：php-fpm/apache 進程所使用的用戶，不能是網站文件所有者。 凡是違背這個原則，則不符合最小權限原則。

根據生產環境不斷反饋，發現不斷有 php網站被掛木馬，絕大部分原因是因為權限設置不合理造成。因為服務器軟件，或是 php 程序中存在漏洞都是難免的，在這種情況下，如果能正確設置 Linux 網站目錄權限， php 進程權限，那么網站的安全性實際上是可以得到保障的。

那么，造成網站被掛木馬的原因是什么？

1. 　ftp 連接信息被破解，對這個原因，可行的辦法就是使用非常復雜的FTP 用戶名（不要使用常用的用戶名），如果是固定作業，可考慮使用 iptables 防火墻限制來源 IP 。但是一些情景下，可能需要使用 VPN 以便遠程維護。　即網站維護者需要使用 FTP 修改網站文件時，必須先登錄到IDC機房的VPN 服務器上，再進行后續的操作。

2. 　網站服務器軟件/ 配置 /php 程序存在漏洞，被利用。

在討論這個問題前，先說明文件及進程權限的幾個概念:

A.  FTP用戶對網站目錄具有最大修改權限，那么網站的文件所有者一定屬于 FTP, 　這是毋庸置疑的 ,  否則如何修改文件呢？

B.  php-fpm/apache/nginx 進程對網站文件至少需要有讀取權限，例如，以下命令即可查看這兩個進程所使用的賬號：

通過上圖，我們可以發現，nginx 和 php-fpm 子進程賬號是 nobody 。

我們再查看網站文件目錄的權限：

發現網站文件所有者是www 賬號，那說明：

◆ nginx和 php 對網站只有讀取權限，無寫入權限

◆ 如果php 程序需要對網站某些文件有寫入權限，需要手工將文件或目錄權限修改為 777

◆ 因為php-fpm 子進程是以 nobody 運行，那么 php-fpm 生成的新文件所有者也是 nobody,  這時 ftp 用戶將無法修改這些文件，解鈴還需系鈴人，當 php 生成文件后，需要調用 chmod("/somedir/somefile", 0777) 將文件權限修改為 777 ，以便 FTP 用戶也可以修改這個文件。

◆ 經常有開發人員找我請求重設php 生成的文件的權限。

◆ 如果php-fpm/apache/nginx進程以網站文件所有者用戶運行，那意味著 php-fpm/apache/nginx 進程對整個網站目錄具有可寫權限，噩夢也就由此開始。

但是我們發現，有不少系統管理員為了省事，違背了Linux 最小化權限的原則，設置 php-fpm/apache/nginx 進程以網站文件所有者賬號運行，當然這樣可能會方便 php 開發人員（ php-fpm 進程對整個網站目錄具有可寫權限），但是這樣一來， Linux 體系的文件系統權限原則將被打破，所有的安全措施將形同虛設。可以想象的是，萬一 php 程序中有漏洞，攻擊者上傳木馬，便可以修改網站的所有文件，網站首頁被黑，也就不足為怪了。

退一步，如果我們設置了較嚴格的權限，就算php 程序中存在漏洞，那么攻擊者也只能篡改權限為 777 的目錄，其它的文件是無法被改寫的，網站不就就得更安全了嗎？

核心總結：php-fpm/apache/nginx進程所使用的用戶，不能是網站文件所有者。 凡是違背這個原則，則不符合最小權限原則。

經過我參閱網上關于nginx, php-fpm 配置的文章教程和市面上的一些書籍，發現有不少人受這些文章的誤導，直接讓 php-fpm/apache/nginx進程以網站所有者賬號運行，例如張宴的《實戰 nginx  取代 apache 的高性能 Web 服務器》一書的 52 頁中，存在以下設置：

<value name="user">www</value>  
<value name="group">www</value>  

而在第50 頁，設置網站文件所有者也為 www 用戶：

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

顯然，此書的這部分內部，對初學者有誤導，針對這個問題，我已經向本書作者發郵件，希望其能在第二版中進行強調聲明，以免由于過度寬松的權限配置，造成一些安全隱患。

官方提供的配置文件中，php-fpm 子進程使用 nobody 用戶，這完全是合理的，無須修改。

那么nginx 的子進程用戶，如何設置合理？　我的建議是也使用 nobody （對錯誤日志寫入等無影響），設置方法如下：

nginx.conf文件第一行設置為 user 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

location ~ "^/cache" {  
return 403;  
}  
location ~ "\.php$" {  
fastcgi_pass 127.0.0.0:9000;  
....................  
}  
 

這時，任何用戶將無法訪問/cache/ 目錄內容，即使

2、附件上傳目錄  attachments

此目錄的特點是需要開放訪問權限，但所有文件不能由php 引擎解析（包括后綴名改為 gif 的木馬文件）

location ~ "^/attachments" {  
}  
location ~ "\.php$" {  
fastcgi_pass 127.0.0.0:9000;  
....................  
}  
 

注意，上面對attachments 目錄的 location 定義中是沒有任何語句的。 nginx 對正則表達式的 location 匹配優先級最高，任何一個用正則表達式定義的 location,  只要匹配一次，將不會再匹配其它正則表達式定義的 location 。

現在，請在attachments 目錄下建立一個 php 腳本文件，再通過瀏覽器訪問安，我們發現瀏覽器提示下載，這說明 nginx 把 attachments 目錄下的文件當成靜態文件處理，并沒有交給 php fastcgi 處理。這樣即使可寫目錄被植入木馬，但因為其無法被執行，網站也就更安全了。

顯然，重要的php 配置文件，請勿放在此類目錄下。

3、靜態文件生成目錄 public

這些目錄一般都是php 生成的靜態頁的保存目錄，顯然與附件目錄有類似之處，按附件目錄的權限設置即可。

可以預見的是，如果我們設置了較嚴格的權限，即使網站php 程序存在漏洞，木馬腳本也只能被寫入到權限為 777 的目錄中去，如果配合上述嚴格的目錄權限控制，木馬也無法被觸發運行，整個系統的安全性顯然會有顯著的提高。

但是網站可寫目錄的作用及權限，只有開發人員最為清楚。這方面需要php 開發人員和系統管理員積極溝通。我們使用的方式是：項目上線前，開發人員根據以文檔形式提供網站可寫目錄的作用及權限，由系統管理員針對不同目錄進行權限設置。任何一方修改了網站目錄權限，但未體現到文檔中，我們認為是違反工作流程的。