巧用 iLocker 清理恶意程序

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 提示新邮件，查看一下，或许是个不错的切入点哦！

不要错过任何一个线索——

草蛇灰线，掩藏得再好，蛛丝马迹还是被找到了！

脚本意图明显，功能简单明了：

1. 使用 ifconfig 命令启动所有网卡
2. 复制 /lib/libudev.so 到 /lib/libudev.so.6
3. 启动 /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 、弱密码…没错，弱密码被暴力猜解了！

安全是个整体

哪里都要注意

弱密码要慎用！

（陈国 | 天存信息）