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 、弱密碼…沒錯，弱密碼被暴力猜解了！
安全是個整體
哪裡都要注意
弱密碼要慎用！
（陳國 | 天存資訊）