深入淺出云原生環境信息收集技術（二）

前言

信息收集在攻擊和防御兩端都是非常重要的一環。從宏觀的角度來說，大多數信息相關的工作都可以看作信息收集和信息處理交替進行的循環。優質的信息收集成果是后續工作順利展開的首要條件。《孫子兵法》有云：故善戰人之勢，如轉圓石于千仞之山者，勢也。在掌握了充足信息后，攻防工作將“如轉圓石于千仞之山”。

然而，信息的瑣碎性和云原生本身的復雜組成為云原生環境下的信息收集工作帶來了一定挑戰。有些朋友也許會說，這有何難？比如，執行uname -a命令，就能收集到內核信息了。沒錯，信息收集確實是一步步進行、一項項完成的。但是，如果只是想當然地進行，收集到的信息難免陷于凌亂瑣碎，也很可能不全面。

對此，筆者結合在攻、防兩端積累的經驗，希望與大家探討四個問題：

1. 站在攻擊者視角，云原生環境下的收集信息方式有哪些？
2. 站在攻擊者視角，云原生環境下的信息分類維度有哪些？
3. 站在攻擊者視角，收集到的云原生環境信息有什么價值？
4. 站在攻擊者視角，有沒有可能阻礙或影響防守者收集信息？

就“信息收集”這個話題而言，毫無疑問，防守者是占盡天時地利的，無論是能夠收集到的信息種類、規模，還是信息收集開始的時間、收集信息所需的權限，都遠遠在攻擊者之上。防守者更需要關注的是如何使用、分析收集到的信息。因此，我們從攻擊者的角度出發進行探討。這并不意味著防守的同學不需要關注。相反，只有對攻擊者的技術了然于胸，才能更好地識別攻擊行為、判定攻擊意圖。

本系列第一篇文章討論了云原生環境下的收集信息方式，給出“通過遠程交互收集信息”、“在容器內收集信息”和“基于鏡像收集信息”三種思路。作為本系列的第二篇文章，本文將討論第二個問題：站在攻擊者視角，云原生環境下的信息分類維度有哪些？

注：文中案例相關操作均在實驗環境中進行，相關技術僅供研究交流，請勿應用于未授權的滲透測試。

站在攻擊者視角，云原生環境下的信息分類維度有哪些？

我們會結合實踐從信息收集的“廣度與深度”、“軟件棧層次”和“特定需求”三個方面來介紹云原生環境下的信息分類維度和體系化的收集思路，其中：

1. “廣度與深度”分別指代收集到的信息覆蓋的資產規模和對資產（尤其是可利用性）的了解程度。
2. “軟件棧層次”能夠幫助我們對云原生環境的信息收集工作作出具體分層分類。
3. 面向“特定需求”收集信息是一個“補集”性質的選項，相對于全面撒網式收集而言，有時收集少量信息達到目的即可。

1 信息收集的廣度與深度

信息的收集與分類離不開資產，脫離資產空談信息收集是沒有實際意義的。除了扮演攻擊者角色的滲透測試同學，從事安全防御和網絡空間測繪的同學也都十分重視資產。對于前者來說，有效防御的前提是確保重要資產都處于安全系統和安全管理流程的覆蓋范圍內，在此基礎上不斷監控資產狀態、收集資產信息，對異常狀態和行為進行分析、預警和處置；對于后者來說，測繪能力一定程度上等同于對資產信息的收集分析能力。

站在攻擊者的角度，我們也可以將信息關聯到資產上，從而將信息分類問題轉化為資產分類問題。通常情況下，攻擊者不像防守者（尤其是入侵檢測系統、EDR等）那樣擁有近乎上帝視角下的信息收集能力，卻要比網絡空間測繪以外在暴露特征為主的信息收集工作更主動、更有力。攻擊者能夠、且有必要去挖掘縱深滲透過程中接觸到的每一個信息的可利用性。基于這些觀察，我們將云原生環境中處于不同層次上的集群、主機、容器、進程及文件都定義為資產，并提出以下兩個觀點：

