1、引言

        網路安全是互聯網永不過時的主題，尤其是在雲計算時代，大量的電腦應用遷移到雲端，龐大的IT資產集結在雲數據中心，一旦雲數據中心爆發安全險情，輕則大量服務停擺，重則敏感數據丟失、系統遭到破壞，損失不可估量。國內幾大頭部雲服務提供商，近一年都發生過網路運行或安全事故，拋開經濟損失不提，作為頂級IT巨頭出現安全問題難免尷尬，授人以柄、影響聲譽。

        本文講述今天發生的一起黑客入侵事件，網路紅客與黑客攻防對戰。作者帶您一步步揭開黑客攻擊計算系統的內幕，也講述網路紅客如何絕地反擊。

        黑客身手不俗，深夜凌晨悄然侵入雲伺服器，步步為營，沿路設置重重障礙，就像冷兵器時代的鐵蒺藜、鐵拒馬灑滿一路，設下重重機關，牽一發而動全身，維繫木馬程式存在。

        然並卵非也，魔高一尺，道高一丈。我們想象中，網路紅客高舉網安利劍，直入特洛伊城，層層深入，抽絲剝繭，把黑客設下鐵蒺藜一根根拔出，輕鬆拆解隱秘機關，最後堵上城防漏洞，恢復城市的健康和生機。這裡的特洛伊城就是中招的雲伺服器。還可能留下一具木馬僵屍標本，以供將來拆解、把玩。哈哈！

        事實果真如此嗎？

        閑話少敘，我們直奔主題，欣賞一場紅客、黑客攻防戰的來龍去脈和驚險場景。

        從這個例子也感悟到，我們以為的真相其實只是表象，看到的表象是更淺顯的表象。就像俄羅斯套娃，一層套一層，不到最後一刻永遠不知道是否抵達真相。

2、雲機見疑雲

2.1 遭遇半癱機

        最近一個月，同事們抱怨公司JIRA伺服器變慢了，而且越來越慢，點擊頁面幾秒才有響應，幾個人同時點頁面，圓圈能不能轉出來看運氣。最近我忙著做K3s系統遷移，對JIRA沒有太在意，也沒有關註PR和缺陷報告。

        直到昨天，發現軟體產品的有個頁面不符合我帶有潔癖的審美，小伙伴們慫恿我提交一條PR，我才去打開久違了的JIRA首頁。沒想到JIRA不給力，點登錄後圓圈轉啊轉啊，就是不出來工作台。還不給面子，報告賬號密碼錯。換Chrome瀏        覽器登錄，還是賬號、密碼錯。我的賬號、密碼是記在電子本本上的，排除人為因素，僅僅拷貝是不可能出錯的。

        那個無限旋轉的圓圈，一點點消磨我的耐心。圓圈能不能求得圓滿，以至於懷疑人生。哈哈。

        此路不通，能否擇歧路而行？用安全郵箱修改JIRA密碼後，再登錄圓圈消失了，正常登錄進去。然後，一波未平一波又起，新建PR頁面，出現白屏幾分鐘無響應。

        此間不明一定有暗鬼。

        小伙伴們的無助和我的切膚之痛，激發了我的好奇心和正義感。

        明知山有虎，偏向虎山行。我不入地獄誰入地獄。

        人不可雀語，語雀願助人。語雀耳語於我，告知JIRA的賬號密碼和訪問路徑。JIRA伺服器架設在阿裡雲數據中心，雲端SSH直連通道關閉，只能用堡壘主機作跳板二次登錄才能訪問JIRA伺服器。架設JIRA的人士用心於安全可謂良苦。

前奏有點慢節奏，不過某國大片不經常是這樣的開頭的嗎，平靜的生活危機四伏。

2.2 初探噬心獸

        系統響應慢，習慣性地先看系統資源利用情況。輸入top命令，一看嚇一跳，有一個sd-pam進程占用CPU接近400%。

圖 JIRA伺服器系統資源利用情況

          輸入htop命令進一步查看詳情。

圖 JIRA伺服器系統資源利用詳情 

        從詳情頁可見，這台雲伺服器一共有4個CPU核心，4個核心利用率全是100%。可憐的JIRA（Java）進程擠到不知道哪個犄角旮旯里去了，分配的CPU連1%都不到，難怪JIRA會慢得像蝸牛。

