說說 WEB SHELL

 WEB SHELL 的威力和危害性有多大，大家都知道，我就不多說了。下面首先給出一個 WEB SHELL 的例子，然後，逐步分析我們應該怎樣來防範 WEB SHELL。

 一.  WEB SHELL 例子

本文提供該 WEB SHELL，是因爲下文的分析會用到它。請讀者不要誤用，感謝。

 

二. WEB SHELL 的防護

WEB SHELL 的防護，說到底，就是三點：

 首先，怎樣防止別人把 WEB SHELL 放到你的網站上去；

  其次，如果不幸，別人把 WEB SHELL 放到了你的網站上，怎樣防止別人執行這些被

              放上去 的 WEB SHELL；

  再次，如果更不幸，你遇上了絕頂高手，他不但把 WEB SHELL 放進了你的網站，而

              且還能想出招式來執行，怎樣儘量減小這些 WEB SHELL 執行所造成的破壞。

 

三. 先來談談怎樣防止別人上傳 WEB SHELL

這個問題說簡單也簡單，說複雜也負責，關鍵看網站的 WEB 程序員是否把網站的安全放在有心之上。如果 WEB 程序員關注自己開發的程序的安全，他們就會對自己的代碼中，處理用戶上傳文件的地方特別留意。對用戶上傳的文件的類型和內容執行嚴格的檢查。期望用戶上傳什麼樣的文件，就只允許上傳這些類型的文件，其它一概拒絕。這樣，惡意用戶想把 WEB SHELL傳上來 就難了。讀者可以參考筆者的<<WEB 應用數據驗證指南>>，其中講了對WEB 應用數據驗證的一些方法。

 

四. 接下來談談怎樣防止惡意用戶執行放上來的 WEB SHELL

筆者知道並實踐過的方法有兩種，下面詳述。

一是禁止 WEB 應用服務器編譯 WEB 頁面的能力，可以通過設置 $RESIN_HOME/webapps 目錄對 RESIN 進程爲只讀來實現。當然，前提條件是你自己的 WEB 應用程序要事先編譯好，然後再放到 $RESIN_HOME/webapps 裏的適當位置。因爲RESIN 對  $RESIN_HOME/webapps 目錄只有只讀權限，不管是對你自己的程序而言，還是對於上傳上來的 WEB SHELL 而言，都不能在線編譯。

二是配置一個專門的域名來負責發佈用戶上傳的文件，該域名由純靜態的服務器來發布，比如APACHE。這樣，即使惡意用戶把 WEB SHELL 傳上來了，縱然他有天大的本事，也不能讓靜態服務器來執行他的 WEB SHELL。哈哈哈哈。

 

五. 最後來談談怎樣儘量減小 WEB SHELL 執行所帶來的危害

人世間有些事情是很難說的，對於信息安全來說更是如此。有很多你覺得根本就不可能發生的事情，總是在你不經意之間出現。所以，就算你運用了上面的招式，未必就一定能防止***精英們在你的網站上執行 WEB SHELL。 所以，我們還要做最壞的打算，如果不幸中的不幸發生在了我們的頭上，我們怎樣限制 WEB SHELL 執行所造成的破壞呢。

一是用非root（比如 resin）用戶來運行應用服務器，比如 RESIN, 這樣，即使 RESIN 執行了系統命令，那麼其破壞程度也可以限制在非root用戶（比如resin）的權限範圍內，絕不會出現惡意用戶執行了 rm -rf / 所導致的讓你痛苦流涕的惡果。^_^

下面是我配置RESIN的通用刀法：

[root@wireless-239 local]# pwd
/usr/local
[root@wireless-239 local]# ll
總用量 28124
drwxr-xr-x  11 root root      4096  1月  6 15:19 resin-3.0.22
[root@wireless-239 resin-3.0.22]# ll
總用量 36
drwxr-xr-x  2 root  root  4096  1月  6 16:05 bin
drwxr-xr-x  2 root  root  4096  1月  6 15:23 conf
drwxr-xr-x  2 root  root  4096  1月  6 15:16 lib
drwxr-xr-x  2 root  root  4096  1月  6 15:16 libexec
drwxr-xr-x  2 resin resin 4096  1月  6 16:05 log
drwxr-xr-x  2 resin resin 4096  1月  6 15:18 logs
drwxr-xr-x  3 resin resin 4096  1月  6 15:24 tmp
drwxr-xr-x  5 root  root  4096  1月  6 15:16 webapps
drwxr-xr-x  3 resin resin 4096  1月  6 15:25 work

[root@wireless-239 resin-3.0.22]# ps -ef | grep resin | grep -v  grep