1. 發現更多未知資產等同于提高信息收集的“廣度”；挖掘已知資產的屬性等同于提高信息收集的“深度”。
2. 上層資產的屬性 = 下層資產 + 上層資產自身的元數據。

在以上兩個觀點的基礎上，我們可以制作出面向資產的信息收集結構樹：

這棵樹是我們在面對云原生集群目標時制定信息收集策略的好幫手，其中：

1. 發現、訪問同層次結點增加了信息廣度；自頂向下（上圖中從左向右）訪問結點增加了信息深度。
2. 網絡信息主要由拓撲信息（如隔離策略、子網劃分等）和實體信息（如提供網絡服務的進程等）兩部分組成；前者歸屬于集群、節點或Pod元數據，后者歸屬于進程元數據。

通過建立廣度和深度的概念，我們總結出云原生環境中的資產關系，并繪制出信息收集結構樹。這確實能夠幫助我們把握信息收集的方向，但依然有些抽象，不能有效指導具體收集工作。接下來，我們將把這棵樹具體化——結合實例來分享如何層次化收集云原生環境的信息。

2 信息收集的軟件棧層次

將上一節的信息收集結構樹展開，可以獲得下面這樣的信息收集矩陣：

其中，集群處于最高層次，覆蓋的信息采集點最多；容器是最低層次，覆蓋自身元數據和進程、文件的元數據。進程和文件作為葉子結點資產，不可再分，沒有獨立劃出來。與ATT&CK矩陣類似，上圖列出了常用的信息采集點，但信息收集矩陣本身在不同的軟件棧層次上都是持續增長的。隨著軟件的更迭和技術的發展，失去價值的信息采集點可能會棄用，新的信息采集點可能會出現。

前面提到，沒有上帝視角的攻擊者能夠收集到的信息注定是有限的。因此，我們必須充分利用收集到的信息，為目標集群畫像，在黑盒狀態下建立威脅模型，并盡可能不斷完善這個模型。有的朋友可能會問：又是樹，又是矩陣，到底有什么用呢？我們將在第三篇文章中詳細講述收集到的云原生環境信息的利用價值。在此之前，大家可以通過下面這幅測試環境下的實踐圖先睹為快：

上圖是我們對目標云原生環境應用信息收集矩陣的部分輸出結果。可以看到，我們能夠利用信息收集矩陣獲取相當多的有價值信息，為后續的滲透測試指出方向。這些信息均采用本系列第一篇文章[2]中介紹的方法收集。下面，我們以檢測命名空間共享情況為例來講解具體的收集過程。

Linux Namespaces機制是構成容器的技術基石，包括不同類型的命名空間，實現對不同類型資源的隔離。判斷容器是否與宿主機共享命名空間的關鍵是找到在攻擊者信息收集能力范圍內的共享與不共享兩種情況之間的差異點。接下來，我們將介紹PID、Network命名空間的判斷方法。

對于PID namespace來說，一種簡單但不太精確的方法是觀察/proc目錄下的進程數。通常來說，宿主機上的進程要大大多于普通容器內的進程，進程執行的命令行（/proc/[PID]/cmdline）也種類各異。根據這些情況，人類也許很容易給出傾向性的判定，但卻很難由機器自動化。我們的方法是讀取/proc/sys/kernel/cad_pid的值，1表明是宿主機的PID命名空間，0則代表容器的獨立PID命名空間：

rambo@t-matrix:~# docker run --rm-it ubuntu cat /proc/sys/kernel/cad_pid0rambo@t-matrix:~# docker run --rm -it --pid=hostubuntu cat /proc/sys/kernel/cad_pid1

根據內核文檔[3]，這個文件的值表示系統重啟時接收Ctrl-Alt-Delete信號的進程的PID。可以發現，在宿主機上該值為1，在容器內該值為0。