CPU利用率排在前5位（1+4）的進程無一例外是sd-pam，第1個進程CPU利用率是396%，緊接著4個進程CPU利用率在99%左右。

        大家可能會問，4個核心的主機，5個進程CPU利用率加起來將近800%，怎麼像8個核心呢？

        Linux是多進程多線程的操作系統，以進程模擬線程，5個進程ID（PID），其實只有一個主進程，其餘4個是進程模擬出來的線程，從屬於主進程，4個線程的CPU利用率合計等於第1個線程的CPU利用率396%，不要重覆計算。

        sd-pam進程像瘋狂的野獸吞噬著CPU。去研發大群里詢問，沒有人能說清楚sd-pam進程是什麼來頭。疑雲驟起，關註點向sd-pam進程聚焦。

2.3 舉手解內困

        提交PR還得仰仗JIRA服務，JIRA服務是運行在Docker容器內的。登錄到JIRA容器，查看Java虛擬機參數，堆空間最大可用預設值是768MB，對於JIRA服務來說顯然偏低。而雲伺服器16GB記憶體還有10GB以上的空閑，閑著也是閑著，堆空間最大可用值擬修改為2GB。因為運行環境和文件許可權問題，在容器內不好修改文件，所以用docker cp命令把環境設置文件setenv.sh拷貝到宿主機，修改後拷貝回JIRA容器。

        在大群里喊一嗓子，要重啟JIRA服務了，沒人理，過幾分鐘就reboot雲伺服器了。

        重啟後，JIRA服務的配置會生效，JVM堆空間會擴大，對改善JIRA服務會有幫助。我也想看看雲伺服器重啟後，sd-pam進程會不會還在。

        修改JIRA配置與黑客對戰沒啥關係，不過是舉手解JIRA之困境。

3、循跡清木馬

3.1 初識兩點疑

        重啟雲伺服器後，sd-pam進程依然頑固地存在，撒著歡一樣把CPU利用率拱到滿格400%。

        “你來或不來我都在這裡，不多不少，4個CPU全是我的菜。” 清哥哥感覺被挑釁了，看來得好好伺候這位爺了。

        思緒開始往木馬、蠕蟲方向去想了。但凡木馬都不是孤立的，要與外界聯繫，雲伺服器聯繫外界唯一的通道是網路通信。我想看看sd-pam都聯繫了哪些網路地址。實用工具lsof能查看進程打開的所有文件描述符。文件描述符有點抽象，但是說建立的TCP連接、打開的文件/目錄、建立的管道都是文件描述符，就不難理解了。而進程打開的文件和建立的TCP連接正是我想知道的，以後有妙用。

        在CentOS上，預設地沒有安裝實用命令lsof，通過yum自動下載安裝。

1 yum install -y lsof

        安裝好以後迫不及待想看看sd-pam都幹了啥。輸入lsof命令，帶參數-p PID，PID是進程ID。

1 # lsof -p 11320

圖 sd-pam進程打開的文件描述符

        分析命令輸出，發現兩個疑點：

        第一個疑點是被刪除的文件：/var/tmp/dbus/.sd-pam/sd-pam(deleted)。

        第二個疑點是從本機連接到未知遠端IP的TCP連接： jira-wiki-nexus:55916->128.199.136.211:http。

3.2 淺析外連接

        連接外網的TCP連接很常見，先從第二個未知TCP連接下手。這個TCP連接指向HTTP埠，用瀏覽器打開網址，頁面顯示Mining Proxy Online。Mining，不是Mine，不就是挖礦嗎？它自我暴露了。

         換一個Google Chrome訪問網址看看，輸出還是Mining Proxy Online。

        再試一試curl命令，都說在挖礦，很誠實的樣子。

        上午懟黑客時，並沒有註意到Mining這個詞，只是猜測可能是挖礦，要不然找個“肉雞”幹嘛呢？

        百度一下，看看IP來自何方。百度雖然有很多槽點，但是引入的IP查詢工具還是實用的。查詢結果顯示遠端IP來自新加坡，是部署在海外的主機。而重啟主機前的一次lsof顯示，遠端IP來自美國。之後，殺死過sd-pam不下十次，它又頑固地出現，穩定地連接這個新加坡IP地址。

        接著，我想知道進程sd-pam的可執行程式藏身在什麼地方。用了find命令去找它，執行時間太長，一時沒耐住性子，ctrl+c掐斷了。

        好吧，先放過它。

3.3 調試失蹤客

        進程sd-pam是可執行的，那麼就可以用gdb來跟蹤調試，深入內部是不是可以窺探內幕。

        CentOS預設也沒有安裝程開源調試工具gdb，運行yum命令自動下載、安裝gdb。

