-- “隱患險於明火，防範勝於救災，責任重於泰山”

這篇文章中記錄的事件發生在兩年前，事件發生並處理後我在自己本地做了記錄（本文中的主體內容都來源於這份兩年前的記錄），最近才在清理舊檔案的時候翻了出來。之所以當時沒有在部落格中進行記錄原因有二：第一，之前我太懶（是真的懶，懶到忘了自己部落格早就已經註冊過）；第二，做了對應處理後，並沒有完全的信心認為已經處理妥當。觀望了這兩年發現確實沒再發生同樣的事件，說明當時的處理辦法是有一定效果的，想要將方案分享出來。

下面直接進入正題。

一、事件發生

Z專案部署於某公有云上，兩年前的某一天，某雲平臺發出預警提示伺服器可能受到攻擊。趕緊檢查（此處感謝某雲工程師的配合），發現伺服器有可疑程序正在執行某個指令碼自動下載檔案，並不斷與國外的幾個IP進行連線。正在執行的業務程序與Z專案完全無關，基本判斷為伺服器被植入了木馬。

二、發現問題

發現了木馬，並不能算是發現了問題所在，伺服器必然存在某個漏洞導致後門大開，這次的木馬即使被清理也無法保證不會再被入侵。應重點處理的根源是填補漏洞，而不是僅僅處理當前木馬。

那麼進行一下梳理分析（再次感謝某雲工程師的配合）：

1. 某雲平臺中的安全策略已進行了配置，雲平臺自身防火牆的策略、預警也都已開通（這裡沒問題）；
2. 伺服器出口策略目前定義的是全部放通（這裡有風險）；
3. 檢查了伺服器的定時任務列表，發現被加入不明定時任務（這裡已經產生了問題）；
4. 部署的web應用伺服器為Tomcat6（這裡有風險，加固策略可能存在遺漏）。

經過梳理，初步發現了風險和有問題的地方，先緊急處理目前的問題，再進一步進行分析處理。

三、緊急處理

根據問題的表象，先進行緊急處理：

1. 清理木馬檔案；
2. 刪除伺服器中不明定時任務；
3. 將發現的國外伺服器地址在出口策略中配置為禁止訪問。

緊急處理後伺服器執行恢復正常，為我們後續的操作爭取到一定的時間。接下來正式處理問題。

四、加固方案

我們的方案重點放在對Tomcat6進行加固。其他風險點我們在某雲工程師的配合下已完成了可處理的極限，更多其他方面的安全需要某雲來保障了。而對於具體的web應用伺服器（Z專案使用Tomcat6），某雲工程師無法再提供支援，需要我們專案組內自行處理。綜合了網路上各大神的處理辦法，我們自己進行了彙總，並實施了以下幾個方面的加固（此處記錄所有做過的操作，不區分是在本次事件發生後才做的處理還是上線前已做過的處理）：

1. 修改伺服器SSH訪問埠；
2. 刪除Tomcat中的示例文件與示例專案；
3. 刪除Tomcat控制檯功能，或設定複雜控制檯口令；
4. 修改SHUTDOWN命令；
5. 單獨建立Tomcat使用者許可權；
6. 禁止顯示檔案列表；
7. 開啟記錄訪問日誌。

詳細說明一下每項加固的操作方法：

1.修改伺服器SSH訪問埠：

為了避免攻擊者通過網際網路掃描到SSH的預設埠22，進行破解登陸伺服器。具體操作步驟如下（示例伺服器OS為CentOS7）：

第一步，修改SSH配置檔案：

vi /etc/ssh/sshd_config

第二步，找到如下行（22埠是被註釋的狀態，SSH預設埠就是22）：

#Port 22

第三步， 自行修改為調整後的埠號（其中的埠號55000是我自己修改的，修改後的埠號最好按習慣大於1024）：

#Port 22
Port 55000

按配置的埠號同步調整防火牆策略，由於我們使用的是某雲平臺，策略統一在雲平臺後臺進行配置。此處不再贅述防火牆策略的配置過程。需要注意，在下一步重啟SSH服務後遠端連線的客戶端會斷開，如果在下一步之前防火牆沒有允許新埠的使用就會無法遠端登陸伺服器。

第四步，重啟SSH：

systemctl restart sshd

完成，從此以後SSH就可以使用新埠了，預設的22埠不再起作用。

2.刪除Tomcat中的示例文件與示例專案：

進入tomcat目錄下的webapps目錄，會發現其中有docs和examples這兩個目錄，其中的內容是Tomcat示例用到的頁面和文件內容，對實際部署的應用並沒有任何實際用途，反而有可能被惡意攻擊者利用。建議直接刪除docs和examples這兩個目錄及目錄下的所有檔案。

3.刪除Tomcat控制檯功能，或設定複雜控制檯口令

Tomcat6預設會提供控制檯功能，但不會提供預設的使用者名稱和密碼。可以通過http://ip:port/manager/html訪問，訪問時會彈出要求輸入使用者名稱與密碼，如下圖：

由於控制檯內的功能很難被用到（大部分情況下很難用到，如你想知道有什麼情況會用到，可以檢視其他關於tomcat6 manager的介紹），而且暴露在外的控制檯對於使用者賬戶的管理還是會存在一定的風險，當然也可以配置成只允許指定IP訪問，但如果伺服器被入侵，這些基於應用的配置還是風險很大，建議直接刪除控制檯功能。