resin    25073 25071  0 16:05 ?        00:00:05 /usr/local/jdk/bin/java -ms2048m -mx2048m -Xss1m -Dresin.home=/usr/local/resin-3.0.22 -Dserver.root=/usr/local/resin-3.0.22 -Djava.util.logging.manager=com.caucho.log.LogManagerImpl -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl com.caucho.server.resin.Resin -socketwait 51989 -stdout /usr/local/resin-3.0.22/log/stdout.log -stderr /usr/local/resin-3.0.22/log/stderr.log

[root@wireless-239 resin-3.0.22]# ll log
總用量 36
-rw-r--r--  1 resin resin     6  1月  6 16:05 httpd.pid
-rw-r--r--  1 resin resin     0  1月  6 15:18 jvm.log
-rw-r--r--  1 resin resin 28377  1月  6 16:05 stderr.log
-rw-r--r--  1 resin resin  4008  1月  6 16:09 stdout.log

[root@wireless-239 resin-3.0.22]# cat bin/httpd.sh

......

args="-J-ms2048m -J-mx2048m -pid log/httpd.pid"

以上內容的具體解釋，超出了本文的範圍，請參考 resin 文檔。

 

下圖表明，當我們以非 root 身份運行 RESIN 的時候，RESIN 不能訪問 /root 了：

 

 

我們說，讓應用服務器以非root身份運行，可以保證 WEB SHELL 不能把魔爪伸出到應用服務器運行的用戶身份的權限之外。可是，應用服務器爲了能正常服務 WEB 請求，還是必須訪問 JSP 文件，那麼，如果不仔細考慮權限，應用服務器還是可能會被賦予刪除這些 JSP 文件的權限的。那麼，我們應該怎樣做呢？筆者的做法是將RESIN的webapps目錄宿主設置爲root，而單獨配置另外兩個目錄來作爲 RESIN 工作目錄。由於 JSP 文件是放在 webapps目錄下的，而該目錄是root所有，RESIN 就拿它沒辦法了。至於這兩個工作目錄，RESIN 當然有所有的權限，不過我們並不太關心工作目錄裏面的東西。因爲這些東西是輕易就可以重新生成的。

相關配置如下所示：

[root@wireless-239 resin-3.0.22]# ll
總用量 36
drwxr-xr-x  3 resin resin 4096  1月  6 15:24 tmp
drwxr-xr-x  5 root  root  4096  1月  6 15:16 webapps
drwxr-xr-x  3 resin resin 4096  1月  6 15:25 work

[root@wireless-239 resin-3.0.22]# cat conf/app-default.xml | grep dir

......
<work-dir>/usr/local/resin-3.0.22/work/${host.name}/${app.name}</work-dir>
<temp-dir>/usr/local/resin-3.0.22/tmp/${host.name}/${app.name}</temp-dir>

 

下圖表明，當我們禁止了 RESIN 對 $RESIN_HOME/webapps 的寫訪問後， RESIN 不能刪除 JSP 文件了：   

 

到此爲止，我們已經讓 RESIN 不能破壞系統，不能破壞 JSP 文件。可是，還有一個讓人頭痛的問題，那就是數據庫連接信息的問題。有個大中型 WEB 系統維護經驗的讀者都知道，數據庫連接信息一般都是放在應用服務器的配置文件裏面的。而應用服務器是一定需要讀自己的配置文件才能正常工作。不過，我們仔細想想，就會發現，其實應用服務器只有在啓動的時候才需要讀自己的配置文件，一旦啓動完成了，就不再需要讀了。所以，我們可以這樣做，讓應用服務器在啓動的時候對自己的配置文件有讀權限，一旦啓動完畢，就禁止應用服務器對自己配置文件的讀權限。這樣，我們就防止了 WEB SHELL 通過讀應用服務器的配置文件來獲得數據庫連接信息了。

下面提供筆者自己的相關配置：

[root@wireless-239 resin-3.0.22]# cat bin/my-httpd.sh
chmod 755 /usr/local/resin-3.0.22/conf/resin.conf
sudo -u resin ./httpd.sh $@
sleep 90
chmod 000 /usr/local/resin-3.0.22/conf/resin.conf

 

注：筆者配置文件中的 sleep 90, 適合自己服務器的應用，讀者可能需要做適當調整，才能適合你的WEB 應用。

 

下圖表明，當我們配置了 RESIN 啓動後失去對 $RESIN_HOME/conf /resin.conf 的讀權限後，RESIN 不能讀該文件了：

 

 

總之， 儘管 WEB SHELL 臭名昭著而威力強大，但是，只要我們做個有心人，採取適當的防範措施，WEB SHELL 要施展手腳，也不是一件易事。最後，願大家維護的網站永遠都不要受到 WEB SHELL 的破壞。good luck !!!