Falco 實作 Kubernetes 實時威脅偵測與防禦

– 10 分鐘閱讀

破解 Kubernetes 叢集的加密貨幣挖礦攻擊：深度防禦策略

加密貨幣挖礦攻擊就像網路世界的寄生蟲，悄悄地吸取你的 Kubernetes 叢集資源，影回應用程式效能，甚至造成經濟損失。我曾親身經歷這類別攻擊的嚴重性，因此，分享我的經驗和見解，幫助大家建立有效的防禦機制，保護 Kubernetes 叢集的安全。

挖礦攻擊的運作模式

區塊鏈技術的興起帶動了加密貨幣的發展，但也滋生了挖礦攻擊。攻擊者利用系統漏洞，在你的 Kubernetes 叢集中植入挖礦程式，竊取計算資源來驗證加密貨幣交易，從中獲利。這種攻擊手法隱蔽性高，初期難以察覺，但隨著時間推移，會對叢集效能造成顯著影響。

想像一下，你的叢集就像一座繁忙的港口，每個 Pod 都是一艘貨輪，負責運輸不同的應用程式。挖礦程式就像偷偷溜進港口的走私船，佔用寶貴的碼頭空間和資源，導致其他貨輪延誤，港口運作效率下降。

多層次防禦策略：建立銅牆鐵壁

為了有效防禦挖礦攻擊，我建議採用多層次防禦策略，就像為港口建立多道防線，層層設防，將威脅阻擋在外。

第一層：網路連線監控 - 識別可疑流量

挖礦程式通常需要連線到礦池伺服器才能運作，因此監控網路流量是偵測挖礦活動的第一道防線，就像港口的雷達系統，掃描進出港口的船隻，識別可疑目標。

Falco 是一款開源的雲原生執行時安全工具，可以監控系統呼叫和網路活動，偵測異常行為。以下是一個使用 Falco 規則偵測連線到已知礦池連線埠的範例：

- rule: Detect outbound connections to common miner pool ports
  desc: Miners typically connect to miner pools on common ports.
  condition: net_miner_pool and not trusted_images_query_miner_domain_dns
  enabled: true
  output: Outbound connection to IP/Port flagged by cryptoioc.ch (command=%proc.cmdline port=%fd.rport ip=%fd.rip container=%container.info image=%container.image.repository)
  priority: CRITICAL
  tags: [network, mitre_execution]

這段 Falco 規則會監控所有 Pod 的對外網路連線。net_miner_pool 條件會檢查連線的目標連線埠是否在已知礦池連線埠列表中。trusted_images_query_miner_domain_dns 條件則用於排除合法查詢礦池網域的 DNS 請求，避免誤報。一旦發現可疑連線，Falco 就會觸發警示，並提供詳細的連線資訊，例如連線指令、連線埠、IP 位址、容器資訊和映像檔名稱，方便安全團隊追蹤和分析。

  graph LR
    B[B]
A[Pod] --> B{連線到礦池連線埠?};
B -- Yes --> C[觸發 Falco 警示];
B -- No --> D[正常流量];

這個流程圖展示了 Falco 規則如何判斷網路連線是否連線到礦池連線埠，並觸發警示。

然而，僅依靠礦池 IP 和連線埠列表的規則不夠靈活。礦池伺服器地址和連線埠可能變化，攻擊者也可能使用新的礦池或連線埠來規避偵測。更有效的方法是採用白名單策略，只允許連線到預先核准的 IP 位址和連線埠。

- list: trusted_server_addresses
  items: [...]
- list: trusted_server_ports
  items: [...]
- rule: Detect anomalous outbound connections
  desc: Detect anomalous outbound connections
  condition: (evt.type in (sendto, sendmsg) and container and evt.dir=< and (fd.net != "127.0.0.0/8" and not fd.snet in (trusted_server_addresses) or not fd.sport in (trusted_server_ports)))
  output: Outbound connection to anomalous IP/Port(command=%proc.cmdline port=%fd.rport ip=%fd.rip container=%container.info image=%container.image.repository)
  priority: CRITICAL

