Kubernetes 是什么，Kubernetes 是一個全新的基于容器技術(shù)的分布式架構(gòu)解決方案，是 Google 開源的一個容器集群管理系統(tǒng)，Kubernetes 簡稱 K8S。用于自動部署、擴(kuò)展和管理容器化(containerized)應(yīng)用程序。在本文中，我們將介紹為何 Kubernetes 的 DFIR 如此重要，以及如何評估你的容器 DFIR 功能。我們還將看到一個完整的場景，深入挖掘影響 Kubernetes pod 的事件，以及要采取的對應(yīng)步驟。

什么是 DFIR

數(shù)字取證和事件響應(yīng) (DFIR) 是網(wǎng)絡(luò)安全領(lǐng)域，包括在事件發(fā)生時采用的技術(shù)，重點(diǎn)是識別、檢查和響應(yīng)網(wǎng)絡(luò)攻擊。

事件響應(yīng)計(jì)劃

發(fā)生安全事件時，每家公司都應(yīng)應(yīng)用其事件響應(yīng)計(jì)劃 (IRP) 中概述的技術(shù)。這是一個記錄在案的過程，它建立了在發(fā)生違規(guī)時要采用的指導(dǎo)方針。盡管每個公司的 IRP 可能不同，但可以概括為以下四個主要步驟：

識別：對攻擊及其相關(guān)風(fēng)險的快速深入調(diào)查可以在整個過程中發(fā)揮關(guān)鍵作用。此步驟通常涉及與受影響環(huán)境相關(guān)的所有安全事件、日志和報告。

協(xié)調(diào)：一旦檢測到可能的事件，響應(yīng)團(tuán)隊(duì)必須評估該事件是否代表真正的安全事件。因此，它還必須決定是否響應(yīng)它。

解決方案：該過程的這一步用于調(diào)查事件本身的原因，限制其影響，并在必要時將其隔離。在此步驟中，團(tuán)隊(duì)?wèi)?yīng)解決安全風(fēng)險并實(shí)施補(bǔ)救措施。最終，它可以從備份中恢復(fù)受影響的系統(tǒng)、數(shù)據(jù)和服務(wù)，甚至修復(fù)受影響的環(huán)境。

工具推薦

工具可以在識別、調(diào)查和響應(yīng)網(wǎng)絡(luò)攻擊方面發(fā)揮關(guān)鍵作用。

前面描述的所有階段都應(yīng)該始終得到有效工具的支持，這些工具可以促進(jìn)攻擊的調(diào)查和響應(yīng)。通過執(zhí)行它們，你可以深入了解你控制的所有內(nèi)容。你可以將證據(jù)自動存儲在你的私人遠(yuǎn)程存儲中。此外，你可以監(jiān)控你當(dāng)前擁有的資源，以檢測意外的工作負(fù)載峰值，在發(fā)生事件或可疑網(wǎng)絡(luò)流量時接收警報，并及時做出響應(yīng)。

以下是本文將使用的工具或在 DFIR Kubernetes 期間可能用得著的工具：

SIEM(例如 ElasticSearch)：收集和存儲在你要監(jiān)控的環(huán)境中生成的日志和警報的應(yīng)用程序，它在識別階段非常有用。

Falco：一種開源威脅檢測引擎，可根據(jù)一組規(guī)則在運(yùn)行時觸發(fā)警報。 Falco 觸發(fā)的警報可以發(fā)送到 SIEM 以收集運(yùn)行時事件的證據(jù)。

Falcosidekick：一個開源工具，它接收 Falco 的事件并以扇出方式將它們轉(zhuǎn)發(fā)到不同的輸出。

Prometheus：使用領(lǐng)先的開源監(jiān)控解決方案為你的指標(biāo)和警報提供支持。

Docker Explorer：一個能夠?qū)煺站磉M(jìn)行離線取證分析的開源項(xiàng)目。

kube-forensics：一個開源項(xiàng)目，允許 Kubernetes 集群管理員將任何受影響的 pod 的工件存儲到 AWS 存儲桶中。

