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 的規則。

本文翻譯自：https://sysdig.com/blog/guide-kubernetes-forensics-dfir/如若轉載，請注明原文地址