周五下午三點，監(jiān)控頁面突然跳出“容器異常行為”報警，運維群瞬間炸鍋了。有人貼出日志片段：一個名叫nginx的容器里，進程樹從sh冒出來，后面跟著cat、sleep循環(huán)，每隔5秒準時上演一次。沒有部署腳本，也沒有定時任務，普通的Web服務容器哪兒來的shell在蹦跶？在細粒度隔離的容器環(huán)境下，看到這種“多出來的進程”，和家里客廳半夜自己開燈一樣讓人頭皮發(fā)麻。

　　傳統(tǒng)的主機入侵檢測光看CPU、網(wǎng)絡流量根本摸不著頭腦。容器內(nèi)跑什么進程，宿主機上往往只看得到一個docker?containerd的大傘柄，里面少說封了幾十個進程，沒有透視圖，運維就等于蒙著眼睛給人遞刀。這時候必須有一種工具，能直接鉆進容器名字空間，把每一條系統(tǒng)調(diào)用攤開來看——Falco就是干這個的。

　　別再迷信“容器就是輕量級虛擬機”這句老黃歷了。在一個真正按“不可變基礎設施”理念管理的生產(chǎn)集群里，Nginx容器的工作目錄是只讀的，除了master和worker之外，不該再有第三個進程。一旦內(nèi)部多出個bash、sh或者莫名其妙的perl，十有八九是有人拿到了shell。攻擊者踩點、反連cnc、橫向移動，頭一件事就是把shell丟進去。而你如果只盯著access log，等到發(fā)現(xiàn)異常的時候，數(shù)據(jù)可能早就被拖干凈了。

　　所以面對這個“心跳式”進程循環(huán)，我們用Falco做了一次實時分析。思路很干脆：逮住execve系統(tǒng)調(diào)用——不管是誰想要fork一個新進程，都得經(jīng)過這個關口。然后只監(jiān)聽名字精確等于”nginx”的容器，篩出來的每一條事件都落盤，留作審計鏈條。下面就把整個排查拆成三條硬核操作，每一條都能立即復用。

　　第1步：定制一條能聽懂“進程生娃”的規(guī)則
Falco的規(guī)則文件是YAML格式，規(guī)則引擎會把每一行實時事件流挨個過篩。我們在任意目錄下新建文件，命名為nginx?rules.yml：
vi nginx?rules.yml
粘貼以下配置：
- rule: spawned_process_in_nginx_container
desc: A process was spawned in the Nginx container.
condition: container.name = "nginx" and evt.type = execve
output: "%evt.time,%proc.name,%user.uid,%container.id,%container.name,%container.image"
priority: WARNING
保存退出。這條規(guī)則底下藏著三個關鍵點：第一，condition字段做了雙重過濾，必須同時命中容器名為”nginx”而且事件類型為execve，少一個條件都不會觸發(fā)；第二，output里拼了時間戳、進程名、用戶UID以及容器ID、鏡像信息，相當于給每個新進程拍了張帶身份證的出生照；第三，級別設成WARNING，意味著只要規(guī)則命中，就代表發(fā)生了不符合“單一進程”預期的狀況。

　　為什么死磕execve？因為在Linux內(nèi)核里，無論是交互式敲命令、腳本里的子進程、還是被漏洞利用代碼注入后執(zhí)行/bin/sh，最終都要通過execve系列調(diào)用來加載新程序鏡像。Falco在內(nèi)核態(tài)用eBPF或者模塊直接掛載跟蹤點，進程還沒跑完創(chuàng)建就已經(jīng)被記下，延遲微乎其微，而且繞不過去——除非攻擊者能直接寫內(nèi)核模塊，那游戲規(guī)則就已經(jīng)完全不同了。

　　還有一點值得專門拎出來說：這條規(guī)則沒有直接用”容器內(nèi)所有execve都告警”這種大炮打蚊子的寫法，而是縮小到nginx容器。在真實生產(chǎn)環(huán)境，如果你一股腦把四十多種微服務容器的進程生成全部錄下來，幾分鐘就能淹沒磁盤，真正的攻擊痕跡反而被沖淡。精準打擊，是運行時檢測的第一要義。

　　第2步：限定時間窗口，把掃描結果釘在紙上
規(guī)則寫好，接下來就運行Falco。為保證實驗可復現(xiàn)，我們用-M 45參數(shù)，讓它在剛好45秒后自動優(yōu)雅退出，然后把輸出重定向到一個日志文件：
sudo falco -r nginx?rules.yml -M 45 > /home/cloud_user/falco?report.log
這里-r指定我們剛剛編寫的規(guī)則文件，-M 45是duration模式，不會無限運行。45秒的時間窗口看起來短，但對于一個5秒循環(huán)的異常進程鏈來說，已經(jīng)夠捕獲至少9輪事件，足以看出行為模式。

