您好,登錄后才能下訂單哦!
這篇文章主要講解了“Linux應急響應怎么處理”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Linux應急響應怎么處理”吧!
客戶的監控系統發現有異常行為,我臨時頂替應急的同事處理一下。
連接到服務器,首先通過ps auxef 和 netstat -tulnp兩個命令查看異常進程信息,果然發現了兩個異常進程 xmp 和 [atd]
通過 ls -al /proc/[pid]/exe 查看這兩個進程的程序位置,其中[pid]為xmp 和 [atd]兩個進程的進程id
最后確認xmp在 /lib/PROXY/ 目錄下,該目錄下有兩個文件,一個是xmp,一個是config.json [atd]在 /var/spool/at/.sqe/ 目錄下,該目錄下有很多文件,包括 [atd], cyc.acc, seed, stealth, randfiles 等
把兩個進程上傳到virustotal,均超過一半的殺毒軟件報毒
執行stat /lib/PROXY/xmp, stat /var/spool/at/.sqe/[atd], 發現這兩個文件的Change time都是在23,24這兩天
所以懷疑應該是23日左右被入侵了,查看 history, /var/log/secure 發現文件都被清空了,查看 /root/.ssh/known_hosts 發現600多條記錄。 找不到蛛絲馬跡,只能以為是ssh暴破登錄了。
重啟服務器后,發現[atd]進程依然存在,應該是加入了開機啟動,我采用了比較粗暴的方式定位開機啟動,在根目錄執行
grep -rn '\[atd\]' *
皇天不負苦心人,果然被我找到,在/bin/seed 中有啟動[atd]的代碼,這個腳本非常簡單,只是cd到/var/spool/at/.sqe/然后執行[atd]
接下來我去/etc目錄,繼續執行 grep -rn seed *, 這條命令執行結果很多行,逐個過濾后,發現在/etc/rc.sysinit 某一行,新增了一個命令seed,這樣就能解釋為什么[atd]能開機啟動了,然而并沒有找到xmp的開機啟動項,xmp也不會隨著服務器重啟自啟動
看[atd]的進程名,猜測這是一個執行定時任務進程,這個進程監聽udp端口,猜測應該是攻擊者通過這個進程控制服務器,執行命令,包括啟動xmp
再回過頭來看xmp,通過config.json文件可以知道這是一個門羅幣挖礦病毒
"pools": [ { "algo": null, "coin": "monero", "url": "pool.supportxmr.com:80", "user": "44wuEu1F6UMDzAu2ByHjKGRR4WiU33zJW6bdHPrHaHbLWYHTyqJUiqG47yvaJof8gfd1HbMR1WhmsDJcX7yhVx8bU8PHRtBx", "pass": "HERCULE", "rig-id": null, "keepalive": true, "enabled": true, "tls": false, "tls-fingerprint": null, "daemon": false } ],
最后清除過程很簡單,刪除/etc/rc.sysinit seed那一行,刪除/bin/seed,刪除/lib/PROXY,刪除/var/spool/at/.sqe/
加固方法為把一些不必要的端口配置iptables拒絕所有連接請求,修改ssh密碼為不常見的強密碼。
言歸正傳,應急響應的標準流程應該如何? Security+給出了一套流程:
Preparation –> Identification –> Containment –> Eradication –> Recovery –> Lessons learned
以上面的背景里的例子來說,Preparation就是一線人員提供我接入服務器的渠道。Identification就是我發現xmp和[atd]確認服務器被感染病毒。Containment把所有可能受影響的系統都隔離,包括上述known_hosts 發現600多臺主機。Eradication根據上面的清除清除所有受影響的主機。Recovery是在清除之后,解除隔離,讓業務系統恢復。Lessons learned總結反思事件,一方面從源頭上減小安全事件的發現,另一方面提升應急響應的效率。
上面的應急響應還是非常片面的,我搜羅了一系列網友分享的應急響應經驗,整理成章方便以后查閱。
我把應急響應流程分為三個部分,分別是 【1】入侵現場,【2】攻擊維持,【3】入侵原因,下面我將從這三個方面展開
所謂入侵現場,是指服務器被懷疑中毒的現場環境,一般來說,服務器被懷疑中毒都有異常現象,比如異常的網絡流量,異常的端口,cpu/內存占用率異常等等。
為了避免系統命令被替換,預加載動態庫等問題,下載靜態鏈接版本的 busybox來執行調查。或者下載源碼編譯 busybox源碼,注意編譯的時候采用靜態鏈接編譯。
查看網絡監聽的tcp和udp端口及對應的進程信息:busybox netstat -tulnp
查看網絡所有的網絡連接:busybox netstat -anp
通過網絡監聽及網絡連接來輔助定位異常進程
注意如果攻擊者獲取到了Root權限,被植入內核或者系統層Rootkit的話,連接是可以被隱藏的。
如果系統被發現異常,那很大概率是有異常進程在執行
通過ps查看進程信息
busybox ps / ps -aux / ps -ef
通過grep -v 過濾掉一些正常進程,再逐個排查異常進程
通過top命令查看cpu/內存占用異常的進程
busybox top
查找ps中隱藏的進程,通過對比proc中的進程id和ps中的進程id,判斷是否有些進程在proc中但不在ps中顯示
ps -ef | awk '{print $2}' | sort -n | uniq > ps.p ls /proc | sort -n |uniq > proc.p diff ps.p proc.p
執行pstree查看進程樹:pstree -p
注意如果攻擊者獲取到了Root權限,被植入內核或者系統層Rootkit的話,可以把進程隱藏的更徹底。參考文獻[1]做了部分的擴展,供讀者參考。
首先執行busybox stat /usr/bin/ls, busybox stat /usr/bin/lsof, busybox stat /usr/bin/stat, 確認這幾個文件沒有被修改過
ls
排查 可讀寫執行目錄
ls –alt /tmp/; ls -alt /var/tmp; ls -alt /dev/shm
排序 $PATH 環境變量下的目錄的文件,比如
ls -alt /bin, ls -alt /sbin, ls -alt /usr/bin, ls -alt /usr/sbin 等
遞歸查看所有文件
ls -aR
stat
針對任何的可以文件,都通過stat命令查看各個時間點。
lsof
另外可以通過lsof命令聯合查看,lsof常用options如下
lsof 列出所有進程調用
lsof abc.txt 顯示開啟文件abc.txt的進程
lsof -c abc 顯示abc進程現在打開的文件
lsof -p 1234 列出進程號為1234的進程所打開的文件
lsof -g gid 顯示歸屬gid的進程情況
lsof +d /usr/local/ 顯示目錄下被進程開啟的文件
lsof +D /usr/local/ 同上,但是會搜索目錄下的目錄,時間較長
lsof -d 4 顯示使用fd為4的進程
lsof -i :port 檢查哪個進程使用這個端口
lsof -i 用以顯示符合條件的進程情況
find
通過find命令來查找近期新增/修改文件
例如要查找24小時內被修改的JSP文件
最后一次修改發生在距離當前時間n24小時至(n+1)24 小時 find ./ -mtime 0 -name "*.jsp"
查找72小時內新增的文件
find / -ctime -2
查找特殊權限的文件
find / *.jsp -perm 4777
diff
用diff命令把重要的目錄做對比,分別對比入侵環境和純凈環境下的不同
比如把連個環境的重要目錄都拷貝到PC-x中,利用下面的命令對比兩個目錄
diff -r {dir 1} {dir 2}
若發現有非法進程,運行ls -l /proc/$PID/exe或file /proc/$PID/exe($PID 為異常進程的pid),查看下 pid 所對應的進程文件路徑。
運行cat /proc/$PID/cmdline查看進程執行的命令及參數
通過file命令查看惡意程序文件類型,比如:file /tmp/.sh
如果是ELF文件,可以通過strings查看ELF里帶的字符串,可能會泄露一些信息,比如 stirngs /tmp/.elf
如果碰到惡意程序被刪除,可以通過內存轉儲的方式從內存中導出惡意程序
從內存拷貝恢復被刪除文件 cp /proc/[pid]/exe /tmp/malware.dump 導出進程內存 cat /proc/[pid]/maps 7ff48bb5d000-7ff48bb5e000 gdb --pid [pid] dump memory /tmp/malware.dump 0x7ff48bb5d000 0x7ff48bb5e000
通過 stat命令查看惡意程序的Access,Modify,Change時間,了解系統大概是什么時間被入侵。
可以把可疑的惡意程序或內存轉儲的程序上傳到virustotal進行病毒掃描
其他可能用到的命令,比如strings, strace, lsattr, chattr -i, getfacl,setfacl等。
chkrootkit
使用方法:
wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz tar zxvf chkrootkit.tar.gz cd chkrootkit-0.53 make sense ./chkrootkit
rkhunter
使用方法:
wget https://nchc.dl.sourceforge.net/project/rkhunter/rkhunter/1.4.4/rkhunter-1.4.4.tar.gz 我測試的時候發現上面鏈接無法下載了,所以換了下面的鏈接 wget https://fossies.org/linux/privat/rkhunter-1.4.6.tar.gz tar -zxvf rkhunter-1.4.6.tar.gz cd rkhunter-1.4.6 ./installer.sh --install rkhunter -c
busybox cat ~/.bash_history
查看環境變量動態庫劫持
busybox echo $LD_PRELOAD
查看配置文件動態庫劫持
busybox cat /etc/ld.so.preload
如果不確定動態庫是不是惡意的,可以把動態庫上傳到virustotal檢測。
busybox cat /etc/passwd | grep -v nologin
busybox cat /etc/shadow
busybox stat /etc/passwd
busybox cat /etc/sudoers
查看服務器近期登錄的帳戶記錄:last
遍歷查看 /etc/ 目錄下的init開始的系列目錄及文件,以及rc開頭的系列目錄及文件
查看 /etc/init.d/目錄下的文件
查詢系統服務,特別是開機自啟動的服務
chkconfig –list
service –status-all
重點查看以下羅列的目錄及文件內容
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/*
/etc/cron.hourly/*
/etc/cron.monthly/*
/etc/cron.weekly/
/etc/anacrontab
/var/spool/cron/*
/var/spool/anacron/*
通過crontab -l羅列當前用戶的定時任務
查看內核模塊加載情況:lsmod
到 /root/.ssh 目錄下查看是否有公鑰,以及查看known_hosts文件,看本機通過ssh連接過哪些主機,很可能這些主機有一部分也被入侵了。
首先通過netstat查看對外開放的服務,確認這些服務(比如mysql,redis,zookeeper,tomcat等)是否有配置認證,認證使用的是否為弱密碼或者默認密碼。
查看這些服務的日志信息,看是否有入侵記錄。
日志包括系統日志和應用程序日志,系統日志存放在 /var/log 目錄下,應用程序日志需要看應用程序的具體配置
系統日志包括
/var/log/cron 記錄了系統定時任務相關的日志
/var/log/cups 記錄打印信息的日志
/var/log/dmesg 記錄了系統在開機時內核自檢的信息
/var/log/mailog 記錄郵件信息
/var/log/message 記錄系統重要信息的日志
/var/log/btmp 記錄錯誤登錄日志。 要使用lastb命令查看
/var/log/lastlog 記錄系統中所有用戶最后一次登錄時間的日志。 要使用lastlog命令查看
/var/log/wtmp 永久記錄所有用戶的登錄、注銷信息,同時記錄系統的啟動、重啟、關機事件。 要使用last命令查看
/var/log/utmp 記錄當前已經登錄的用戶信息。要使用w,who,users命令查看
/var/log/secure 記錄驗證和授權方面的信息,比如SSH登錄,su切換用戶,sudo授權
查看ssh登錄記錄
less /var/log/secure | grep 'Accepted'
大多數情況惡意進程的父進程都是1,而有些情況下惡意進程的父進程可能不是1,比如父進程是httpd,這種情況下,就可以大膽猜測攻擊者是通過利用父進程的漏洞達成攻擊。
通過命令ps -ef 查看進程的父進程pid也就是ppid
通過 ps auxef 查看惡意進程啟動的用戶,如果發現比如是mysql用戶啟動,那么就可以推斷是通過mysql服務入侵。
修改各個對我開放的服務密碼
限制對外開放的服務,如果不方便操作,則通過iptables限制可訪問的主機
升級系統組件或者服務使用到的中間件
感謝各位的閱讀,以上就是“Linux應急響應怎么處理”的內容了,經過本文的學習后,相信大家對Linux應急響應怎么處理這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。