刪除方法：找到tomcat目錄下的webapps目錄，刪除其內的manager和host-manager兩個目錄即可。

如確實需要保留控制檯功能，建議設定複雜口令。設定控制檯口令的方法如下：

第一步，開啟儲存口令的檔案：

vi $tomcat_home/conf/tomcat-users.xml

第二步，找到檔案中的<tomcat-users>節點，發現其中的內容都是註釋掉的，原始內容如下：

<tomcat-users>
<!--
  NOTE:  By default, no user is included in the "manager-gui" role required
  to operate the "/manager/html" web application.  If you wish to use this app,
  you must define such a user - the username and password are arbitrary.
-->
<!--
  NOTE:  The sample user and role entries below are wrapped in a comment
  and thus are ignored when reading this file. Do not forget to remove
  <!.. ..> that surrounds them.
-->
<!--
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
-->
</tomcat-users>

第三步，在 <tomcat-users> 節點內按如下格式增加角色與使用者，並設定使用者名稱和複雜口令。例如：

<tomcat-users>
  <role rolename="manager-gui"/>
  <user username="使用者名稱" password="複雜口令" roles="manager-gui"/>
</tomcat-users>

這裡稍微擴充套件一下，此處使用到的rolename為manager-gui，Tomcat一共有四種角色：manager-gui、manager-status、manager-script、manager-jmx，這四種都在$tomcat_home/webapps/manager/WEB-INF/web.xml裡定義了，感興趣的朋友可以自己看看每個角色都有什麼樣的許可權。

4.修改SHUTDOWN命令

這項操作是為了防止8005埠被攻擊者telnet到後，傳送SHUTDOWN命令停止我們的tomcat服務。這裡的8005埠與SHUTDOWN命令都是Tomcat預設的配置，均可以進行修改。修改SHUTDOWN命令串就可以防範這類的惡意攻擊，同時修改8005埠也是可以的。操作過程如下：

第一步，開啟Tomcat的server.xml檔案：

vi $tomcat_home/conf/server.xml

第二步，找到SHUTDOWN命令對應的配置位置，如下：

<Server port="8005" shutdown="SHUTDOWN">

第三步，修改SHUTDOWN命令的字串（也可以同時修改8005埠），設定為複雜字串：

<Server port="8005" shutdown="複雜字串">

5.單獨建立Tomcat使用者許可權

這一點各專案團隊都會做，即使Tomcat使用者口令被破解或洩露也不會影響到伺服器的其他目錄。這裡對使用者許可權配置的過程不再進行贅述，可直接使用各OS配置使用者組、使用者許可權的方式操作。

6.禁止顯示檔案列表

這項操作是為了防止在使用不含頁面名稱直接訪問目錄時找不到預設主頁，會顯示出目錄下所有檔案的風險發生。Tomcat6中預設這一項是禁止的，符合我們的要求，但需要檢查到位，防止已被攻擊者開啟或被運維人員由於某些原因開啟（誤開啟，或有其他目的的開啟）。操作過程如下：

第一步，開啟Tomcat的web.xml檔案：

vi $tomcat_home/conf/web.xml

第二步，找到listings的配置，如下：

<init-param>
    <param-name>listings</param-name>
    <param-value>false</param-value>
</init-param>

我們可以看到預設的配置是false，這樣是我們需要達到的效果，能夠禁止顯示檔案列表。如果不是false建議改回false。

7.開啟記錄訪問日誌

Tomcat6的訪問日誌預設是未開啟的，開啟訪問日誌的目的是得到每一次訪問的記錄，事後能根據這份記錄進行稽核和分析，如有異常訪問在這份日誌裡是可以分析出來的。開啟方式如下：

第一步，開啟Tomcat的server.xml檔案：

vi $tomcat_home/conf/server.xml

第二步， 找到配置AccessLog的地方，如下：

<!--
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"  
       prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
-->

可以看到目前預設是註釋掉的狀態，開啟註釋即可。Tomcat6訪問日誌預設存放的位置在$tomcat_home/logs目錄下，生成的日誌檔名稱格式如：localhost_access_log.2017-12-13.txt。開啟檔案，能看到記錄的內容還是很詳細的，如下：

其中記錄有請求IP、請求的時間、請求方式、被請求的檔案路徑、響應的http狀態碼等資訊對於事後分析都很有用，建議開啟訪問日誌。需要注意做好訪問日誌的備份與清理（每一次向伺服器發起的請求都會被記錄，業務量大的時候硬碟會被吃的很快）。

以上幾項Tomcat中的配置完成後，重啟Tomcat服務即可生效。

五、事後思考

這次事件對伺服器造成的影響很大，機器的頻寬和IO在一段時間內差點達到峰值導致宕機，所幸某雲的預警發現較早，給了我們一段時間進行緊急處理，沒有造成服務中斷的惡性事件。

Z專案的系統做了這幾項加固後，經過這兩年的執行沒再出現過相同的事件，但我們依然應該保持清醒保持警惕，每一次的教訓都應轉變為下一次處理時的經驗。

六、感謝

這次的事件處理，要大力感謝某雲工程師的配合（為了避免打廣告嫌疑，這裡使用某雲指代我們的雲服務供應商），由於當時的客觀原因，我們團隊成員中並沒有運維工程師或安全工程師，事件的處理過程中某雲工程師都能盡力配合，共同完成了這次的救火任務。