正确设置nginx/php-fpm/apache权限 提高网站安全性 防止被挂木马
2019獨角獸企業重金招聘Python工程師標準>>>
核心總結：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 對網站只有讀取權限，無寫入權限
l? 如果php 程序需要對網站某些文件有寫入權限，需要手工將文件或目錄權限修改為 777
l? 因為php-fpm 子進程是以 nobody 運行，那么 php-fpm 生成的新文件所有者也是 nobody,? 這時 ftp 用戶將無法修改這些文件，解鈴還需系鈴人，當 php 生成文件后，需要調用 chmod("/somedir/somefile",?0777) 將文件權限修改為 777 ，以便 FTP 用戶也可以修改這個文件。
l? 經常有開發人員找我請求重設php 生成的文件的權限。
?
l? 如果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 開發人員和系統管理員積極溝通。我們使用的方式是：項目上線前，開發人員根據以文檔形式提供網站可寫目錄的作用及權限，由系統管理員針對不同目錄進行權限設置。任何一方修改了網站目錄權限，但未體現到文檔中，我們認為是違反工作流程的。
轉載于:https://my.oschina.net/u/588516/blog/621592
總結
以上是生活随笔為你收集整理的正确设置nginx/php-fpm/apache权限 提高网站安全性 防止被挂木马的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【转】测试思考——测试人员需要具备哪些素
- 下一篇： 基于SharePoint 2013的论坛