巧用 iLocker 清理恶意程序
巧用 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 提示新邮件，查看一下，或许是个不错的切入点哦！
不要错过任何一个线索——
草蛇灰线，掩藏得再好，蛛丝马迹还是被找到了！
脚本意图明显，功能简单明了：
- 使用
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 、弱密码…没错，弱密码被暴力猜解了！
安全是个整体
哪里都要注意
弱密码要慎用！