.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
Kubernetes是什麼，Kubernetes是一個全新的基於容器技術的分佈式架構解決方案，是Google 開源的一個容器集群管理系統，Kubernetes簡稱K8S。用於自動部署、擴展和管理容器化（containerized）應用程序。在本文中，我們將介紹為何Kubernetes 的DFIR 如此重要，以及如何評估你的容器DFIR 功能。我們還將看到一個完整的場景，深入挖掘影響Kubernetes pod 的事件，以及要採取的對應步驟。
什麼是DFIR數字取證和事件響應(DFIR) 是網絡安全領域，包括在事件發生時採用的技術，重點是識別、檢查和響應網絡攻擊。
事件響應計劃發生安全事件時，每家公司都應應用其事件響應計劃(IRP) 中概述的技術。這是一個記錄在案的過程，它建立了在發生違規時要採用的指導方針。儘管每個公司的IRP 可能不同，但可以概括為以下四個主要步驟：
識別：對攻擊及其相關風險的快速深入調查可以在整個過程中發揮關鍵作用。此步驟通常涉及與受影響環境相關的所有安全事件、日誌和報告。
協調：一旦檢測到可能的事件，響應團隊必須評估該事件是否代表真正的安全事件。因此，它還必須決定是否響應它。
解決方案：該過程的這一步用於調查事件本身的原因，限制其影響，並在必要時將其隔離。在此步驟中，團隊應解決安全風險並實施補救措施。最終，它可以從備份中恢復受影響的系統、數據和服務，甚至修復受影響的環境。
工具推薦工具可以在識別、調查和響應網絡攻擊方面發揮關鍵作用。
前面描述的所有階段都應該始終得到有效工具的支持，這些工具可以促進攻擊的調查和響應。通過執行它們，你可以深入了解你控制的所有內容。你可以將證據自動存儲在你的私人遠程存儲中。此外，你可以監控你當前擁有的資源，以檢測意外的工作負載峰值，在發生事件或可疑網絡流量時接收警報，並及時做出響應。
以下是本文將使用的工具或在DFIR Kubernetes 期間可能用得著的工具：
SIEM（例如ElasticSearch）：收集和存儲在你要監控的環境中生成的日誌和警報的應用程序，它在識別階段非常有用。
Falco：一種開源威脅檢測引擎，可根據一組規則在運行時觸發警報。 Falco 觸發的警報可以發送到SIEM 以收集運行時事件的證據。
Falcosidekick：一個開源工具，它接收Falco 的事件並以扇出方式將它們轉發到不同的輸出。
Prometheus：使用領先的開源監控解決方案為你的指標和警報提供支持。
Docker Explorer：一個能夠對快照捲進行離線取證分析的開源項目。
kube-forensics：一個開源項目，允許Kubernetes 集群管理員將任何受影響的pod 的工件存儲到AWS 存儲桶中。
Cloud Forensics Utils：一個開源項目，可以通過一組工具加快和簡化取證過程。
kubesploit：一個開源滲透測試框架，可以改善你掃描集群的網絡安全狀況。
因此，擁有工具並規劃正確的策略可以讓你跟踪和收集環境的證據，從而使管理和調查更容易。
Kubernetes 的分步取證程序現在，我們將模擬在Kubernetes 集群中發生網絡安全事件時如何評估DFIR。
在這個場景中，我們將看到如何檢測可能的事件、如何監控事件及其相關資源。最後，我們還將看到如何採取措施減少其影響。
識別過程我們用自己管理的Kubernetes集群，通過Kubernetes負載均衡器服務將我們的應用程序、網站和web服務器部署到網絡中。
如上述步驟所示，我們使用Falco 在運行時檢測事件。 Falco 是事實上的Kubernetes 威脅檢測引擎。它作為守護進程部署在我們集群的每個節點上，並配置了Falcosidekick，以便向本場景中採用的SIEM (Elasticsearch和Prometheus)發送警報。
為了使用Falco 監控整個集群，我們設置了自定義檢測規則，當遠程命令執行攻擊在我們的pod中發生時，這些規則就會觸發。
其中一條Falco 規則如下所示：
就在幾分鐘前，觸發了其中一個規則，生成了一些警報，現在我們可以在Falcosidekick UI中檢查所有事件信息。
似乎我們的一個Tomcat pod允許一個奇怪的下載，這可能是值得研究的有趣的事情。
一旦發現可疑情況，就可能需要深入評估事件的風險。你所擁有的工具可以給你很多建議，比如可以檢測到正在運行的可疑命令、敏感文件系統路徑中的更改文件以及意外的網絡流量。此外，高CPU 使用率和內存使用率可能表明存在惡意執行，並且可以使用Prometheus 等工具快速監控。
在這種特定情況下，已檢測到它具有很高的資源消耗（特別是受影響的Pod 使用了超過2 GB 的內存）！
協調以減少風險暴露時間——Kubernetes 網絡政策首先，我們需要減少影響。讓我們開始通過Kubernetes 網絡策略隔離受影響的Pod。這樣，你將有機會控制入站和出站流量。
首先，刪除將受影響的Pod 與部署綁定的當前標籤。通過這樣做，我們會自動刪除傳入的流量。接下來，我們必須標記受影響的Pod：
這個新標籤將我們即將創建的網絡策略的範圍限制為僅標記的Pod，而不是整個名稱空間。
然後，根據文檔，明確拒絕策略的能力無法通過網絡策略完成。為了實現我們的目標，隔離Pod，我們修改了最嚴格的策略（deny-all）並將podSelector 修改為僅適用於受影響的pod。如果有其他NetPol 影響所有pod，則行為可能與預期不同。
這將阻止任何進出受影響pod 的入站或出站連接。
這是另一個示例，表明我們無法從帶有藍色標籤的Pod 中獲取信息，並且綠色標籤的pod 不受影響。
對工作節點進行標籤和封鎖為了隔離攻擊並使調查更容易，我們可以標記部署pod 的工作節點。這樣就可以簡化該節點的區分。
另一個最佳實踐是“封鎖”工作節點。它確保Kubernetes 調度程序將該節點視為不可調度，並阻止在其上部署新的Pod。因此，如果資源允許，新的Pod 將被調度到其他地方，而受影響節點上已經運行的Pod 將被保留。這不會改變受影響的Pod，也不會改變要在其中進行的調查過程。
這對於隔離節點並調查由於容器逃逸而導致的危害非常有用。順便說一句，在本文中，我們僅僅假設攻擊將仍然局限於受影響的pod。
我們已經執行了一些必要的步驟來隔離受影響Pod 中的惡意執行。使用Kubernetes 網絡策略，我們已經確定不允許來自受影響的pod 的傳入或傳出連接。此外，我們標記了涉及的Pod，並阻止在Pod 運行的節點中進行新的部署。有時，你還可以刪除或撤銷受影響的工作節點/Pod 權限或安全憑證，以避免攻擊傳播到其他雲資源。
但是，我們仍然需要了解攻擊是如何發生的，我們承擔的風險是什麼，以及它可能產生的影響。
DFIR Kubernetes方法——快速方法它可以被認為是最快的方法。將正在運行的容器隔離並仍在Kubernetes 集群中運行，你可以直接從其工作節點檢查它。
現在，讓我們跳轉到該節點並開始搜索受影響的容器ID。
現在我們知道了哪個是容器ID，這樣就可以開始深入挖掘它的細節。
似乎在Elasticsearch 收到日誌前幾秒鐘，在Tomcat 上部署了一個新的war 文件。這可能是攻擊的初始訪問，但讓我們繼續檢查容器文件系統自創建以來的更改。
更改：C 行是更改後的目錄。
追加：A 行是新添加的文件。
如前所述，似乎在Tomcat 管理器中添加的文件很少。而且，文件系統中還寫入了其他文件，例如zzz（已經在上面的Elasticsearch 日誌中顯示）。
為了查看機器中還有什麼在運行，我們還可以啟動docker top和stats命令。
高CPU 使用率，確認之前檢測到的內容。
我們還可以將容器的更改提交到新映像（通過docker commit）或將受影響的文件系統導出為tar 文件（通過docker export），以便存儲發生更改的工件。如果你想了解有關此技術的更多信息，請查看對惡意Docker 容器進行分類。
DFIR Kubernetes——離線方法Docker-explorer是一個開源項目，能夠對快照捲進行離線取證分析。
一旦我們確定了受影響的Pod 所在的Kubernetes 工作節點，最好的做法是對其文件系統進行快照。這可以通過雲提供商控制台或通過採用其他一些開源項目來完成，例如cloud-forensics-utils。有了快照卷，就可以進行事後分析，將其附加並安裝到將使用docker-explorer 的新虛擬機上。
Docker-explorer 可以列出所有docker 容器或僅列出已安裝卷中正在運行的容器。
一旦我們獲得了我們想要調查的容器ID，就可以提取日誌，就像我們之前使用docker logs
但最重要的功能是使用docker-explorer 將容器文件系統掛載到VM 中。
這將使我們能夠訪問受影響的容器文件系統。因此，從現在開始，我們將能夠調查之前監控的進程和文件（zzz、kdevtmpfsi、kinsing）。
例如，我們可以讀取zzz bash 腳本，或者我們可以提取ELF 文件的哈希值，以便通過VirusTotal 對其進行掃描。
正如預期的那樣，由於使用了大量的CPU，kdevtmpfsi 進程是一個挖礦程序。
Kube-forensics
kube-forensics 是一個開源項目，允許集群管理員將任何受影響的pod 的工件存儲到S3 存儲桶中。它要求kube-forensics 創建的工作pod 具有將對象寫入AWS 存儲桶的必要權限。
這樣我們就可以將受影響的Pod 證據存儲到應用此PodCheckpoint 的S3 存儲中：
幾分鐘後，PodCheckpoint 將完成其執行，證據也會出現在目標S3 存儲桶中。
因此，除了保存pod 描述之外，kube-forensics 還以與我們之前在實時主機部分中所做的類似方式存儲與docker inspect 和docker diff 命令相關的結果。
對於“.export.tar”文件，它是可以通過docker export 命令獲得的文件，它可以將容器文件系統存儲在可以檢查發布的“.tar”文件中。
Kubernetes事件的解決和總結通過分析和調查違規行為，你可以識別你在集群中部署的易受攻擊的資產。
在此示例中，攻擊入口點由暴露在網絡中的易受攻擊的Tomcat Pod 表示。取證分析得出的結論是Tomcat 管理器不安全，因為它配置錯誤並且沒有影響其他Pod 或命名空間。
不過，有時受感染的Pod 可能會由於眾所周知或未知的漏洞而被利用。
作為事件響應階段的一部分，你應該從受感染的Pod 中學習，用更新和安全的Pod 替換它們。但是，如果無法保護你的工作負載，可能是因為它們還沒有可用的補丁，你應該採用其他解決方案。
例如，第一個是在發布新補丁之前刪除和刪除你的部署，只要你有足夠的關於發生的事情的信息。這是防止發生任何違規的最嚴格的方法，但它也會在可用性方面影響你的業務。
在其他一些情況下，你可能希望使用Falco 和Falcosidekick 來設置你的Kubernetes 響應引擎。當通過Falco 觸發特定事件時，它允許你在Kubernetes 集群中做出響應。例如，在前面的場景中，如果將具有通用文件名的新.war 文件部署到Tomcat 管理器中或檢測到RCE，我們可以採用終止pod 的規則。