主機被植入木馬後的應急響應思路

• 2019 年 11 月 20 日
• 筆記

又是一個風和日麗的下午,姜老師發了一張圖。是一個系統進程的截圖。赫然在目一個看起來命名很隨便的一個進程名，很輕浮。

姜老師作為一個老江湖，怎麼就能讓這麼一個不正經的程式在自己的主機上運行起來？

按理說我們這時候應該列出各種圖表和操作命令系統截圖，來溯源整個入侵的過程,輔助大家理解整個事件的前因後果。這也是「糖果的實驗室」公眾號，第二次寫應急。奈何天太熱，實在不愛動，空調和糖水都不能喚起來我躺起來的熱情。在可能不是草長鶯飛的日子，說一篇公眾號。

用一個公眾號來發各種富文本是一個很累的活兒，因此想用一個純文字版的資訊推送，來表述一個大概事件過程。

對於過往，已發表的文章大概可分成幾類：一種就是非常寫意的抽象概念，祖國山河，大好景色，溝幫子燒雞，天一腳地一腿，這種情況下大家好像不太買賬。對於一些虛頭巴腦的概念，沒有什麼心得體會和收穫的話，往往會對這種文章嗤之以鼻。說的越對，越虛，越沒人愛聽。

還有另一種純工具實用主義類的介紹性文章，這裡有大量的程式碼和對應的工具介紹，然而這種文章的回應也寥寥無幾，一般都是好頂贊。但是還是要特別感謝朋友們的支援，默默的點擊收藏的數量應該不是假的。

只有一種文章卻受歡迎，就是文章要有故事，要有包袱，要有亮點。還要有解決方案。 就算這種場合，也有會在評論里說，他們不關心娛樂，說這口才不適合做什麼什麼的應該去說相聲， 對看文章找錯別字的朋友，只能不好意思了。

接著主題說，問題既然這麼發生了，接下來如何應急呢？

按照傳統的做法，我們會把系統上運行的所有的服務都看一遍。然後找到那種高危的程式，去重點關注一下。往往這種程式的特徵也比較明顯。會在某個時間段進行，大量的網路傳輸操作。佔用記憶體和計算資源。

但是對於溯源來說，一定要看一下重要的正常服務。

比如nginx是否運行在超級用戶環境下。

比如特定資料庫是否開了一些敏感的服務。

還有就是系統版本是否過低。

使用的語言工具是否版本過低沒有更新？

看看計劃任務是否被篡改。

我要通過各種技術手段發現黑客是否在伺服器上留下什麼蛛絲馬跡？

我們要找到黑客是從哪個途徑入侵到伺服器。經過一定的排查，最有可能出現的問題是出在網頁伺服器使用的電商系統版本過了。其實這個也不是排查的，是因為服務的使用者自己清楚。

通過網頁的漏洞，經過一系列的提權，將木馬程式植入到伺服器。這是一種比較常見的入侵。特別是在各種雲廠商的服務上。

其實每家雲服務廠商都有自己的防護系統。但即使有這些防護系統，雲主機被入侵的概率也是不小的。姜老師面臨一個比較尷尬的局面就是。業務用了一個很老的電商軟體。用軟體提供的功能來，支撐他們的業務運轉。但可能是因為一個祖傳程式碼。不好進行更新和修改。

大家都知道這種祖傳程式碼的威力。不敢動，不敢改。能維持正常運作就已經很不錯了。你不知道過去的程式碼里加了多少的黑客技術。

工廠管這種項目叫做坑。誰負責誰就是坑長。

另外系統本身的版本也不高。運行的語言軟體版本也不高。你從程式碼審計的角度，我們要去掃描一下程式碼是否被動過。

往往這種被入侵的事件發生的概率很高的。但是我們一般都有多少種途徑來解決這種問題？像這種雲服務。他們本身提供的防護系統不起作用。一般這時候的雲服務使用者不會再另外構建一個自己的安全防護系統。

姜老師發現了主要的問題的進程。當下掉這個業務的主機。把不正經的程式拷貝到新的主機環境下。這個進程也是無法被殺掉。會不斷的重啟。可能短時間內我們無法對老的系統進行版本的升級。所以首要的任務要把老業務恢復生命。重新提供服務。但同時也面臨著再次被入侵的風險。

我們通過系統運維手段發現了問題的進程。姜老師定位這是入侵，很有可能是在國外進行。所以，大體回憶起來我們整個應急過程是這樣的。

首先排查掉，重點業務是否有漏洞的危險！如果都沒有，是不是因為軟體版本過老造成？版本老的軟體本身可能存在一定的漏洞。而在境外的人會利用這個漏洞進行提權入侵。針對這一點，響應的一個辦法就是將所有境外中國以外的服務請求全部關閉掉。

很明顯，這個業務是一個地域性很強中文業務。不提供境外支付方式進行交易。大面積的訂單都是在中國境內完成。所以姜老師可以把境外的所有請求都屏蔽掉。