1 # yum install -y gdb

        安裝好以後，啟動gdb，然後輸入attach PID（PID需要替換為實際進程號），觸碰sd-pam進程並掛載到gdb調試環境。輸出顯示/var/tmp/dbus/.sd-pam/sd-pam(deleted)，該進程的可執行文件不存在。

        消失的可執行程式，難道是揮刀刪掉自己了嗎？很詭異的現象。正常情況下，從可執行文件啟動進程後，可執行文件依然存在原處。因為操作系統創建進程時，未必完全載入可執行文件，可能分步載入，運行時仍可能從可執行文件讀數據段。進程能否刪除啟動的可執行文件？此處存疑。

        後續分析會揭露可執行文件消失的真相。

        因為想要儘快定位故障、解決問題，gdb調試暫告一段落。

        消失的可執行文件意味著sd-pam進程的主人不希望可執行文件被髮現，那麼可執行文件可能隱藏著不為人知的秘密。sd-pam是黑客進程的疑慮進一步加重。

3.4 解密怪腳本

        通過百度或谷歌搜索關鍵字sd-pam，所得搜索結果很少，看起來有關聯的搜索結果不過區區兩三條，點進去看詳情也毫不相干。如果黑客攻擊一說成立的話，那麼程式文件名是個性化量身定製的，同樣的攻擊程式在別的受攻擊伺服器，可        能會使用別的程式文件名。或者，也許這個攻擊程式剛出現，沒有形成規模和氣候，所以網上報告的信息較少。

        可執行程式位於目錄/var/tmp/dbus/.sd-pam/，這個目錄有兩個疑點：可執行目錄包含tmp，在Windows安裝程式時很常見，Linux 系統很少見；子目錄.sd-pam是隱藏目錄，命令ls -a才能顯示出來，ls是看不出來的。目錄的兩個疑點都指向，sd-pam程式的主人試圖掩蓋什麼，不想讓所寄居的雲伺服器的管理人員發現。

        嘗試進入目錄/var/tmp/dbus，有了新的發現：

1 # cd /var/tmp/dbus
2 
3 # ls -ltra
4 
5 # more sd-pam

        居然看到了sd-pam，不過sd-pam是一小段Shell腳本，用more命令查看文件內容：

        這個腳本做了4件事：

        S1、創建隱藏子目錄.sd-pam。子目錄與前面發現的可疑路徑吻合。

        S2、複製文件x86_64到隱藏子目錄.sd-pam，並改名為sd-pam。與前面發現消失的可執行文件完全一致。

        S3、啟動新複製的sd-pam程式，帶有參數-h sd-pam -c。懷疑是以父子進程監控的方式啟動：萬一子進程死亡，父進程依然能fork出新的子進程。這樣大大增加sd-pam程式存活的幾率。

        S4、刪除S1創建的子目錄.sd-pam，連同子目錄下可執行文件sd-pam也一併刪除。這就解釋了前面的謎團：sd-pam進程存在，而進程的可執行程式文件卻神秘地消失了。因為腳本sd-pam是以root用戶身份運行的，刪除jira用戶運行進程的可執行文件毫無壓力，無需提權。雖無根，仍運行。

        註意：這裡的sd-pam有兩個同名版本：一個是Shell腳本sd-pam；另一個是可執行文件sd-pam，由可執行文件x86_64複製、改名而來，不能混淆。

x86_64適用於64位的X86架構晶元，可以想象該程式可能還有x86（32位X86架構晶元）、ARM32、ARM64和SPARC64等多種版本。

3.5 斬斷無形手

        前面提到，JIRA雲伺服器重新啟動後，sd-pam進程像幽靈一樣存在，揮之不去，牢牢占據CPU排行榜的首位。應該是有某一種機制能夠自動啟動sd-pam。

        已知的第一種機制是Linux後臺服務管理，在系統重新引導後會自動運行，這是Linux內部機制，潛伏的進程只要不被髮現，完全可以長期潛伏、定期送出有價值的信息。

        第二種機制就要複雜得多，來自互聯網的漏洞掃描程式，定時掃描雲伺服器的漏洞，發現漏洞後重新植入木馬。第二種機制容易受到網路安全屏障的阻隔，頻繁的掃描也容易被網路安全嗅探器發現，主要的雲計算中心都提供免費或收費的服務，嗅探、發現漏洞和外部攻擊。所以第二種機制/方法，不適合監控已植入木馬雲伺服器，更適合於初次尋找漏洞，或者地毯式搜索雲伺服器漏洞。

        在不重啟雲伺服器時，直接殺死sd-pam進程能快速的停止木馬進程。Linux命令kill傳遞信號參數SIGKILL或者9能立即殺死進程。