這段規則定義了 trusted_server_addresses 和 trusted_server_ports 兩個白名單列表，包含允許連線的 IP 位址和連線埠。任何不在白名單內的對外連線都會觸發警示。這種方法更具彈性，可以有效偵測異常連線，即使目標 IP 看似正常。

第二層：程式行為監控 - 捕捉挖礦程式啟動

除了網路連線，監控程式行為也是重要的偵測手段。挖礦程式通常會在命令列中包含特定的關鍵字，例如 stratum+tcp。Falco 可以偵測這類別程式啟動行為，就像港口的監視器，捕捉可疑人員的活動。

- rule: Detect crypto miners using the Stratum protocol
  desc: Miners typically specify the mining pool to connect to with a URI that begins with 'stratum+tcp'
  condition: spawned_process and proc.cmdline contains "stratum+tcp"
  output: Possible miner running (command=%proc.cmdline container=%container.info image=%container.image.repository)
  priority: CRITICAL
  tags: [process, mitre_execution]

這段 Falco 規則會監控所有新啟動的程式。如果程式的命令列中包含 stratum+tcp 關鍵字，Falco 就會觸發警示，提示可能正在執行挖礦程式。

  graph LR
    A[程式啟動] --> B{命令列包含 stratum+tcp}
    B -- Yes --> C[觸發 Falco 警示]
    B -- No --> D[正常程式]

這個流程圖展示了 Falco 規則如何判斷新啟動的程式是否包含挖礦程式特徵，並觸發警示。

透過結合網路連線監控和程式行為監控，我們可以建立更全面的防禦體系，有效偵測和阻止加密貨幣挖礦攻擊，保護 Kubernetes 叢集的安全和穩定執行。

持續監控和更新安全策略至關重要。攻擊手法不斷演變，安全防禦也需要不斷更新迭代。建議定期更新 Falco 規則和白名單列表，並密切關注最新的安全威脅情報，才能在不斷變化的威脅環境中保持領先地位。

除了 Falco，還可以結合其他安全工具和技術，例如資源限制、映像檔掃描和安全稽核，構建更強大的安全防禦體系。

記住，安全不是一蹴而就的，而是一個持續改進的過程。只有不斷學習、實踐和更新，才能有效保護 Kubernetes 叢集免受各種威脅。

強化 Kubernetes 叢集安全防禦策略

保護 Kubernetes 叢集需要一套全面的安全策略，涵蓋叢集佈建、映像檔建置、應用程式佈署和執行時監控等各個環節。我將分享我的防禦策略和實務經驗，協助您開發更安全的 Kubernetes 環境。

Kubernetes 叢集佈建安全

無論您選擇 kops、kubeadm 或其他工具來佈建叢集，每個 Kubernetes 元件的安全設定都至關重要。我推薦使用 kube-bench 評估叢集的基準安全性，並據此強化設定。以下是在叢集佈建階段必須注意的關鍵環節：

  1. RBAC 啟用與匿名驗證停用: 啟用根據角色的存取控制 (RBAC)，並停用 --anonymous-auth 標誌，確保只有經過授權的使用者才能存取叢集資源。

  2. 加密網路連線: 所有 Kubernetes 元件之間的通訊都必須加密，例如 kube-apiserver、kubelet 和 etcd 之間的連線。

  3. 靜態資料加密: 啟用 etcd 的靜態資料加密，保護敏感資訊。

  4. 最小化元件: 只啟動必要的元件，例如停用非必要的 Dashboard，減少攻擊面。

  5. 啟用必要的准入控制器: 啟用必要的准入控制器，並停用過時的控制器，強化安全性。

  graph LR
    C[C]
    subgraph 控制平面
        A((kube-apiserver)) --> B[(etcd)]
        A --> C{{kube-scheduler}}
        A --> D[kube-controller-manager]
    end
    E>kubelet] --> A
    F((kube-proxy)) --> A

上圖展示了 Kubernetes 主要元件之間的通訊關係，kube-apiserver 作為中心節點，與 etcd、kube-scheduler、kube-controller-manager 等元件進行通訊。kubelet 和 kube-proxy 則與 kube-apiserver 互動。kube-apiserver 的安全設定至關重要，因為它是所有請求的入口。