　　不設限的持續(xù)監(jiān)控當然有價值，但針對一次明確的排查場景，限時運行有兩個實際好處：一是輸出可控，日志不至于膨脹到幾GB，審計復盤時眼睛不發(fā)直；二是能快速驗證規(guī)則本身有沒有寫錯，比如正則沒匹配上、文件路徑錯誤，45秒內(nèi)就能暴露出來，不用等半天才發(fā)現(xiàn)一條告警都沒有。

　　很多人習慣把安全工具掛成守護進程就跑，從來不抽檢輸出的內(nèi)容。等真出事那天把日志翻出來，才發(fā)現(xiàn)六個月來只記錄了一行“Falco started”——這不是工具的問題，是壓根沒配對。所以，如果你第一次上手Falco，務必先用人肉可讀的小窗口驗證規(guī)則是否起效，再去談長期留存。

　　第3步：翻日志，把進程“犯罪鏈條”拼出來
運行結束后，直接查看生成的報告：
cat /home/cloud_user/falco?report.log
時間戳會告訴你每一條新進程誕生的精確時刻。這次的輸出里，赫然出現(xiàn)了規(guī)律明顯的循環(huán)：
05:07:16: sh → cat → sh → sleep
05:07:21: sh → cat → sh → sleep
05:07:26: sh → cat → sh → sleep
兩次觸發(fā)間隔恰好5秒。正常的Nginx worker絕對不會平白無故執(zhí)行cat，更不會反復把自己注冊成shell再睡覺。這種模式說明有一份腳本或者反向shell已經(jīng)在容器內(nèi)部扎根，而且極可能是攻擊者通過Web漏洞上傳或者利用了遠程代碼執(zhí)行，正在反復探測環(huán)境。

　　為什么是sh?cat?sh?sleep這個順序？八成是攻擊者想從某個文件里讀信息（cat），然后把結果逐行交給后面的shell處理，sleep用來控制心跳間隔，防止短時間高頻連接惹人注意。換句話說，這已經(jīng)是在“做事”的階段了，不是在踩點，是在干活。

　　沒有Falco，你很可能從Kubernetes的dashboard里只能看到nginx容器的內(nèi)存漲了一點點，CPU起伏平常，其他一切指標綠瑩瑩。運維人員最多說一句“這容器有點鬧騰”，然后繼續(xù)喝茶。但鬧騰的到底是什么？是應用本身的熱加載，還是勒索病毒在加密文件？不知道。

　　容器的“不可變”理念，不能只停留在部署階段。一個鏡像build完上線之后，運行期也絕不能允許隨意的進程修改。讓容器做到“除了聲明下的路徑，任何地方無法寫入；除了聲明的進程，任何代碼無法執(zhí)行”，才是把攻擊面壓到最低。Falco在這里扮演的就是運行時的最后一道攝像頭——只要有人試圖打破這種不變性，馬上就會被抓拍。

　　這三步操作總結下來，本質(zhì)上就是把傳統(tǒng)安全領域里的“進程白名單”搬到了云原生體系里，并借助系統(tǒng)調(diào)用級別的跟蹤，把它做得更細粒度、更具實時性。不需要在鏡像里預埋agent，也不需要改基礎鏡像，只要節(jié)點上有Falco探針，所有容器的execve都逃不掉。

　　當然，會有人問：如果攻擊者進來后，完全不創(chuàng)建新進程，只利用nginx已有的worker進程，通過寫入內(nèi)存、修改解析邏輯等方式執(zhí)行惡意代碼，F(xiàn)alco還能不能看到？這屬于無文件攻擊范疇，通常需要結合網(wǎng)絡層異常和內(nèi)存取證，已經(jīng)超出單條execve規(guī)則的覆蓋范圍。但現(xiàn)實中的大多數(shù)自動化攻擊和人工操作，第一步還是fork一個shell出來，因此這條規(guī)則依舊能卡住大半攻擊鏈路的咽喉。

　　最后別忘記，F(xiàn)alco的規(guī)則異常靈活，你可以把condition擴展到檢測特定命令行參數(shù)、父進程名、或者是某個敏感系統(tǒng)調(diào)用（比如ptrace）。我們這次只用了execve作為例子，但實際生產(chǎn)里完全可以編織一套針對自己業(yè)務畫像的策略，讓告警從“大海撈針”變成“見血封喉”。

　　安全監(jiān)控最怕的從來不是“發(fā)現(xiàn)不了”，而是“告警太多，真的那條被埋了”。用Falco精準盯住不可變?nèi)萜骼锩俺鰜淼拿恳粋€新進程，就是在混亂里按下一個可靠的指紋采集器。下次再有人問“為什么Nginx容器里會有sh？”，你直接甩他一條日志，精確到毫秒和UID。