發布日期：2017/4/21

摘要： 中介交易 seo診斷 淘寶客 站長團購 云主機 A5外包 每一個高手在成長路上, 都需要與墻作足夠的對抗. 要么你成功, 站在世界之顛, 然后盡情吸取到的知識; 或者或被它打趴下, 成為蕓

　

 

每一個高手在成長路上, 都需要與墻作足夠的對抗. 要么你成功, 站在世界之顛, 然后盡情吸取到的知識; 或者或被它打趴下, 成為蕓蕓眾生中的一人, 然后對它習以為常.

我也不例外.

前不久, 我剛在我的服務器上自行架好了自己的 "梯子". 這正是從 "梯子" 開始的故事.

開幕

夜已經深了, 我依然坐在電腦, 思索著一件事: 為什么倏忽之間, 歷來運行的 "梯子", 倏忽就這么卡呢? 莫非已經被 "墻" 發現并限制了?

我不甘心地想, 這不可能, 我隱藏的這么好, 這么低調, 不會是我.

我拿出手中好愛的工具: ping.

開始了我的檢測之旅.

 

60% 丟包, 這太夸張了, 這樣的網絡環境簡直比帝都的交通環境還差千倍. 我在想.

試試另一個利器 traceroute 吧, 只有跳是通的, F**K, 果然是世界的局域網絡, 運營商也敢非法丟棄我的檢測包, 這個檢測毫無收獲.

但是, 看著我的 "梯子" 在云層搖搖晃晃(丟包), 我就心生決意: 不在對抗中成功, 就在對抗中消亡.

正在無所措時, "梯子" 所在的服務商給給我好愛的 Gmail 倏忽發送了一封至關主要的郵件, 上面赫然寫道:

 

啊, 即將成為高手那種敏銳的第六感, 讓我覺得, 我可能錯怪 "墻" 了, 我可能被黑了.

檢測

一陣餓意, 讓我清醒了不少, 果然, 有些高手發明的 "輕斷食" 療法特別很是有用, 讓我離高手更進了一步.

"我一定要把對手揪出來", 心里暗暗下決定.

ssh root@myblog.me

我開始連接到我的服務器, 步, 先從登錄日志開始.

這是一個特別很是聰明的做法:

# whoroot pts/2 2015-01-20 3:00 (xx.xx.xx.xx)

嗯, 只有我一個人, 并沒有抓住黑客的現行. "我想他不會這么笨, 讓我當場拿住他", 心里暗想.

 

繼續諳練地檢查著有誰登錄過系統, 通過 ip1381683 檢測著 IP 的來源. 效果, 全是我這里的 IP, 沒有人!!!

莫非我弄錯了? 不是被黑了嗎?

不行, 繼續看登錄日志.

 

看到這么多 ssh 爆破登錄日志, 心里一陣涼意, 果然在互聯網上混, 時刻要小心遠方各種暗器. 岑寂一下, 慢慢找找看.

花了幾十分鐘之后, 除了各種用戶名密碼的登錄失敗外, 并沒有通過密碼登錄成功的日志, 全無新的發現.

心里暗想, "對手也不弱嘛."

不過, 還有一個線索沒有檢查過: "目前服務器的流量仍然很高"

是時候運用我手中的核心武器了.

發現

目前思路照舊很清晰的, 要定位到底是哪個進程導致的高流量, 然后通過它的行為, 分析是否是黑客掛的馬?

OK, 開始行動:

下載 iftop, 打開系統的流量面板, 10秒之后, 流量面板開始準確顯示流量, 我的流量峰值高達 100mb/s. 調整一些飭令參數, 顯示端口與 IP 信息.

iftop -nP

流量面板顯示出是從我的服務器往外流出流量, 先從 30157 端口開始往外發送, 幾秒之后, 就會循環切到 30000 - 50000 之間的一個端口繼續發. 是 UDP 流量. 我斷言.

果然, 再通過 netstat -anp 來檢測打開端口情況, 發現并沒有 TCP 上的狀況, 確認了我的斷言.

( UDP 流量是可以無狀況的, 可以快速切換, TCP 反之, 可以通過工具抓到鏈接狀況 )

但不幸的是, 這兩個工具并不能顯示出來是哪個進程作的鬼. 看來只有一個個看了.

ps aux

進程并不多, 很快就看完了, 有兩個可疑進程:

ruby 5162 0.0 5.0 286128 102200 ? Sl 02:58 2:20 /usr/sbin/httpd -c ./init -d /home/ruby/lib/2

111 3033 0.0 5.0 1 2017 ? Sl 02:58 2:20 /tmp/freeBSD /tmp/freeBSD 1

第1點, 我使用的是 nginx 而不是 apache, 這里的 httpd 特別很是可疑. 第2點, freeBSD 顯明是一個偽裝, 進程的權限也令人可疑.

至此, 已經確認, 我的服務器已經被黑了. 接下來, 是時候對決的時候了.

對決

第1點的進程信息有一個目錄特別很是可疑, 在 /home/ruby/lib, 這里是我的個人目錄, 怎么會出現在這里的參數里呢?

進去看看: cd /home/ruby/lib

 

大吃一驚, 第六感告訴我, 這命名, 這習慣, 是一個黑客作為, 這不是我寫的東西, 細心看看.

 

Oh no, 一個木馬程序赫然在目, 這是一個特別很是顯明的反向連接木馬:

只要你把服務器打開, 它便會啟動, 并主動連接到黑客指定的服務器, 報告黑客已經上線, 然后等待指令. 一旦有指令收到, 便會用自己控制的權限運行對應的程序. 特別很是可怕.

繼續看, 它的配置文件如下:

 