透過這些安全措施，可以有效降低駭客入侵叢集的風險，避免類別似 Tesla 叢集因 Dashboard 未啟用驗證而遭受攻擊的事件。

建置階段安全

微服務的安全始於 CI/CD 流程的建置階段。以下是我在建置階段採取的關鍵措施：

  1. 漏洞掃描: 使用映像檔掃描工具找出微服務的漏洞，並立即修復，降低被入侵的風險。

  2. Dockerfile 安全基準測試: 檢查 Dockerfile 的安全設定，確保映像檔中不包含敏感資料，所有套件都已更新。

  3. 可執行檔掃描: 掃描映像檔中的可執行檔，確保沒有惡意程式碼。

  4. Kubernetes 安全上下文: 正確設定工作負載的安全上下文，遵循最小許可權原則，限制對系統資源的存取，例如主機層級名稱空間和主機路徑，並移除不必要的 Linux 功能。

  5. 服務帳戶: 不要啟用自動掛載服務帳戶，如果工作負載不需要服務帳戶，就不要建立。

  6. 資源限制: 遵循最小許可權原則，評估工作負載的資源使用情況，並設定適當的資源請求和限制。

佈署階段安全

准入控制器是 Kubernetes 叢集中的重要安全閘道器。以下是一些關鍵的防禦措施：

  1. 網路策略: 為名稱空間和工作負載設定網路策略，限制對工作負載的存取（入站網路策略）或實施最小許可權原則（出站網路策略）。例如，如果知道工作負載的出站連線目標 IP 區塊，應該建立網路策略來限制其出站連線，例如阻止從命令和控制伺服器下載挖礦程式。

  2. Open Policy Agent (OPA): 使用 OPA 確保只有來自受信任映像檔倉函式庫的映像檔才能在叢集中執行。例如，來自 Docker Hub 的公開映像檔不應被視為受信任的來源。

  3. 映像檔掃描准入控制器: 確保只有符合掃描策略的映像檔才能在叢集中執行。新的漏洞可能會被發現，漏洞資料函式庫也會在佈署工作負載時更新，因此佈署前掃描非常重要。

  4. OPA 或 Pod 安全策略: 使用 OPA 或 Pod 安全策略來限制工作負載的 Linux 功能，並限制對主機層級名稱空間和主機路徑的存取。

  5. AppArmor: 在工作節點上啟用 AppArmor，並為每個佈署的映像檔套用 AppArmor 設定檔。良好的 AppArmor 設定檔可以將允許的程式列入白名單，從而阻止其他程式（例如挖礦程式）執行。

執行時安全

Kubernetes 叢集通常是抵禦駭客攻擊的第一線。雖然我們討論了各種保護建置和佈署的策略，但所有這些策略最終目標都是減少叢集中的攻擊面。以下是在執行時保護叢集的一些關鍵措施：

  1. 資源監控: 佈署監控工具，例如 Prometheus 和 Grafana，監控叢集中的資源使用情況。這對於確保服務可用性至關重要，因為挖礦等攻擊可能會導致 CPU 使用率飆升。

  2. Kubernetes 稽核策略: 啟用 Kubernetes 稽核策略來記錄 Kubernetes 事件和活動。

  3. 高用性: 確保基礎架構、Kubernetes 元件和應用程式的高用性。

透過以上這些策略，我們可以建立一個更安全的 Kubernetes 叢集環境，有效降低各種攻擊風險。

Kubernetes CVE 教訓

通用漏洞披露 (CVE) 是公開已知安全漏洞和暴露的識別碼，這些漏洞存在於熱門應用程式中，包含 CVE 字串、年份和 ID 號碼。CVE 資料函式庫由 MITRE Corporation 維護並公開提供，每個條目包含問題的簡要描述，有助於理解根本原因和嚴重性，但不包含技術細節。CVE 對於 IT 專業人員協調和排列更新的優先順序很有用。每個 CVE 都有一個相關的嚴重性。MITRE 使用通用漏洞評分系統 (CVSS) 為 CVE 分配嚴重性等級。建議立即修補高嚴重性 CVE。

