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自動下載安裝。
# yum install -y lsof
安裝好以後迫不及待想看看sd-pam都幹了啥。輸入lsof命令，帶參數-p PID，PID是進程ID。
# 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。
# 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，有了新的發現：
# cd /var/tmp/dbus
# ls -ltra
# 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能立即殺死進程。
# kill -9 11320
殺死進程後，CPU利用率立即下降到個位數。遺憾的是一兩分鐘後，sd-pam幽靈又出現在top命令輸出榜首。
一兩分鐘內重啟進程，Linux Service服務監控管理能做到，但又不符合其行為方式。因為殺死sd-pam進程後，服務監控進程立即能感知到，不會等待，而會立即重啟新的sd-pam進程。
有另一種Linux定時任務機制，能做到精準到時分，重啟後臺任務。Linux後臺服務crond，定時被喚醒，按照crontab表定義的時間表啟動後臺任務。
先看看crontab的時間表：
# crontab -l
…
* * * * * /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了，也不會更壞了。
# x86_64
提示程序已經在運行。x86_64有自我監控的功能，只運行一份sd-pam進程副本。Crontab裡的x86_64應該就是監控sd-pam存活狀態的幕後推手。
先在最前面添加#號，註釋掉crontab定時任務。斬斷一雙幕後黑手，那麼木馬程序sd-pam就會像孤兒一樣。再殺了孤兒sd-pam，預期木馬就會清除了。
# crontab -e
編輯並保存crontab，立即生效。
然後，執行kill -9 PID，果然sd-pam幽靈消失了好一會兒。好一會兒是多久，沒讀秒，沒數數，我也不知道是多久。哈哈。
在徹底擊敗敵人之前，歡樂的日子總是短暫的。過了好一會兒，sd-pam幽靈又出現了。有些氣餒了，怎麼辦？不過，還沒有動絕殺之前，怎麼能輕言失敗呢？！
3.6 拔除木馬根
回顧一下，不管是Linux服務管理還是Linux Crontab，都要調用/var/tmp/dbus/目錄下的程序，那麼讓它們找不到這個目錄，是不是它們就抓瞎了呢？說幹就幹，斬草要除根，dbus就是sd-pam的根。
# cd /var/tmp
# mv dbus dbus_bak
# 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、小結
原文鏈接：
https://mp.weixin.qq.com/s/DLGHw3wLUgzd_2XhQ3oVzA
關於睿雲智合
深圳睿雲智合科技有限公司成立於2012年，總部位於深圳，並分別在成都、深圳設立了研發中心，北京、上海設立了分支機構，核心骨幹人員全部為來自金融、科技行業知名企業資深業務專家、技術專家。早期專注於為中國金融保險等大型企業提供創新技術、電子商務、CRM等領域專業諮詢服務。
自2016年始，在率先將容器技術引進到中國保險行業客戶後，公司組建了專業的容器技術產品研發和實施服務團隊，旨在幫助中國金融行業客戶將容器創新技術應用於企業信息技術支持業務發展的基礎能力改善與提升，成為中國金融保險行業容器技術服務領導品牌。
此外，憑藉多年來在呼叫中心領域的業務經驗與技術積累，睿雲智合率先在業界推出基於開源軟交換平臺FreeSwitch的微服務架構多媒體數字化業務平臺，將語音、視頻、webchat、微信、微博等多種客戶接觸渠道集成，實現客戶統一接入、精準識別、智能路由的CRM策略，並以容器化治理來支持平臺的全應用生命週期管理，顯著提升了數字化業務處理的靈活、高效、彈性、穩定等特性，為幫助傳統企業向“以客戶為中心”的數字化業務轉型提供完美的一站式整體解決方案。
客戶與合作伙伴
閱讀更多 睿雲智合Wise2C 的文章