其實姜老師的系統也不是完全沒有防護。她本身可以在自己的nginx上進行安裝waf模組進行攔截。現在比較清晰的一個黑名單就是。所有中國境外的IP可以全部屏蔽掉。

我們如何屏蔽掉境外的IP呢？怎麼區分是境內的IP和境外的IP？我們可以通過開源IP庫進行查表。然後封禁所有國外的請求。

某種程度上可以解決某些領域的黑客入侵。但是如果國外的黑客使用了中國的肉雞。通過代理跳板的方式進行，目前還是沒有辦法解決這個問題。但這本身增加了他們入侵的難度和成本。

其實對於老的電商業務系統來說。定期進行掃描是不錯的選擇。但即使發現了有漏洞，如果沒有及時解決。掃描也只是一個預警的功能。也有可能是一種老系統，未知的0day。一樣可以攻擊進來。所以也沒有絕對的安全。安全本身和你投入防護成本也有關係。

但即使這樣，我們也可以通過其他手段發現被入侵。我們常見的方法就是監控服務程式碼的變更。一旦是非開發人員進行程式碼改變。可以被系統所識別並報警。

其實掃描和程式碼審計，雲服務廠商也可能會提供這種服務。但即使有這種服務也不一定會發現威脅。而業務，自己搭建的防護系統。其實相對更有針對性。因為業務指導自己的薄弱環節在哪裡？擔心自己哪裡可能存在問題。這種問題是訂製化的，不一定是通用的防護。系統可以解決的。

如果下次再有類似的入侵。找姜老師其中的麻煩。至少我們應該構建一個什麼樣的機制來完善自己的防護工作？

首先創建一個定時掃描的業務系統。通過定時或者不定時的方式對當前系統的漏洞，進行全方位的了解。對於一些顯而易見的漏洞，不至於視而不見。當然可能會面臨一個問題。就是上文所說的業務過分依賴於老版本的軟體。並且後續升級維護有困難。即使在這樣的前提條件下，也要保證系統安全。

除了掃描，另外一個重點就是文件監控。對非開發人員修改程式碼的行為，要進行跟蹤確認。一旦發現有人在你的程式碼中動了手腳。你可以在這個節點發現異常行為。很不好意思，我們這裡只是聽純文字版，不便於編輯，列出工具。

實在如果沒有實時的文件監控。可以進行定期的後期審計文件掃描。

自動化的日誌分析手段。當入侵發生後，對訪問日誌的分析，是一個不可或缺的過程。如果還停留在純文本的操作模式。相對的效率呢，可能不是最快的。

所以我們通過類似於大數據的這些手段，把系統的日誌進行實時分析，根據系統日誌得出的結論進行下一步的判斷。

其實地圖炮貌似是一個不實用的東西。但如果像這次實踐。有一個明確的需求點就是不希望老外來訪問我們的中國一些網站。不是不歡迎老外，是不歡迎來搗亂的，老外黑客。

如果在入侵的當時，可以有自動化的日誌分析手段。針對用戶的請求IP。與開源IP庫進行交互。取得IP所在地理位置資訊。我們可以通過大數據的工具清晰的看到，訪問者。的IP是在中國境內還是中國境外？

因為這是一篇純文字吧，我們會基於這一篇純文字版再出一版工具介紹。

說到防護工具。一種是我們基於日誌的分析。一種是基於流量數據的分析。這個流量可以來自7層，也可以來自4層，簡單說就是，HTTP還是Tcp。這種防護往往解決大流量攻擊效果不太好。但是解決老系統的邏輯漏洞，進行查缺補漏還是有效的。

針對有限的攻擊手段。也一樣會有防衛手段。可能這次姜老師的系統。是因為電商軟體版本太低，造成給別人有侵入的機會。但是也通過了日誌審計，hids進程檢查、程式碼掃描、IP限制、腳本限制等各種手段進行防禦。

後期還對木馬進行了分析。將木馬放入沙箱，分析結果顯示這是一個中威木馬程式。對於所有掛在外網的服務來說，被掃描和被入侵的可能都是存在的。我們幾乎每天都會面臨這樣的問題。

是否我們可以通過一種複合的手段，來儘可能的發現這種入侵行為？用一套相對通用的工具，給予像姜老師這樣老江湖提供一個解決方案。

其實相對沒有一種方法可以解決所有的問題的。如果有兩個防護系統。我們重點應該看它的誤報率和漏報率，還是看他能發現了什麼。如果誤報率很低，但是什麼有用的威脅也沒有發現，那這種系統還是比沒有誤報率高，能發現威脅的系統有用，誤報率高我們可以想辦法過濾，而什麼有用威脅識別不到的系統，我們是沒有辦法。

如果文章有錯別字什麼的，還請您留言！我們希望可以和老薑的故事一起精進成長。符總和DK在這個事中仙人指了路。也不知道老薑現在有沒有和小區里的大爺們在殺一盤。