Cloud Forensics Utils：一個開源項(xiàng)目，可以通過一組工具加快和簡化取證過程。

kubesploit：一個開源滲透測試框架，可以改善你掃描集群的網(wǎng)絡(luò)安全狀況。

因此，擁有工具并規(guī)劃正確的策略可以讓你跟蹤和收集環(huán)境的證據(jù)，從而使管理和調(diào)查更容易。

Kubernetes 的分步取證程序

現(xiàn)在，我們將模擬在 Kubernetes 集群中發(fā)生網(wǎng)絡(luò)安全事件時如何評估 DFIR。

在這個場景中，我們將看到如何檢測可能的事件、如何監(jiān)控事件及其相關(guān)資源。最后，我們還將看到如何采取措施減少其影響。

識別過程

我們用自己管理的Kubernetes集群，通過Kubernetes負(fù)載均衡器服務(wù)將我們的應(yīng)用程序、網(wǎng)站和web服務(wù)器部署到網(wǎng)絡(luò)中。

如上述步驟所示，我們使用 Falco 在運(yùn)行時檢測事件。 Falco 是事實(shí)上的 Kubernetes 威脅檢測引擎。它作為守護(hù)進(jìn)程部署在我們集群的每個節(jié)點(diǎn)上，并配置了Falcosidekick，以便向本場景中采用的SIEM (Elasticsearch和Prometheus)發(fā)送警報。

為了使用 Falco 監(jiān)控整個集群，我們設(shè)置了自定義檢測規(guī)則，當(dāng)遠(yuǎn)程命令執(zhí)行攻擊在我們的pod中發(fā)生時，這些規(guī)則就會觸發(fā)。

其中一條Falco 規(guī)則如下所示：

就在幾分鐘前，觸發(fā)了其中一個規(guī)則，生成了一些警報，現(xiàn)在我們可以在Falcosidekick UI中檢查所有事件信息。

似乎我們的一個Tomcat pod允許一個奇怪的下載，這可能是值得研究的有趣的事情。

一旦發(fā)現(xiàn)可疑情況，就可能需要深入評估事件的風(fēng)險。你所擁有的工具可以給你很多建議，比如可以檢測到正在運(yùn)行的可疑命令、敏感文件系統(tǒng)路徑中的更改文件以及意外的網(wǎng)絡(luò)流量。此外，高 CPU 使用率和內(nèi)存使用率可能表明存在惡意執(zhí)行，并且可以使用 Prometheus 等工具快速監(jiān)控。

在這種特定情況下，已檢測到它具有很高的資源消耗(特別是受影響的 Pod 使用了超過 2 GB 的內(nèi)存)!

協(xié)調(diào)以減少風(fēng)險暴露時間——Kubernetes 網(wǎng)絡(luò)政策

首先，我們需要減少影響。讓我們開始通過 Kubernetes 網(wǎng)絡(luò)策略隔離受影響的 Pod。這樣，你將有機(jī)會控制入站和出站流量。

首先，刪除將受影響的 Pod 與部署綁定的當(dāng)前標(biāo)簽。通過這樣做，我們會自動刪除傳入的流量。接下來，我們必須標(biāo)記受影響的 Pod：

這個新標(biāo)簽將我們即將創(chuàng)建的網(wǎng)絡(luò)策略的范圍限制為僅標(biāo)記的 Pod，而不是整個名稱空間。

然后，根據(jù)文檔，明確拒絕策略的能力無法通過網(wǎng)絡(luò)策略完成。為了實(shí)現(xiàn)我們的目標(biāo)，隔離 Pod，我們修改了最嚴(yán)格的策略(deny-all)并將 podSelector 修改為僅適用于受影響的 pod。如果有其他 NetPol 影響所有 pod，則行為可能與預(yù)期不同。

這將阻止任何進(jìn)出受影響 pod 的入站或出站連接。

