云服务器反黑客入侵攻防实录（一）
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%?？蓱z的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，所得搜索結果很少，看起來有關聯的搜索結果不過區區兩三條，點進去看詳情也毫不相干。如果黑客攻擊一說成立的話，那么程序文件名是個性化量身定制的，同樣的攻擊程序在別的受攻擊服務器，可? ? ? ??能會使用別的程序文件名?；蛘?#xff0c;也許這個攻擊程序剛出現，沒有形成規模和氣候，所以網上報告的信息較少。
? ? ? ??可執行程序位于目錄/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、小結
?
轉載于:https://www.cnblogs.com/solomonxu/p/10889928.html
總結
以上是生活随笔為你收集整理的云服务器反黑客入侵攻防实录（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： unity打包的windows程序运行权
- 下一篇： RouterOS配置【网络工程】（保姆级