1  # kill -9 11320

        殺死進程後，CPU利用率立即下降到個位數。遺憾的是一兩分鐘後，sd-pam幽靈又出現在top命令輸出榜首。

        一兩分鐘內重啟進程，Linux Service服務監控管理能做到，但又不符合其行為方式。因為殺死sd-pam進程後，服務監控進程立即能感知到，不會等待，而會立即重啟新的sd-pam進程。

        有另一種Linux定時任務機制，能做到精準到時分，重啟後臺任務。Linux後臺服務crond，定時被喚醒，按照crontab表定義的時間表啟動後臺任務。

        先看看crontab的時間表：

1 # crontab -l
2 
3  …
4 
5  * * * * * /var/tmp/dbus/./x86_64

圖 Crontab定時啟動、檢查進程sd-pam

        又發現了x86_64的蹤跡。前面說到，x86_64就是sd-pam的化身和前身，sd-pam是x86_64的拷貝。自動忽略crontab表的第一條時間任務。

        定時任務crontab的任務項由五個時間列和一個命令列組成。五個時間列分別是分鐘、小時、星期、日、月，如果是數字表示具體時點，如果是*表示所有的時間點。

        五個時間列都是*，表示每月每日每星期每時每分，都會運行命令列的程式。翻譯過來就是：7*24小時的每一分每一秒都在運行，榨乾雲伺服器的每一分計算力。夠狠的吧，比996厲害吧，669也不過如此。

        x86_64能幹什麼，我有點好奇，忍不住手欠，運行了一把。反正CPU已經4個100了，也不會更壞了。

1 # x86_64

        提示程式已經在運行。x86_64有自我監控的功能，只運行一份sd-pam進程副本。Crontab里的x86_64應該就是監控sd-pam存活狀態的幕後推手。

        先在最前面添加#號，註釋掉crontab定時任務。斬斷一雙幕後黑手，那麼木馬程式sd-pam就會像孤兒一樣。再殺了孤兒sd-pam，預期木馬就會清除了。

1 # crontab -e

        編輯並保存crontab，立即生效。

        然後，執行kill -9 PID，果然sd-pam幽靈消失了好一會兒。好一會兒是多久，沒讀秒，沒數數，我也不知道是多久。哈哈。

        在徹底擊敗敵人之前，歡樂的日子總是短暫的。過了好一會兒，sd-pam幽靈又出現了。有些氣餒了，怎麼辦？不過，還沒有動絕殺之前，怎麼能輕言失敗呢？！

3.6 拔除木馬根

        回顧一下，不管是Linux服務管理還是Linux Crontab，都要調用/var/tmp/dbus/目錄下的程式，那麼讓它們找不到這個目錄，是不是它們就抓瞎了呢？說乾就乾，斬草要除根，dbus就是sd-pam的根。

1 # cd /var/tmp
2 
3 # mv dbus dbus_bak
4 
5 # kill -9 PID   ## PID替換為sd-pam進程的進程號

        這裡沒有直接刪除dbus目錄，而是給目錄改名，使之找不到dbus目錄，與刪除目錄效果是一樣的。黑客攻擊現場留下活證據，可作為呈堂證供。哈哈。

        如此操作之後，幽靈進程再也沒有出現過。又重啟了雲伺服器，幽靈進程也沒有出現了，空閑時CPU利用率穩定在個位數。

圖 清除木馬後雲伺服器進程列表

        從瀏覽器點擊JIRA控制台，在後臺監控雲伺服器，看著JIRA（Java）進程歡快地吞噬CPU，我也長舒了一口，心裡的石頭落地了。

        木馬程式是被根除了，但是黑客是怎麼攻進來的，雲伺服器漏洞在哪裡，黑客會不會輕車熟路開始下一波攻擊，我們一無所知。如果您對此感興趣，請看下一節。

        下文預告：
        4、探秘黑客蹤
        4.1 寓言公寓樓
        4.2 查詢訪客志
        4.3 孜孜找不同
        4.4 驚現無秘碼
        4.5 緊鎖失密門
        4.6 探尋黑客蹤
        4.7 解讀黑客術
        4.8 還原入侵圖
        5、修複雲主機
        6、安全警示鐘
        7、詳解木馬源
        8、小結