這是另一個示例，表明我們無法從帶有藍(lán)色標(biāo)簽的 Pod 中獲取信息，并且綠色標(biāo)簽的 pod 不受影響。

對工作節(jié)點(diǎn)進(jìn)行標(biāo)簽和封鎖

為了隔離攻擊并使調(diào)查更容易，我們可以標(biāo)記部署 pod 的工作節(jié)點(diǎn)。這樣就可以簡化該節(jié)點(diǎn)的區(qū)分。

另一個最佳實(shí)踐是“封鎖”工作節(jié)點(diǎn)。它確保 Kubernetes 調(diào)度程序?qū)⒃摴?jié)點(diǎn)視為不可調(diào)度，并阻止在其上部署新的 Pod。因此，如果資源允許，新的 Pod 將被調(diào)度到其他地方，而受影響節(jié)點(diǎn)上已經(jīng)運(yùn)行的 Pod 將被保留。這不會改變受影響的Pod，也不會改變要在其中進(jìn)行的調(diào)查過程。

這對于隔離節(jié)點(diǎn)并調(diào)查由于容器逃逸而導(dǎo)致的危害非常有用。順便說一句，在本文中，我們僅僅假設(shè)攻擊將仍然局限于受影響的 pod。

我們已經(jīng)執(zhí)行了一些必要的步驟來隔離受影響 Pod 中的惡意執(zhí)行。使用 Kubernetes 網(wǎng)絡(luò)策略，我們已經(jīng)確定不允許來自受影響的 pod 的傳入或傳出連接。此外，我們標(biāo)記了涉及的 Pod，并阻止在 Pod 運(yùn)行的節(jié)點(diǎn)中進(jìn)行新的部署。有時，你還可以刪除或撤銷受影響的工作節(jié)點(diǎn)/Pod 權(quán)限或安全憑證，以避免攻擊傳播到其他云資源。

但是，我們?nèi)匀恍枰私夤羰侨绾伟l(fā)生的，我們承擔(dān)的風(fēng)險是什么，以及它可能產(chǎn)生的影響。

DFIR Kubernetes方法——快速方法

它可以被認(rèn)為是最快的方法。將正在運(yùn)行的容器隔離并仍在 Kubernetes 集群中運(yùn)行，你可以直接從其工作節(jié)點(diǎn)檢查它。

現(xiàn)在，讓我們跳轉(zhuǎn)到該節(jié)點(diǎn)并開始搜索受影響的容器 ID。

現(xiàn)在我們知道了哪個是容器ID，這樣就可以開始深入挖掘它的細(xì)節(jié)。

似乎在 Elasticsearch 收到日志前幾秒鐘，在 Tomcat 上部署了一個新的 war 文件。這可能是攻擊的初始訪問，但讓我們繼續(xù)檢查容器文件系統(tǒng)自創(chuàng)建以來的更改。

更改：C 行是更改后的目錄。

追加：A 行是新添加的文件。

如前所述，似乎在 Tomcat 管理器中添加的文件很少。而且，文件系統(tǒng)中還寫入了其他文件，例如 zzz(已經(jīng)在上面的 Elasticsearch 日志中顯示)。

為了查看機(jī)器中還有什么在運(yùn)行，我們還可以啟動docker top和stats命令。

高 CPU 使用率，確認(rèn)之前檢測到的內(nèi)容。

我們還可以將容器的更改提交到新映像(通過 docker commit)或?qū)⑹苡绊懙奈募到y(tǒng)導(dǎo)出為 tar 文件(通過 docker export)，以便存儲發(fā)生更改的工件。如果你想了解有關(guān)此技術(shù)的更多信息，請查看對惡意 Docker 容器進(jìn)行分類。

DFIR Kubernetes——離線方法

Docker-explorer 是一個開源項(xiàng)目，能夠?qū)煺站磉M(jìn)行離線取證分析。