對于Network namespace來說，可以通過檢查容器的/etc/hosts文件是否有容器內部IP來判斷。如下面的命令行操作所示，在共享宿主機Network namespace的情況下，容器內的/etc/hosts中沒有172.17.0.2的內部IP：

rambo@t-matrix:~# docker run --rm-it --net=host centos:latest cat /etc/hosts127.0.0.1   localhost.localdomain   localhost::1         localhost6.localdomain6localhost6
# The following lines are desirable for IPv6 capablehosts::1    localhost ip6-localhost ip6-loopbackfe00::0 ip6-localnetff02::1 ip6-allnodesff02::2 ip6-allroutersff02::3 ip6-allhostsrambo@t-matrix:~# docker run --rm -it centos:latestcat /etc/hosts127.0.0.1   localhost::1   localhostip6-localhost ip6-loopbackfe00::0     ip6-localnetff00::0     ip6-mcastprefixff02::1     ip6-allnodesff02::2     ip6-allrouters172.17.0.2  890791c776de

然而，在一些較為復雜的網絡環境（如存在多種CNI插件可供選擇的Kubernetes集群環境）中，這種方法也不夠準確直觀。因此，一種更好的方式是通過檢查容器內的/proc/net/unix文件內容[4]來判斷：

rambo@t-matrix:~# docker run --rm-it --net=host centos:latest grep "systemd" /proc/net/unix0000000000000000: 00000002 00000000 00000000 0002 014397653 /run/user/1000/systemd/notify...rambo@t-matrix:~# docker run --rm -it centos:latestgrep "systemd" /proc/net/unixrambo@t-matrix:~#

除了上面這種隔離性判定問題外，信息收集矩陣中的大部分信息都可以通過直接讀取特定文件或發起特定網絡訪問的方式獲得，思路一致，手法大同小異，不再展開講解。

3面向特定需求收集信息

理論上，全面、體系化的信息收集工作確實能夠最大程度地幫助我們感知目標環境，但在實踐中也存在明顯不足：容易觸發告警。前文提到，防守的同學可以利用這一點“識別攻擊行為、判定攻擊意圖”，正是如此。

因此，另一種思路便是面向特定需求收集信息，夠用即可，點到為止。在下一篇文章中，我們會對云原生環境信息的利用價值進行總結。換個角度，利用價值也正是利用目的，無外數據泄露、權限提升、容器逃逸、橫向移動四種：

正如上圖所展示的一樣，如果明確了目的，那么實際執行的操作可能只是整個信息收集矩陣中很小的子集。

總結

本文是“深入淺出云原生環境信息收集技術”系列的第二篇，分享了信息收集的廣度深度和軟件棧層次，并依次提出了信息收集結構樹和信息收集矩陣，從抽象到具體一步步展開云原生環境信息收集工作，最后介紹了從需求出發的收集思路，作為體系化收集思路的補充。

在本系列開頭[2]，我們曾提出一個觀點：大多數信息相關的工作都可以看作信息收集和信息處理交替進行的循環。希望大家能夠通過本文感受到信息收集工作的魅力。現在，有了信息收集的方式，也有了信息分類的維度，下一篇文章將分享云原生環境信息的具體利用案例，達到“轉圓石于千仞之山”的利用效果。

最后，向大家推薦由綠盟科技星云實驗室編寫的《云原生安全：攻防實踐與體系構建》一書，本書系統梳理云原生安全可能面臨的威脅與風險，給出切實可行的防護方案，隨書附帶豐富的配套實驗。云原生從業者以及對云原生安全感興趣的同學一定不要錯過！

參考文獻

[1] https://www.bilibili.com/video/BV1pL4y1g7FP

[2] https://mp.weixin.qq.com/s/qCfH80BWOTTOA707wVSY-w

[3] https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#cad-pid

[4] https://man7.org/linux/man-pages/man5/proc.5.html