iLocker 作為 iGuard 網頁防篡改系統的檔案驅動過濾模塊所衍生出來的獨立應用，是一個檔案防護工具，可以在檔案系統驅動層檢查檔案操作，根據規則對檔案操作進行放行或攔截，可以靈活細致地對檔案訪問進行控制，

分享一則 iLocker 在實際運用中的案例，幫助大家拓展 iLocker 的運用思路——

起因

和許多突發事件一樣，本次案例也發生在狀況高發期——半夜，

工程師小張反饋服務器有不明程式在運行，判斷不出程式的運行意圖不說，它甚至還吃掉了100%的 CPU，小張嘗試 kill 掉這個不明行程，卻每次都會有新的行程殺出來，名字不盡相同，都是無規則的一串字母，好不煩人，

根據小張所述，并沒有什么頭緒，只有在程式里找線索了，

首先要厘清服務器（Linux）上的行程狀態， top 命令一看，確實有個符合上述特征的奇怪行程在吃 CPU，

嘗試重現小張所說情況： kill-9 可以殺掉，再 top 一看，又出來一個行程，名字變了，但換湯不換藥，

觀察

依照常規，用 ps-ef|grep 檢測發現，如下圖，7769，分明是同一個行程 ID， top 所顯示的行程名和 ps 得到的結果并不一樣，這一項問題姑且不論，檢查后還發現， ps 命令沒有被替換，程式還沒有感染整個系統，可以用 lsof 進一步查看此行程，發現程式檔案在 /usr/bin/ 下，

可以嘗試再 kill 一次行程，

雖然如意料之中，得到和最初一樣的結果，但再運行一次 ps 命令，我們有了新發現：不止7769一個行程，還暴露出一長串例外行程，

總結一下這次的問題：在同一時間點上，多個不該運行的命令在運行，比如 route-n ， grep"A" ，甚至還有 echo"find" 這樣的命令，十分反常，不僅如此，這些命令變化大量且迅速，每個行程短暫運行數秒即消失，新命令列程也在不斷生成，

至此，這次例外狀況的形態已初露端倪，100%占用 CPU 的行程可以斷定是核心作業行程，其他變化多端的閃現行程則充當保護肉盾，用來保護真正的作業行程不被殺死洗掉，棘手的，便是這些周而復始，葉訓不散的保護行程了，

當然，經驗豐富的我方安全戰斗人員，一線作戰經驗豐富，如果排查出問題所在，解決方案也當即應運而生，

shell 提示新郵件，查看一下，或許是個不錯的切入點哦！

不要錯過任何一個線索——

草蛇灰線，掩藏得再好，蛛絲馬跡還是被找到了！

腳本意圖明顯，功能簡單明了：

使用 ifconfig 命令啟動所有網卡
復制 /lib/libudev.so 到 /lib/libudev.so.6
啟動 /lib/libudev.so.6

可以看出

crontab 發出了提醒郵件，是因為系統沒有 ifconfig 命令，腳本報錯了，
腳本啟動的是 /lib/libudev.so.6 ，看起來這個檔案比較關鍵，

先嘗試洗掉 /lib/libudev.so.6 ，rm 命令執行成功，但是再次 ls 的時候，它又出現了，猜測是那些奇怪的行程在維護這個 /lib/libudev.so.6 不被清理，

思路變得簡單了：

怎么知道它都把檔案復制到哪里去了呢？
怎么找到并殺死那些不停閃現的行程呢？
怎么阻止它復制自己呢？

手段

iLocker 大顯身手的時候到了，

iLocker 可以保護檔案或目錄不被篡改，不但能阻止檔案創建，還能發現惡意程式操作了哪些檔案，無需多言，iLocker 配置起來，

配置前，有如下幾點考慮：