這篇文章將探討四個 Kubernetes 公開已知的安全漏洞。首先，我們將研究路徑遍歷問題—CVE-2019-11246，它允許攻擊者修改客戶端上的內容，可能導致叢集管理員機器上的資料洩露或程式碼執行。接下來，我們將討論 CVE-2019-1002100，它允許使用者對 API 伺服器發動阻斷服務 (DoS) 攻擊。然後，我們將討論 CVE-2019-11253，它允許未經身份驗證的使用者對 kube-apiserver 發動 DoS 攻擊。最後，我們將討論 CVE-2019-11247，它允許具有名稱空間許可權的使用者修改叢集範圍的資源。我們將討論每個 CVE 的緩解策略。升級到修補漏洞的最新版 Kubernetes 和 kubectl 應是您的首要任務。最後，我們將介紹 kube-hunter，它可以用於掃描 Kubernetes 叢集中的已知安全漏洞。

  graph LR
A[CVE-2019-11246 路徑遍歷] --> B(kubectl cp 漏洞);
C[CVE-2019-1002100 DoS] --> D(JSON 解析漏洞);
E[CVE-2019-11253 DoS] --> F(YAML 解析漏洞);
G[CVE-2019-11247 許可權提升] --> H(角色解析漏洞);
I[kube-hunter] --> J(掃描已知漏洞);

上面的圖表展示了本文將要討論的 Kubernetes CVE 及其相關漏洞型別。這有助於讀者快速瞭解文章結構和主要內容。

使用 kubectl cp 的路徑遍歷問題 - CVE-2019-11246

開發人員經常將檔案複製到 Pod 中的容器或從中複製檔案以進行除錯。kubectl cp 允許開發人員從 Pod 中的容器複製檔案或將檔案複製到 Pod 中的容器（預設情況下，這是在 Pod 中的第一個容器中完成的）。

要將檔案複製到 Pod，您可以使用以下命令：

kubectl cp /tmp/test <pod>:/tmp/bar

要從 Pod 複製檔案，您可以使用以下命令：

kubectl cp <some-pod>:/tmp/foo /tmp/bar

從 pod 複製檔案時，Kubernetes 首先在容器內建立檔案的 TAR 存檔。然後，它將 TAR 存檔複製到客戶端，最後為客戶端解壓縮 TAR 存檔。在 2018 年，研究人員發現了一種使用 kubectl cp 覆寫客戶端主機上檔案的方法。如果攻擊者可以存取 pod，則此漏洞可用於透過使用惡意二進位檔覆寫原始 TAR 二進位檔，將 TAR 存檔替換為使用相對路徑的特殊檔案。當格式錯誤的 TAR 檔案被複製到主機時，它在解壓縮時可能會覆寫主機上的檔案。

以上程式碼片段展示瞭如何使用 kubectl cp 命令在 Pod 和本地檔案系統之間複製檔案。這段程式碼也解釋了 CVE-2019-11246 漏洞的利用方式，即透過惡意 TAR 檔案覆寫主機檔案。

確保 Kubernetes 叢集安全

為了防禦針對 Kubernetes 叢集的攻擊，我們需要端對端地保護 Kubernetes 叢集的組態、構建、佈署和執行時安全。它們都同等重要，因為您的防禦強度取決於您最薄弱的環節。

使用 Vault 等完善的秘密管理工具來管理和組態微服務的秘密。佈署 Falco 等入侵檢測工具來檢測 Kubernetes 叢集中的可疑活動。擁有取證工具來收集和分析可疑事件也是必要的。

這篇文章沒有涵蓋服務網格，原因有二：服務網格會給工作負載和 Kubernetes 叢集帶來效能開銷，因此它們還不是保護服務之間通訊安全的完美解決方案；從應用程式安全的角度來看，很容易使用 CA 簽名的證書強制服務在埠 443 上偵聽，以便對通訊進行加密。如果微服務也執行身份驗證和授權，則只有受信任的微服務才能存取授權資源。服務網格並不是保護服務之間通訊安全的不可替代的解決方案。

總之，Kubernetes 安全需要多方面的考量和持續的努力。透過結合叢集佈建、映像檔建置、應用程式佈署和執行時監控等各個環節的安全策略，並持續學習和改進，才能有效防禦日益複雜的攻擊，確保 Kubernetes 叢集的安全和穩定。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。