這便是對手的反向連接的 IRC 地址, "這小子還真牛啊", 我心想, "他知道, 這樣的 IRC 地址我根本無法進一步追蹤."

現在, 被黑的事實已經確認, 卻讓我更憂慮的事情來了:

1、他有沒有控制到我的 root 權限

一旦被控制了 root 權限, 系統就難于清理了, 因為他可以在任意位置插入自己的木馬, 例如啟動時, 驅動, 替代一個飭令, 隱藏在某個目錄.

而且, 可以手動清理日志, 讓你無法知道對方都干了什么, 這樣子, 你就只能重裝系統了.

2、他是如何黑進我的服務器

不能知道對方是如何黑的, 就無法制訂有用的防御策略, 這是特別很是可怕的.

不過, 我知道, 我離真相已經越來越近了.

繼續翻看他的木馬程序, 發現一個特別很是有趣的東西: h.c.

里面注釋上寫著:

 

哈哈, psf 可翻譯為進程堆棧偽造器. 顧名思義, 它是一個期騙 ps, top 飭令的指令輸出的一個小工具.

細心查看它的說明, 可以發現:

1、無須 root 權限, 即可讓你指定的進程偽造成任何一個進程名字.

2、ps, top, 許多進程監控工具都會被期騙.

它的原理也許如下:

在 main 函數里面(如下)的參數,

int main(int argc, char *argv[])

可以繼續調用以下 execv 接口, 而 path 是可以與 main() 里的 agrv[0] 不一致, 可以精心構造的, 這樣可以導致許多進程監控工具出現異常情況, 顯示出精心構造的參數.

int execv( const char *path, char *const argv[])

看到這個工具, 我反而將之前的擔擾悉數放下了: 用這點小伎倆來騙我, 說明你很可能沒有拿到 root 權限.

我仿佛已經聽到對方嘆氣的聲音, 但又仿佛不是, 彷佛有一點點笑聲.

不管那么多了, 下一步就要了他的命, 我在想.

挖掘

檢查系統核心信息:

# 檢查用戶信息是否正常

cat /etc/passwd

# 檢查系統文件是否被替代

find / -user 122 | xargs ls -l

一切顯示正常, 那么, 系統很可能是沒有被動到 root 的, 是時候找出被黑的原因了.

從另一個進程的線索下手.

進程號 111, 特別很是特殊, 從剛才的用戶信息可以看到, 這個用戶號屬于: elasticsearch.

原來如此, 這個提醒信息太主要了, 此刻, 我還記得之前為了安裝 railsgirlschina1683, 使用了campo3, 安裝了它的依靠 elasticsearch, 而之前 Rei 專門發郵件告訴過我: 這貨可能有遠程執行漏洞.

舛錯啊, 我已經打開了 ufw 防火墻了.

# ufw status

Status: inactive

什么, 沒有打開? 心中一絲涼意侵入骨髓, 我的服務器竟然在嚴格的互聯網環境上裸奔了這么久. 查看操作日志, 發現自從 1 月 8 號起, 防火墻就沒有打開過.

而且, 是我親自關閉了它. 難怪, 他的入侵成功日志正是 1 月 8 號.

此刻, 這位黑客的入侵手段幾乎已經真相大白: 通過 elasticsearch 遠程執行漏洞掃描工具掃進了我的服務器, 再運行了提權工具發現了 /home/ruby/ 目錄是可寫的.

此時, 他很聰明的偽裝了它的木馬, 雖然沒有拿到 root 權限, 但仍然可以輕易的干掉我的博客進程( 雖然他沒這么做 ). 還可以隨時讓我的服務器成為它的幫兇, 成為二次跳板, 或者對無辜者發動 DDOS 攻擊.

而我, 也有一絲絲的僥幸, elasticsearch 并沒有跑在 root 權限下, 而是使用了 111 號用戶, 所以這次攻擊他的好好收獲也只能是, 獲得我 ruby 用戶的權限, 把我的服務器納入他的肉雞, 為他以后更大規模的行動埋下伏筆.

需要增補點能量了, 我在想, 剛才煮好的泡面已經到了嘴邊.

"假如我成為黑客, 我一定通過他的反向代理木馬黑曩昔", 我一邊吃著一路在想, "當務之急, 照舊先清理這些木馬吧."

清理

1、關閉源頭

先打開防火墻: ufw enable.

清理 crontabs: crontab -l, rm /var/spool/cron/crontabs/ruby

殺掉木馬進程: kill pid

2、處理漏洞

按照 elasticsearch 官方處理建議, 將默認的監聽 IP 設定在 127.0.0.1, 關閉動態執行腳本能力:script.disable_dynamic: true ( 均在它的配置文件中完成 )

殺掉已被成功攻擊的 elasticsearch 進程和子進程: kill -9 xxx

3、加固

看來, 離高手還差了不少, 我心在想, 以下措施要補救一下:

3.1 用戶目錄權限

之前, 采用 useradd 的默認用戶目錄權限 644, 許可任何用戶進入, 才導致這個黑客得以入侵成功. 我把它關閉: chmod 700 /home/ruby

3.2 web 漏洞掃描

我需要在本地針對我的服務器做一些漏洞掃描.

3.3 防火墻保證開啟

在 /etc/rc.local 加入: ufw enable

3.4 升級系統

說到這里, 馬上兩條飭令搞定:

apt-get update

apt-get upgrade

后記

隨著流量的正常回落, 看到那我好心愛的 ping 上面好地顯示著

 

我的 "梯子" 又穩定地回來了.

我覺得, 我離高手又近了一步. 倏忽, 顯示器上開始緩慢的出現

 

我知道, 對方又回來了.

( 情節有小部分虛構, 如有相通, 純屬巧合 )