惡意程式的可執行檔案，在 /usr/bin 下面，需要把 /usr/bin 保護起來；
定時腳本里的惡意程式路徑在 /lib/libudev.so ，所以也把 /lib 也保護起來；
/tmp 目錄也比較特別，也需要特別關注一下；
我自己要洗掉 /lib/libudev.so ，所以先要把自己放開；
發現系統的 /lib 目錄實際上是個軟鏈接 /usr/lib ，故而實際保護
/usr/lib 目錄，

簡單解釋下 iLocker 的規則：

#uid=0,exe_path=*,cmdline=*,operation=MKDIR,file_path=/tmp/test/pass/*,action=pass
#uid=*,exe_path=*,cmdline=*,operation=*,file_path=/tmp/test/*,action=deny

一條規則包含以下資訊，根據這些資訊 iLocker 可以捕獲任意一個檔案操作，并對其進行攔截或記錄：

用戶 uid ，行程所屬的用戶 ID；
可執行檔案的路徑 exe_path ；
行程的命令列引數 cmdline ，常用來區分同一個程式的不同行程，比如 java ，python ，shell 等；
具體的檔案操作 operation （如 CREATE ，OPEN ， MKDIR 等）；
被操作的檔案路徑 file_path ；
iLocker 的回應動作 action （pass ，deny ，log）等，

根據觀察現象程序中搜集到的資訊，在 iLocker 中寫入如下配置——

exe_path=/usr/bin/rm,file_path=/usr/lib/*,action=pass
file_path=/usr/bin/*,action=deny
file_path=/usr/lib/*,action=deny
file_path=/tmp/*,action=deny

啟動 iLocker ，并打開 iLocker 日志管理器，發現瞬時增加很多新日志，瀏覽下來，幾乎都是惡意程式在寫檔案，如下：

2019-03-15 5:42:12,CREATE,0,14840,/usr/bin/irjsypzavm,/usr/bin/szklfovzwg,,deny
2019-03-15 15:42:12,CREATE,0,14840,/usr/bin/irjsypzavm,/tmp/szklfovzwg,,deny
2019-03-15 5:42:17,CREATE,0,14848,/usr/bin/irjsypzavm,/usr/lib/libudev.so,,deny
2019-03-15 5:42:18,CREATE,0,14848,/usr/bin/irjsypzavm,/usr/lib/libudev.so,,deny

例如其中第3條日志：

用戶 ID=0 ，行程 ID=14848 ，
行程檔案為 /usr/bin/irjsypzavm ，
想 CREATE 檔案 /usr/lib/libudev.so ，被攔截了，

之前的假設得到了證實——程式在不停地復制自己，

同時，我們也找到了惡意程式自我復制的路徑： /usr/bin 或 /tmp/ 下，檔案名隨機，復制到 /usr/lib/libudev.so 是固定的檔案名，

解決

一波操作之后，終于可以痛下殺手，斬草除根了：

再次 kill 掉100% CPU 的行程
rm /lib/libudev.so
清理留下的惡意檔案，清理crontab

如上所述，這些程式每次完成自我復制，就相應拉起一些新的行程，自己退出，

這次，且不用勞神一個一個找出這些行程：iLocker 運行，行程不再復制成功，自己退出，沒復制成功，也就意味著不再拉起新的行程，

iLocker 出馬，惡意行程原地自閉了！本局，安全團隊借助 iLocker 輕松實作全壘打！

案例總結

該案例下，服務器只開了一個 ssh 服務和一個只提供靜態頁面的 web 服務，系統是最新的，還打了補丁，看起來無懈可擊……

但是！

一個沒有“但是”做ending的案例是不完美的！

……

回傳去查看系統登錄日志，發現了大量失敗的登錄記錄，回想起最初工程師小張提供的登錄資訊，root 、弱密碼…沒錯，弱密碼被暴力猜解了！

安全是個整體
哪里都要注意
弱密碼要慎用！

（陳國 | 天存資訊）

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/285634.html

標籤：其他

上一篇：Google Hacking 搜索引擎攻擊與防范

下一篇：DVWA--XSS(存盤型)

巧用 iLocker 清理惡意程式

起因

觀察

手段

解決

案例總結