1. 靶場練習的價值與解題思路1.1 做Linux-web靶場練的是什么先說個實話應急響應這個東西光看理論真的學不會。你背一萬句排查思路不如實際去一臺被入侵的機器上翻一遍日志、殺一遍進程、找一遍后門。應急響應靶場練習Linux-web-2這個題本質(zhì)就是給你一臺被攻破的Linux Web服務器讓你在最短時間內(nèi)還原攻擊者的完整路徑入口是哪里、拿到什么權限、留下了哪些持久化手段、現(xiàn)在系統(tǒng)還有沒有后門在跑。我做過不少這類模擬靶場的練習每次做完最大的感受是應急響應的核心不是殺毒軟件掃描一下而是重新回到攻擊者的視角把整條鏈路揪出來并掐斷它。這臺Linux-web-2的設計把所有常見的Web攻擊痕跡都塞進了一臺機器里惡意上傳、計劃任務、異常用戶、可疑進程、日志篡改等等。你從拿到題目到最終提交報告整個過程和真實生產(chǎn)環(huán)境出安全事件后的操作邏輯幾乎一致。這個靶場適合三類人剛入門安全運營的新人、準備參加護網(wǎng)或應急演練的藍隊人員、以及想驗證自己排查工具鏈是否靠譜的運維工程師。我用一臺閑置的模擬服務器配合快照還原反復練了三輪每一輪都能發(fā)現(xiàn)前一輪忽略的細節(jié)。下面我把完整操作過程和踩過的坑按順序?qū)懗鰜怼?.2 拿到題目后的第一反應是什么遇到這個靶場練習我建議先別急著登機器。先把題目環(huán)境給的提示信息理清楚目標IP、端口、服務類型、是否分配了賬號密碼。Linux-web-2這種命名方式一般意味著攻擊面集中在Web服務上但答案不一定在Web日志里系統(tǒng)層面的痕跡也藏著不少分。我當時的處理順序是先快照當前狀態(tài)防止排查過程中無意改動證據(jù)用系統(tǒng)自帶工具做基礎信息采集不急著裝第三方掃描器按入侵鏈路由淺入深排查從可疑進程、網(wǎng)絡連接開始再到文件、計劃任務、賬號最后復盤Web日志全程記錄時間線因為應急響應的報告核心就是時間線這里想強調(diào)一個很多人容易犯的錯誤上手就急著刪東西?？吹娇梢晌募R上刪除、看到可疑進程馬上kill結果日志還沒來得及采集線索全斷了。正確的做法是先做證據(jù)備份再分析最后才清理清理之后還要確認殘余進程。2. 環(huán)境準備與起手階段的排查工具2.1 模擬靶場的環(huán)境搭建與快照機制要做Linux-web-2這個靶場練習首先得有一個可復現(xiàn)的環(huán)境。很多新手直接拿虛擬機跑結果排查過程中防火墻策略改了、網(wǎng)絡斷掉、文件刪了下一次想復現(xiàn)就得從頭再來。我采用的方式是用VMware快照配合NAT網(wǎng)絡給靶機分配一個固定的內(nèi)網(wǎng)IP攻擊機用另一臺虛擬機或者宿主機模擬。有個容易被忽視的細節(jié)靶場的Web服務如果綁定在80端口你的排查工具和瀏覽器要能訪問到那就必須保證網(wǎng)絡連通但靶機又不能訪問外網(wǎng)。這一步可以手動封掉靶機的默認網(wǎng)關只保留和攻擊機之間的通信避免靶機上的惡意外聯(lián)真正打出去。靶場練習雖然環(huán)境是模擬的但行為習慣要養(yǎng)成生產(chǎn)環(huán)境的操作習慣這個很重要。具體準備配置項推薦值備注靶機系統(tǒng)Linux發(fā)行版這里用的某常見發(fā)行版內(nèi)核版本固定建議關閉自動更新Web服務Apache/Nginx PHP靶場核心入口網(wǎng)絡模式NAT關閉靶機外網(wǎng)訪問快照方案安裝完成后打一個干凈快照每次復現(xiàn)前還原到這個狀態(tài)2.2 起手階段快速采集系統(tǒng)基線信息登錄靶機之后不要急著翻Web目錄。先把一組基礎命令跑一遍保存輸出結果作為后續(xù)排查的比對基線。這個過程我一般控制在五分鐘以內(nèi)五分鐘后開始深入分析。# 收集系統(tǒng)基本概況 uname -a cat /etc/os-release uptime# 收集用戶與登錄記錄 cat /etc/passwd cat /etc/shadow last lastlog# 收集網(wǎng)絡與賬戶信息 ss -antlp ps aux --sort-%mem systemctl list-units --typeservice crontab -l ls -la /etc/cron.d /etc/cron.daily這些命令看起來簡單但每一類都能對應到一類常見的攻擊痕跡。比如 /etc/passwd 里多了個 uid0 的木馬賬戶ss -antlp 里看到進程連到一個不認識的IPps 里看到一個名字被改過的挖礦進程。這些就是靶場里藏的分數(shù)點。我還習慣把這幾條命令的輸出直接重定向到一個以時間戳命名的文件里mkdir -p /tmp/evidence/$(date %Y%m%d%H%M%S) cd /tmp/evidence/$(date %Y%m%d%H%M%S) ps aux --sort-%mem ps_output.txt ss -antlp ss_output.txt cat /etc/passwd passwd_output.txt這個習慣幫過大忙。有一次我分析到一半系統(tǒng)被人為或者被靶場劇本里的定時任務觸發(fā)改掉了sshd配置導致遠程中斷但之前采集的進程和網(wǎng)絡證據(jù)還在不至于白做。2.3 命令選型背后的原因和坑這里想多說幾句命令選型的問題。比如查看網(wǎng)絡連接我推薦用 ss 而不是 netstat不是因為它更花哨而是新版本的Linux系統(tǒng)里 netstat 經(jīng)常沒裝而且 ss 顯示的信息更全面。查看進程我習慣用 ps aux --sort-%mem 按內(nèi)存占用排序因為挖礦類進程和內(nèi)存馬經(jīng)常伴隨較高的CPU或內(nèi)存占用排序后一眼能發(fā)現(xiàn)異常。查看定時任務的時候注意系統(tǒng)級定時任務不止 crontab -l 這一處。攻擊者非常喜歡把后門腳本寫到 /etc/cron.d、/var/spool/cron/ 甚至 /etc/cron.hourly 這些目錄里。靶場Linux-web-2里就埋了一個隱藏的計劃任務文件名還是 logger不細看真的以為是日志組件。這個后面單獨說。經(jīng)驗先保存現(xiàn)場再動手排查。所有命令輸出前先把證據(jù)目錄建好不要等發(fā)現(xiàn)了再回頭補采。還要留意 shell 歷史記錄可能在 root 的家目錄下。攻擊者不一定每次都清理歷史如果它通過Web shell執(zhí)行命令那歷史記錄大概率是干凈但如果通過某種方式拿到了交互式shell歷史里就可能殘留線索。查看的時候要注意不能光看最后幾行我見過攻擊者在一個巨大的 history 文件末尾混入一句 wget 下載命令粗心的人翻幾行就過了。3. 核心排查路徑從進程、端口到Web日志3.1 進程排查找到藏在正常名字下的異常進程Linux-web-2 的進程排查是整個靶場的高能區(qū)域因為這個靶場刻意把幾個惡意進程偽裝得很像正常服務。我當時按內(nèi)存排序后第一眼看到的是一個名為 php-fpm 的進程內(nèi)存占用極高但機器上其實裝了Apache和Nginx并沒有配php-fpm。用 ps -ef 看它的啟動路徑發(fā)現(xiàn)它運行在 /tmp/.X11-unix/ 目錄下這顯然不合理。再看進程的父進程ID這個進程的PPID不是1而是一個PID很小的進程順著往上追最后追到了Apache的worker進程。到這里基本可以確認這是一個通過Web漏洞上傳的惡意二進制文件偽裝成php-fpm被Apache啟動的PHP腳本間接拉起。那后續(xù)排查的重點就從這是什么進程轉向哪個PHP腳本把它拉起的。進程排查命令再補幾個# 查看進程的啟動時間、工作目錄、啟動路徑 ps aux | grep php ls -l /proc/[PID]/exe ls -l /proc/[PID]/cwd cat /proc/[PID]/cmdline cat /proc/[PID]/environ查看 /proc 下的這些信息非常關鍵。當惡意進程已經(jīng)被刪除exe 鏈接顯示 (deleted)這本身就說明文件被人手動刪過或者用技巧加載后刪除。如果 /proc/[PID]/cmdline 為空或者只是 /bin/sh就要高度懷疑是常用的反彈方式。再強調(diào)一個細節(jié)進程名可以偽造但父進程鏈、啟動路徑、文件鏈接這些元數(shù)據(jù)很難完全偽裝。所以排查時不要只看 ps 的進程名要靠 PID、PPID、/proc 文件系統(tǒng)三重驗證。3.2 網(wǎng)絡連接排查找到外聯(lián)與隱藏C2通道進程排查確認之后網(wǎng)絡連接自然要跟上。靶場Linux-web-2里設計了一個典型的場景Apache進程外連一個看似正常的IP甚至還能看到443端口如果不深入看還以為是在請求什么HTTPS服務。當時我用 ss -antlp 看到如下輸出ESTAB 0 0 192.168.x.x:45678 10.20.30.40:443 uid:33連接進程是Apache的worker但Apache本身沒有理由持續(xù)向一個固定IP發(fā)起443請求。這個IP看起來不像云服務商的IP再結合進程路徑指向 /tmp/.X11-unix 目錄基本可以認定這不是正常的Web服務請求而是惡意進程偽裝成Web訪問往外傳數(shù)據(jù)或者接收指令。網(wǎng)絡排查還需要確認監(jiān)聽端口。攻擊者經(jīng)常會在系統(tǒng)上留一個隱藏監(jiān)聽端口用于后續(xù)連接。最常見的做法是用端口復用或者綁定到非標準端口。# 查看所有監(jiān)聽端口 ss -tulnp # 查看最近的網(wǎng)絡連接 ss -state established -o # 查看TCP連接對應的進程 lsof -i -P -n確認異常外聯(lián)后不要直接把IP封掉就算完應該帶著這個IP回到Web日志里找對應時段的所有請求盡最大可能把攻擊者的交互內(nèi)容恢復出來。靶場里這個外聯(lián)IP對應的訪問記錄其實藏在access.log里后來的日志分析階段驗證了這一點。3.3 Web日志分析還原攻擊者的每一步動作日志是應急響應靶場練習的重頭戲。Linux-web-2 的Web日志位于 /var/log/apache2/access.log當然常見的還有 Nginx 的 access.log。拿到日志第一步先按狀態(tài)碼篩選重點看 200 和 500一個是成功頁面一個是程序錯誤。然后按IP聚合看看哪個IP的請求數(shù)量明顯異常或者哪個IP的請求集中在特定時間窗口。我當時篩選出來的可疑IP是 192.168.x.x攻擊機它的訪問集中在某個時間段內(nèi)而且請求路徑里出現(xiàn)了大量 upload、cmd、eval 這類關鍵字。# 按IP統(tǒng)計訪問次數(shù) awk {print $1} /var/log/apache2/access.log | sort | uniq -c | sort -nr # 查找可疑關鍵字 grep -iE upload|cmd|eval|shell|exec|system|phpinfo|whoami /var/log/apache2/access.log # 查找POST請求 grep POST /var/log/apache2/access.log | tail -n 50日志分析一定要結合時間線。攻擊者在某個時刻上傳了惡意文件緊接著就有系統(tǒng)級操作的痕跡比如創(chuàng)建用戶、寫入計劃任務、下載惡意程序。這里的對應關系是解開整個入侵鏈路的關鍵。我在這次靶場練習中找到了一條很清晰的路徑攻擊者先對某PHP文件做了一次常規(guī)請求然后通過POST向 /uploads/ 目錄上傳了帶PHP后門的圖片文件接著訪問該圖片文件觸發(fā)后門參數(shù)里帶了 whoami 命令后續(xù)出現(xiàn)了 wget 下載惡意二進制和添加公鑰的操作這條路徑在普通網(wǎng)站在線日志里其實很容易被埋沒但如果你圍繞異常IP聚合并按時間排序就會非常明顯。這也是為什么我一直推薦先把日志按IP切開看而不是一上來就整文件搜索。3.4 Web目錄與Webshell專項排查確認Web被上傳了惡意文件之后接下來就是全盤Web目錄掃描。這個過程不是簡單對目錄跑一遍而是要把文件時間、內(nèi)容特征、訪問記錄三者對齊。# 找出最近7天被修改的文件 find /var/www/html -type f -mtime -7 -ls # 查看所有.php文件 find /var/www/html -name *.php -ls # 搜索常見Webshell關鍵字 grep -rEI eval\(|base64_decode\(|assert\(|shell_exec\(|system\(|exec\( /var/www/html靶場里的webshell放在 /var/www/html/uploads/ 目錄下文件名是一個看不出異常的 avatar_2023.jpg但用 file 命令檢查會看到它實際上是PHP腳本。而常規(guī)的目錄掃描工具不一定能識別這種偽裝所以在應急響應流程里文件真實類型檢查比文件后綴名檢查更可靠。file /var/www/html/uploads/avatar_2023.jpg # 輸出PHP script, ASCII text另外webshell里常出現(xiàn)高混淆的編碼。有些攻擊者會把代碼用 base64 嵌套多層編碼grep 可能匹配不到常見關鍵字這時候要結合訪問日志里的參數(shù)特征。日志中有 eval、cmd 之類的傳參這就是關鍵線索。我自己在用的一套Webshell排查邏輯先按修改時間鎖定新增文件再用 file 命令檢查偽裝類型然后按文件內(nèi)容匹配危險函數(shù)最后結合訪問日志看這個文件是否被實際請求過這四步走完常規(guī)靶場里設置的1-3個Webshell基本逃不掉。4. 入侵鏈路復盤一次完整的模擬還原4.1 從Web漏洞入口到權限獲取靶場練習做完排查之后我習慣把整個攻擊鏈復盤一遍寫進報告里。Linux-web-2 的攻擊鏈設計是很有代表性的前后端分離思路入口是某個存在任意文件上傳漏洞的上傳組件攻擊者上傳了一個偽裝為圖片的PHP腳本通過訪問該腳本直接執(zhí)行系統(tǒng)命令從而獲得低權限用戶 www-data 的權限利用系統(tǒng)內(nèi)核漏洞或配置缺陷提權到root提權后創(chuàng)建隱藏用戶、寫入計劃任務、安裝惡意進程這里有個想特別提醒的點很多入門者以為應急響應就是把webshell刪掉就完事但靶場告訴你這只是處理了結果沒有處理原因。應急響應的目標是恢復受控環(huán)境然后給出加固方案上傳接口是否需要校驗、Web服務是否降權運行、系統(tǒng)補丁是否缺失等。所以每次練習我都會要求自己輸出兩個文檔一個是《應急響應處置報告》一個是《安全加固整改方案》。前者給安全團隊看后者給運維團隊看。缺了任何一份練習都不算完整結束。4.2 隱蔽后門與計劃任務的追查回到前面提到的計劃任務。攻擊者在 /etc/cron.d/ 下新增了一個文件文件名是 logger。打開內(nèi)容如下*/5 * * * * root python3 /tmp/.X11-unix/.logger.py /dev/null 21這行命令每5分鐘執(zhí)行一次隱藏在 /tmp/.X11-unix 目錄下的 Python 腳本。攻擊者刻意把目錄起名成 .X11-unix模仿系統(tǒng)圖形接口的套接字目錄不起眼但存在感很強。這種偽裝思路在真實場景中確實很常見。排查計劃任務的完整命令# 列出當前用戶的計劃任務 crontab -l # 查看系統(tǒng)級計劃任務目錄 ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ # 查看所有包含可疑下載或執(zhí)行動作的任務 grep -rE wget|curl|python|bash /tmp|base64 /etc/cron* /var/spool/cron/排查計劃任務的時候還需要注意一個容易被忽略的點/var/spool/cron/ 下可能有以用戶名命名的任務文件如果攻擊者建立了新用戶它會以那個用戶名生成一個計劃任務。所以做計劃任務排查前先把可疑賬號列表確定了兩條線并行查。4.3 賬號隱藏與SSH后門線索在 /etc/passwd 里我們往往只找多出來的名字但其實攻擊者更狡猾的方式是直接修改已有用戶的shell或者在 /etc/passwd 中新增一個 uid 為0的賬戶。靶場里設計的隱藏賬號是 sysadmin在passwd里看著正常但真實用戶信息指向可疑目錄。防漏排查建議用以下方式# 查看uid為0的用戶確認是否有非root用戶 awk -F: $3 0 {print $1} /etc/passwd # 查看所有可以通過shell登錄的用戶 grep -E /(bash|sh|zsh)$ /etc/passwd # 查看用戶目錄下的隱藏文件 ls -la /home/SSH后門這塊靶場里也設了一道題/root/.ssh/authorized_keys 被追加了一個全新的公鑰而且公鑰注釋Anonymous特征明顯。這種后門最直接的危險是攻擊者隨時可以通過密鑰直接登錄root。cat /root/.ssh/authorized_keys # 輸出里除了正常管理員密鑰外還有一行非?？梢傻墓€處理方式很簡單刪除這個公鑰并且重置SSH HostKey因為攻擊者可能也讀取了主機的私鑰然后檢查 /etc/ssh/sshd_config 中是否有異常的全局配置比如把PermitRootLogin改了、增加了不存在的AllowUsers等。5. 靶場練習的常見問題與避坑指南5.1 為什么手動命令采集老是被反殺我見過很多人在做靶場練習的時候在shell里敲了命令然后系統(tǒng)立刻卡死或者進程全部消失。這不是操作失誤而是靶場里故意設計了反排查動作惡意進程檢測到shell輸入了關鍵字就會自我刪除或者執(zhí)行異常腳本。解決這個問題的思路很簡單部分操作盡量使用靜態(tài)工具。把需要排查的數(shù)文件從靶機拷貝到隔離環(huán)境里在本地用工具分析而不是在靶機上一遍遍跑命令。比如 /etc/passwd、/var/log/apache2/access.log 這些都是靜態(tài)文件可以直接拉出來分析。另外執(zhí)行命令時盡量避免高危險的關鍵字這個說法要改一下正常情況下應急響應就是要處理這些進程那么合理的做法是先把證據(jù)備份完再把可疑進程凍結/斷網(wǎng)然后在可受控狀態(tài)下做終止斷網(wǎng)建議在快照之后操作不要一開始就斷網(wǎng)前期的流量分析也是判斷惡意行為的依據(jù)之一。5.2 偽裝文件太多導致誤殺怎么辦靶場里除了惡意的PHP偽裝圖片還可能在正常目錄放置無害但看起來可疑的文件。如果只看文件名或內(nèi)容就判定惡意很容易誤殺正常業(yè)務文件。這個問題的解法和真實應急響應是一致的以訪問日志為準只處理被實際利用過的文件。比如 /uploads 目錄下有一堆JPG只有一個被訪問過且多次傳參那這個才是真正被利用的文件。其他的可疑項可以暫時標記存疑不要馬上刪。5.3 工具自動化vs手動排查的取舍做靶場練習我也用過自動化的一鍵采集腳本效果確實快但有一個致命問題自動腳本誤報率不低而且不告訴你為什么某一行被判定為可疑。手動排查雖然慢但每一步的為什么都清楚。所以我推薦的組合是工具輸出匯總手動確認結論最終報告里對每個可疑項都給出判斷依據(jù)。靶場Linux-web-2非常適合練習這種先手動、后工具的思維模式因為它的樣本數(shù)量有限手動查一遍能在半小時內(nèi)完成但你收獲的排查直覺比用自動化工具掃幾百遍更有用。5.4 報告怎么寫才不像流水賬練習完之后總得寫報告很多新人寫的是流水賬時間線混亂關鍵證據(jù)忘記截取。我在實際練習中整理出一套固定的報告結構分享給大家報告章節(jié)關鍵內(nèi)容事件概述受影響系統(tǒng)、發(fā)現(xiàn)時間、處理結果攻擊時間線從漏洞利用到后門植入的關鍵節(jié)點攻擊路徑分析入口點、提權方式、持久化手段惡意文件清單文件位置、MD5值、判斷依據(jù)處置動作清單清理了什么、封禁了什么、加固了什么證據(jù)鏈附件原始日志、進程快照、網(wǎng)絡連接記錄每次練習報告都按這個模板走養(yǎng)成習慣后等真正遇到生產(chǎn)環(huán)境的安全事件心理壓力再大也有一份標準作業(yè)流程托底。6. 擴展思考與反復練習的體會我練這個靶場系統(tǒng)不止一遍第二輪和第一輪的收獲完全不同。第一輪主要是在學習命令、尋找特征第二輪開始關注攻擊者的意圖比如為什么惡意進程要連443端口為什么計劃任務要每隔5分鐘執(zhí)行這些細節(jié)反過來能幫助定位攻擊者的C2基礎設施思路。到第三輪的時候我開始嘗試在同樣的靶場環(huán)境里修改攻擊路徑比如只留Webshell不放計劃任務模擬短期滲透后快速撤離的攻擊場景。這樣練出來的應急思路會比單純做套題靈活很多。實際上應急響應能力強的人往往都要站在攻擊者的角度去理解每個動作背后的目的。最后再說一個我在練習中摸索出來的小技巧每次處理完一個疑似線索先用一個簡單標簽記錄結論比如已確認惡意待驗證誤報。所有證據(jù)歸檔到帶時間戳的目錄里。這樣即使排查被打斷下次回來也能快速恢復上下文。我見過很多新手因為中途有事情走開了一會兒回來就忘記自己看到哪一步了最后重復排查浪費大量時間。應急響應靶場練習Linux-web-2這個題整體難度偏中等但覆蓋的知識面很全。如果你能在一小時內(nèi)完整走通主機采集、日志回溯、進程定位、后門清理、證據(jù)歸檔、報告輸出這套流程那至少說明你已經(jīng)具備了基本的安全運營實操能力。下一步可以嘗試在這個靶場基礎上自己加戲比如追加一個Redis未授權訪問的入口、或者再加一個隱藏的內(nèi)存馬場景訓練效果會更接近真實攻防對抗。