本文主要分為兩大部分，第一部分介紹了Nginx的一些常見安全漏洞的形成原因、利用方法，并給出了相應的解決辦法;第二部分介紹了Nginx安全加固時需要關注的主要內容。

Nginx(發音同engine x)是一款輕量級的Web服務器/反向代理服務器及電子郵件(IMAP/POP3)代理服務器，由俄羅斯的程序設計師Igor Sysoev所開發，可以穩定地運行在Linux、Windows等操作系統上，其特點是占用內存少，并發能力強。

同其他軟件一樣，Nginx也出現過一些安全漏洞，利用這些漏洞可以對Web服務器進行滲透攻擊。

下面我們通過實例來介紹幾個關于Nginx的安全漏洞，以及相應的漏洞利用方法。

Nginx漏洞分析實例

Nginx文件類型錯誤解析漏洞

在2010年的時候，國內安全組織80Sec發現了一個Nginx文件類型解析漏洞，但實際上這個并非Nginx本身的漏洞，而是由于配置導致的安全問題。下面我們詳細分析一下這個漏洞。

漏洞分析：Nginx默認是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通過正則匹配設置SCRIPT_FILENAME。配置文件中會有類似如下內容，如圖1所示。

 

 

圖1

location對請求進行選擇的時候會使用URI環境變量進行選擇，其中傳遞到后端Fastcgi的關鍵變量SCRIPT_FILENAME是由Nginx生成的$fastcgi_script_name來決定的。而通過分析可以看到$fastcgi_script_name是直接由URI環境變量控制的，這里就是產生問題的點。當訪問http://192.168.1.103/phpinfo.jpg/1.php這個URL時，$fastcgi_script_name會被設置為“phpinfo.jpg/1.php”，然后構造成SCRIPT_FILENAME傳遞給PHP CGI，但是PHP為什么會接受這樣的參數，并將phpinfo.jpg作為PHP文件解析呢?

這就要說到fix_pathinfo這個選項了，如圖2所示。

 

 

圖2

如果開啟了這個選項，那么就會觸發在PHP中的如下邏輯，如圖3所示。

 

 

圖3

到這里，PHP會認為SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就會將phpinfo.jpg作為PHP文件來解析了。

漏洞危害：利用該漏洞，攻擊者可以將任意文件類型作為PHP文件解析，攻擊者通常利用該漏洞來獲取到一個WebShell。

漏洞利用：假設某一服務器存在該漏洞，攻擊者可以通過上傳一張包含PHP后門代碼的圖片來獲取WebShell，這是一種常見的攻擊方式，如圖4所示。

 

 

圖4

解決方案：這里介紹兩種解決方案：一、修改php.ini文件，將cgi.fix_pathinfo的值設置為0;二、在Nginx配置文件中添加以下代碼：

if ( $fastcgi_script_name ~ \..*\/.*php ) {

return 403;

}

這行代碼的意思是當匹配到類似test.jpg/a.php的URL時，將返回403錯誤代碼，如圖5所示。

 

 

圖5

Nginx配置錯誤而導致目錄遍歷漏洞

在Nginx的配置文件中如果開啟了autoindex選項，并采用類似下面的配置時會造成目錄遍歷漏洞，如圖6所示。

 

 

圖6

當訪問http://192.168.1.103/test/這個URL時，正常情況應該遍歷html/test/這個目錄，但是如果訪問http://192.168.1.103/test../這個URL時，則會遍歷上一級目錄(html/)了。

下面我們通過一個實例來演示下這個漏洞，先來看下正常訪問時返回的頁面，如圖7所示。

 

 

圖7

現在我們再來看下漏洞被觸發后返回的頁面，如圖8所示。

 

 

圖8

通過圖8所示的返回結果，我們可以看到利用該漏洞我們成功遍歷到了其上一級目錄。

下面提供兩種方法來解決這個問題，從中選擇一種即可，具體配置如下圖9所示。

 

 

圖9

現在我們再來驗證下當采用上面的代碼加固Nginx以后，服務器是否還存在漏洞。

 

 

圖10

從圖10的返回結果可以看到漏洞沒有被觸發，而是返回了404頁面，說明漏洞被修復。

Nginx安全加固

針對Nginx的安全加固，主要從以下兩個方面考慮：一、Nginx Web Server程序本身是否安全，如是否存在安全漏洞;二、Nginx Web Server是否提供了可使用的安全功能，這部分主要是檢查Nginx的配置是否得當，是否存在由于配置失誤導致的安全問題。

Nginx版本的選擇與安裝注意事項

在選擇Nginx版本時，需要關注是否存在安全漏洞和版本的穩定性。一般選擇最新的穩定版本，這樣可以在穩定性和安全之間取得一個平衡。在升級Nginx版本前建議先在測試環境中測試通過后再正式升級，以避免由于兼容性帶來其他不可預知的問題。

關于Nginx的安全漏洞可以關注Nginx官方發布的安全公告(http://nginx.org/en/security_advisories.html)或到其他一些漏洞發布平臺上查找。

在安裝Nginx時建議使用自定義安裝路徑，如果采用默認安裝路徑，很容易被攻擊者和一些自動化攻擊工具猜測到，為其進行下一步的攻擊提供便利。

Nginx安全配置

1. 修改/隱藏Nginx Banner信息

攻擊者在對目標服務器進行滲透攻擊前，通常會有一個目標信息收集階段，這個階段的任務就是通過各種手段獲取到目標服務器的信息，如獲取目標服務器的系統版本、Web、數據庫的類型及相關信息，這個階段獲取到的信息將直接關系到攻擊者下一步采取的攻擊手段。因此，修改/隱藏Nginx的相關信息將在一定程度上可以增大攻擊者的攻擊難度，也可以騙過一些自動化攻擊工具。

在Linux平臺下以源碼方式安裝Nginx時，可以通過修改“src/core/nginx.h”中的信息來達到隱藏或自定義Banner信息的目的。

我們先來看下nginx.h這個文件中默認的內容，類似圖11所示。

 

 

圖11

這時當我們訪問Nginx服務器時，Server字段會返回真實的Banner信息，如圖12所示。

 

 

圖12

現在我們來自定義nginx.h中關于Banner信息的內容，可參考圖13。

 

 

圖13

修改完成后，重新編譯Nginx，然后安裝即可。安裝完成后，我們再來訪問下該Nginx服務器，發現這時Server返回的內容為自定義的Banner信息了，如圖14所示。

 

 

圖14

2. Nginx日志安全

不論在那種服務器上，日志都是一個非常重要的部分，我們需要對它嚴加保護。在Nginx上也是如此。Nginx的日志默認存放在安裝目錄的logs目錄下，首先要修改日志的默認保存路徑，然后設置只允許管理員有日志存放目錄的完全控制權限。

3. Nginx權限設置

Nginx權限設置分為Nginx運行權限設置和網站目錄權限設置兩部分。

Nginx運行權限是指Nginx以什么權限運行，以管理員權限運行是一個非常糟糕的決定。這樣的后果是攻擊者一旦攻擊成功，將直接獲取到一個高權限的WebShell。因此，我們需要設置Nginx以一個低權限的身份運行，可通過修改“Nginx.conf”這個配置文件來實現。

網站目錄權限設置則要遵循以下原則：

a) 如果目錄有寫入權限，一定不要分配執行權限

b) 如果目錄有執行權限，一定不要分配寫入權限

c) 網站上傳目錄和數據庫目錄一般需要分配“寫入”權限，但一定不要分配執行權限

d) 其他目錄一般只分配“讀取”權限即可