雲服務器反黑客入侵攻防實錄（一）

一、引言

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

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

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

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

        事實果然如此嗎？

        閒話少敘，咱們直奔主題，欣賞一場紅客、黑客攻防戰的前因後果和驚險場景。

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

 

二、雲機見疑雲

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.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件事：

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

        S二、複製文件x86_64到隱藏子目錄.sd-pam，並更名爲sd-pam。與前面發現消失的可執行文件徹底一致。

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

        S四、刪除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架構芯片）、ARM3二、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.1 寓言公寓樓        4.2 查詢訪客志        4.3 孜孜找不一樣        4.4 驚現無祕碼        4.5 緊鎖失密門        4.6 探尋黑客蹤        4.7 解讀黑客術        4.8 還原入侵圖        五、修復雲主機        六、安全警示鐘        七、詳解木馬源        八、小結