故事是這樣的，大年初一，客戶反應他們服務器無法訪問，查看路由，發現某oracle+tomcat服務器UDP流量超大，把帶寬占完了，過年嘛，客戶那邊先找了當地的技術人員弄了幾天沒搞定，然后沒辦法大年初三的找我們弄…顧客是上帝！

其實吧以前也遇到過這類攻擊，當時某IDC都被打癱了，只不過馬兒不在我們的設備上，所以沒過多關注…

0×01 查找木馬

首先SSH登陸，top查看進程，發現奇怪名字的命令gejfhzthbp,一看就感覺有問題。

lsof–cgejfhzthbp

查看關聯文件，發現對外的tcp連接，不知道是不是反向shell…

執行命令

Whereisgejfhzthbp ls-algejfhzthbp

查看文件路徑。并查看文件創建時間，與入侵時間吻合。

順便把文件拷貝下來放到kali虛擬機試了下威力，幾秒鐘的結果如下…

之前還以為是外國人搞的，這應該能證明是國人搞的了…

0×02 恢復業務

首先kill進程，結果肯定沒那么簡單，進程換個名字又出來了

中間嘗試過很多過程，ps –ef |grep 發現父進程每次不一樣，關聯進程有時是sshd，有時是pwd，ls，中間裝了個VNC連接，然后關閉ssh服務，同樣無效，而且kill幾次之后發現父進程變成了1 ，水平有限，生產服務器，還是保守治療，以業務為主吧…

既然被人入侵了，首先還是把防火墻的SSH映射關掉吧，畢竟服務器現在還要用，還是寫幾條iptables規則吧

iptables-AOUTPUT-olo-jACCEPT

允許本機訪問本機

iptables-AOUTPUT-mstate--stateESTABLISHED-jACCEPT

允許主動訪問本服務器的請求

iptables-AOUTPUT–ptcp–d192.168.1.235-jACCEPT

允許服務器主動訪問的IP白名單

iptables-ADROP

拒絕對外訪問

到此，業務恢復正常。

0×03 查找原因

其實原因一開始我就意識到了是SSH的問題，只是先要幫人把業務恢復了再說，web端口方面就只有tomcat的，web漏洞都查過了，什么struts2，manager頁面，還有一些常規web漏洞均不會存在，除非有0day…. Oracle也不外連，只有個SSH

基于這一點，我直接查root賬戶ssh登陸日志，翻啊翻，終于….

cd/var/loglesssecure

如上圖，使用印尼IP爆破成功，而后面服務器內網IP登陸竟然是失敗，問了客戶，算是明白了怎么回事，他們年底加設備，給服務器臨時改了弱密碼方便各種第三方技術人員調試，然后估計忘了改回來，結果悲劇了，被壞人登陸了不說，root密碼還被改，自己都登不上…不知道他們老板知不知道…

繼續查看history文件，看人家都干了些什么。

壞人的操作過程基本就在這里了，他執行了好多腳本，誰知道他干了多少事，還是建議客戶重裝系統吧…

0×04 后記

主要還是自己經驗尚淺，linux運維玩的不熟，不知道怎么把馬兒徹底趕出去…大牛勿噴。