作者:哈茲本德
來源:FreeBuf
0×00 前言
故事是這樣的,大年初一,客戶反應他們伺服器無法訪問,檢視路由,發現某oracle+tomcat伺服器UDP流量超大,把頻寬佔完了,過年嘛,客戶那邊先找了當地的技術人員弄了幾天沒搞定,然後沒辦法大年初三的找我們弄…顧客是上帝!
其實吧以前也遇到過這類攻擊,當時某IDC都被打癱了,只不過馬兒不在我們的裝置上,所以沒過多關註…
0×01 查詢木馬
首先SSH登陸,top檢視行程,發現奇怪名字的命令gejfhzthbp,一看就感覺有問題。
lsof –c gejfhzthbp
檢視關聯檔案,發現對外的tcp連線,不知道是不是反向shell…
執行命令
Whereis gejfhzthbp ls -al gejfhzthbp
檢視檔案路徑。並檢視檔案建立時間,與入侵時間吻合。
順便把檔案複製下來放到kali虛擬機器試了下威力,幾秒鐘的結果如下…
之前還以為是外國人搞的,這應該能證明是國人搞的了…
0×02 恢復業務
首先kill行程,結果肯定沒那麼簡單,行程換個名字又出來了
中間嘗試過很多過程,ps –ef |grep 發現父行程每次不一樣,關聯行程有時是sshd,有時是pwd,ls,中間裝了個VNC連線,然後關閉ssh服務,同樣無效,而且kill幾次之後發現父行程變成了1 ,水平有限,生產伺服器,還是保守治療,以業務為主吧…
既然被人入侵了,首先還是把防火牆的SSH對映關掉吧,畢竟伺服器現在還要用,還是寫幾條iptables規則吧
iptables -A OUTPUT -o lo -j ACCEPT
允許本機訪問本機
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
允許主動訪問本伺服器的請求
iptables -A OUTPUT –p tcp –d 192.168.1.235 -jACCEPT
允許伺服器主動訪問的IP白名單
iptables -A DROP
拒絕對外訪問
到此,業務恢復正常。
0×03 查詢原因
其實原因一開始我就意識到了是SSH的問題,只是先要幫人把業務恢復了再說,web埠方面就只有tomcat的,web漏洞都查過了,什麼struts2,manager頁面,還有一些常規web漏洞均不會存在,除非有0day…. Oracle也不外連,只有個SSH
基於這一點,我直接查root賬戶ssh登陸日誌,翻啊翻,終於….
cd /var/log less secure
如上圖,使用印尼IP爆破成功,而後面伺服器內網IP登陸竟然是失敗,問了客戶,算是明白了怎麼回事,他們年底加裝置,給伺服器臨時改了弱密碼方便各種第三方技術人員除錯,然後估計忘了改回來,結果悲劇了,被壞人登陸了不說,root密碼還被改,自己都登不上…不知道他們老闆知不知道…
繼續檢視history檔案,看人家都幹了些什麼。
壞人的操作過程基本就在這裡了,他執行了好多指令碼,誰知道他幹了多少事,還是建議客戶重灌系統吧…
0×04 後記
主要還是自己經驗尚淺,linux運維玩的不熟,不知道怎麼把馬兒徹底趕出去…大牛勿噴。
《Linux雲端計算及運維架構師高薪實戰班》2018年11月26日即將開課中,120天衝擊Linux運維年薪30萬,改變速約~~~~
*宣告:推送內容及圖片來源於網路,部分內容會有所改動,版權歸原作者所有,如來源資訊有誤或侵犯權益,請聯絡我們刪除或授權事宜。
– END –