一旦我們確定了受影響的 Pod 所在的 Kubernetes 工作節(jié)點(diǎn)，最好的做法是對其文件系統(tǒng)進(jìn)行快照。這可以通過云提供商控制臺或通過采用其他一些開源項(xiàng)目來完成，例如 cloud-forensics-utils。有了快照卷，就可以進(jìn)行事后分析，將其附加并安裝到將使用 docker-explorer 的新虛擬機(jī)上。

Docker-explorer 可以列出所有 docker 容器或僅列出已安裝卷中正在運(yùn)行的容器。

一旦我們獲得了我們想要調(diào)查的容器 ID，就可以提取日志，就像我們之前使用 docker logs

但最重要的功能是使用 docker-explorer 將容器文件系統(tǒng)掛載到 VM 中。

這將使我們能夠訪問受影響的容器文件系統(tǒng)。因此，從現(xiàn)在開始，我們將能夠調(diào)查之前監(jiān)控的進(jìn)程和文件(zzz、kdevtmpfsi、kinsing)。

例如，我們可以讀取 zzz bash 腳本，或者我們可以提取 ELF 文件的哈希值，以便通過 VirusTotal 對其進(jìn)行掃描。

正如預(yù)期的那樣，由于使用了大量的 CPU，kdevtmpfsi 進(jìn)程是一個挖礦程序。

Kube-forensics

kube-forensics 是一個開源項(xiàng)目，允許集群管理員將任何受影響的 pod 的工件存儲到 S3 存儲桶中。它要求 kube-forensics 創(chuàng)建的工作 pod 具有將對象寫入 AWS 存儲桶的必要權(quán)限。

這樣我們就可以將受影響的 Pod 證據(jù)存儲到應(yīng)用此 PodCheckpoint 的 S3 存儲中：

幾分鐘后，PodCheckpoint 將完成其執(zhí)行，證據(jù)也會出現(xiàn)在目標(biāo) S3 存儲桶中。

因此，除了保存 pod 描述之外，kube-forensics 還以與我們之前在實(shí)時主機(jī)部分中所做的類似方式存儲與 docker inspect 和 docker diff 命令相關(guān)的結(jié)果。

對于“...export.tar”文件，它是可以通過 docker export 命令獲得的文件，它可以將容器文件系統(tǒng)存儲在可以檢查發(fā)布的“.tar”文件中。

Kubernetes事件的解決和總結(jié)

通過分析和調(diào)查違規(guī)行為，你可以識別你在集群中部署的易受攻擊的資產(chǎn)。

在此示例中，攻擊入口點(diǎn)由暴露在網(wǎng)絡(luò)中的易受攻擊的 Tomcat Pod 表示。取證分析得出的結(jié)論是 Tomcat 管理器不安全，因?yàn)樗渲缅e誤并且沒有影響其他 Pod 或命名空間。

不過，有時受感染的 Pod 可能會由于眾所周知或未知的漏洞而被利用。

作為事件響應(yīng)階段的一部分，你應(yīng)該從受感染的 Pod 中學(xué)習(xí)，用更新和安全的 Pod 替換它們。但是，如果無法保護(hù)你的工作負(fù)載，可能是因?yàn)樗鼈冞€沒有可用的補(bǔ)丁，你應(yīng)該采用其他解決方案。

例如，第一個是在發(fā)布新補(bǔ)丁之前刪除和刪除你的部署，只要你有足夠的關(guān)于發(fā)生的事情的信息。這是防止發(fā)生任何違規(guī)的最嚴(yán)格的方法，但它也會在可用性方面影響你的業(yè)務(wù)。

在其他一些情況下，你可能希望使用 Falco 和 Falcosidekick 來設(shè)置你的 Kubernetes 響應(yīng)引擎。當(dāng)通過 Falco 觸發(fā)特定事件時，它允許你在 Kubernetes 集群中做出響應(yīng)。例如，在前面的場景中，如果將具有通用文件名的新 .war 文件部署到 Tomcat 管理器中或檢測到 RCE，我們可以采用終止 pod 的規(guī)則。

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