返回文章列表
玄貓（BlackCat）

Falco與CRIU開發K8s安全鑑識

本文探討如何運用 Falco 建立 Kubernetes 稽核規則，以及結合 CRIU 與 Sysdig Inspect 進行容器化環境的數位鑑識。Falco 允許建立根據系統呼叫和 Kubernetes 稽核事件的規則，以檢測異常活動。CRIU 則可儲存和還原容器狀態，方便在沙盒環境中進行分析。Sysdig 和

資安 容器化
Falco Kubernetes CRIU Sysdig 安全 鑑識

在 Kubernetes 環境中，安全防護與事件調查至關重要。Falco 提供了即時的異常檢測能力，能有效識別潛在威脅。本文除了 Falco 規則建立外，更進一步介紹 CRIU 與 Sysdig Inspect 的整合應用，讓開發者能完整掌握容器狀態，並在安全事件發生時，快速進行數位鑑識，有效縮短事件調查時間，降低損失。透過這些工具的整合，可以更全面地保護 Kubernetes 叢集的安全。

使用Falco進行異常檢測與K8s稽核規則建立

Falco是一款強大的開源工具，用於檢測Kubernetes叢集中的異常活動和潛在安全威脅。它透過分析系統呼叫和Kubernetes稽核事件來實作這一目標。在本文中，我們將探討如何使用Falco建立自定義規則，以檢測特定的安全問題。

建立Sysdig篩選欄位規則

Sysdig篩選欄位是Falco用於建立規則的重要組成部分。常見的Sysdig篩選欄位包括：

  • proc.name：行程名稱
  • fd.name：被讀取或寫入的檔案名稱
  • container.id：容器ID
  • container.image.repository：容器映像名稱（不含標籤）
  • fd.sip和fd.sport：伺服器IP位址和伺服器連線埠
  • evt.type：系統呼叫事件型別（例如：open、connect、accept、execve等）

建立簡單的Falco規則

假設我們有一個Nginx Pod，它僅從/usr/share/nginx/html/目錄提供靜態檔案。我們可以建立一個Falco規則來檢測任何異常的檔案讀取活動，如下所示：

- rule: Anomalous read in nginx pod
  desc: Detect any anomalous file read activities in Nginx pod.
  condition: (open_read and container and container.image.repository="kaizheh/insecure-nginx" and fd.directory != "/usr/share/nginx/html")
  output: Anomalous file read activity in Nginx pod (user=%user.name process=%proc.name file=%fd.name container_id=%container.id image=%container.image.repository)
  priority: WARNING

此規則使用了兩個預設巨集：open_read和container。open_read巨集檢查系統呼叫事件是否為開啟檔案以進行讀取，而container巨集檢查系統呼叫事件是否發生在容器內。

程式碼解析

- rule: Anomalous read in nginx pod
  desc: Detect any anomalous file read activities in Nginx pod.
  condition: (open_read and container and container.image.repository="kaizheh/insecure-nginx" and fd.directory != "/usr/share/nginx/html")
  output: Anomalous file read activity in Nginx pod (user=%user.name process=%proc.name file=%fd.name container_id=%container.id image=%container.image.repository)
  priority: WARNING

內容解密：

  1. rule: 定義規則的名稱，這裡是「Anomalous read in nginx pod」。
  2. desc: 對規則的描述，解釋了該規則的目的。
  3. condition: 觸發規則的條件。這裡檢查了四個條件：
    • open_read：系統呼叫事件是開啟檔案以進行讀取。
    • container：事件發生在容器內。
    • container.image.repository="kaizheh/insecure-nginx"：容器的映像名稱為「kaizheh/insecure-nginx」。
    • fd.directory != "/usr/share/nginx/html"：讀取的檔案目錄不是「/usr/share/nginx/html」。
  4. output: 當規則被觸發時輸出的訊息，包含了多個變數，如使用者名稱、行程名稱、檔案名稱等。
  5. priority: 規則的優先順序，這裡設定為「WARNING」。

建立K8s稽核規則

K8s稽核規則評估Kubernetes稽核事件。我們可以使用JSON指標或Falco內建篩選器來檢索Kubernetes稽核事件的資訊。常見的Falco內建篩選器包括：

  • ka.verb：Kubernetes稽核事件的動詞欄位。
  • ka.target.resource：Kubernetes稽核事件的資源欄位。
  • ka.user.name：Kubernetes稽核事件的使用者名稱欄位。
  • ka.uri：Kubernetes稽核事件的請求URI欄位。

建立簡單的K8s稽核規則

假設我們不希望在kube-system名稱空間中佈署除幾個受信任映像以外的其他映像。我們可以建立一個Falco規則，如下所示：

- list: trusted_images
  items: [calico/node, kopeio/etcd-manager, k8s.gcr.io/kube-apiserver, k8s.gcr.io/kube-controller-manager, k8s.gcr.io/kube-proxy, k8s.gcr.io/kube-scheduler]

- rule: Untrusted Image Deployed in kube-system Namespace
  desc: Detect an untrusted image deployed in kube-system namespace
  condition: kevt and pod and kcreate and ka.target.namespace=kube-system and not ka.req.pod.containers.image.repository in (trusted_images)
  output: Untrusted image deployed in kube-system namespace (user=%ka.user.name image=%ka.req.pod.containers.image.repository resource=%ka.target.name)

此規則首先定義了一個受信任映像的列表，然後檢查在kube-system名稱空間中建立的Pod是否使用了列表中的映像。

程式碼解析

- list: trusted_images
  items: [calico/node, kopeio/etcd-manager, k8s.gcr.io/kube-apiserver, k8s.gcr.io/kube-controller-manager, k8s.gcr.io/kube-proxy, k8s.gcr.io/kube-scheduler]

- rule: Untrusted Image Deployed in kube-system Namespace
  desc: Detect an untrusted image deployed in kube-system namespace
  condition: kevt and pod and kcreate and ka.target.namespace=kube-system and not ka.req.pod.containers.image.repository in (trusted_images)
  output: Untrusted image deployed in kube-system namespace (user=%ka.user.name image=%ka.req.pod.containers.image.repository resource=%ka.target.name)

內容解密：

  1. list: trusted_images: 定義了一個名為「trusted_images」的列表，包含了受信任的映像名稱。
  2. rule: 定義了規則「Untrusted Image Deployed in kube-system Namespace」。
  3. desc: 描述了該規則的目的，即檢測在kube-system名稱空間中佈署不受信任的映像。
  4. condition: 設定了觸發規則的條件，包括：
    • kevt：事件是Kubernetes稽核事件。
    • pod：事件與Pod相關。
    • kcreate：事件是建立Pod的操作。
    • ka.target.namespace=kube-system：事件發生在kube-system名稱空間。
    • not ka.req.pod.containers.image.repository in (trusted_images)：Pod使用的映像不在受信任列表中。
  5. output: 當規則被觸發時輸出的訊息，包含了觸發規則的使用者名稱、映像名稱和資源名稱。

使用Sysdig Inspect和CRIU進行數位鑑識

在上一節中，我們介紹了Falco並展示瞭如何從系統呼叫和Kubernetes稽核事件兩種事件源建立Falco規則。這兩種規則都用於根據工作負載或叢集的已知正常活動來檢測異常活動。接下來，我們將討論如何在Kubernetes叢集中進行數位鑑識。

使用Sysdig Inspect和CRIU進行數位鑑識

在網路安全領域，數位鑑識是指收集、處理和分析資訊，以支援漏洞緩解和/或詐欺、反間諜或執法調查。您可以保留的資料越多，並且對收集的資料進行分析的速度越快，您就能越快地追蹤攻擊並更好地回應事件。在本文中，我們將向您展示如何使用CRIU和Sysdig開源工具收集資料，然後介紹Sysdig Inspect，這是一種用於分析Sysdig收集的資料的開源工具。

使用CRIU收集資料

CRIU是Checkpoint and Restore In Userspace的縮寫。它是一種可以凍結正在執行的容器並將容器的狀態擷取到磁碟上的工具。稍後，可以將儲存在磁碟上的容器和應用程式資料還原到凍結時的狀態。它對於容器快照、遷移和遠端偵錯非常有用。從安全形度來看，它特別適用於捕捉容器中的惡意活動（以便在檢查點之後立即終止容器），然後在沙箱環境中還原狀態以進行進一步分析。

CRIU作為Docker外掛程式，目前仍處於實驗階段，並且存在一個已知問題，即CRIU在最近的幾個版本中無法正常運作（https://github.com/moby/moby/issues/37344）。為了演示目的，我們使用了較舊的Docker版本（Docker CE 17.03），並將展示如何使用CRIU對正在執行的容器進行檢查點並將狀態還原為新容器。

要啟用CRIU，您需要在Docker守護程式中啟用實驗模式，如下所示：

echo "{\"experimental\":true}" >> /etc/docker/daemon.json

然後，在重新啟動Docker守護程式後，您應該能夠成功執行docker checkpoint命令，如下所示：

# docker checkpoint
Usage: docker checkpoint COMMAND
Manage checkpoints
Options:
      --help   Print usage
Commands:
  create    Create a checkpoint from a running container
  ls        List checkpoints for a container
  rm        Remove a checkpoint

內容解密：

  • 首先，我們需要在Docker守護程式設定檔/etc/docker/daemon.json中新增實驗模式的設定。
  • 重新啟動Docker守護程式後，即可使用docker checkpoint命令。
  • docker checkpoint命令用於管理容器的檢查點。

接下來，按照指示安裝CRIU（https://criu.org/Installation）。

簡單範例：使用CRIU檢查點容器

我們有一個簡單的busybox容器正在執行，每秒增加一個計數器，如下所示：

# docker run -d --name looper --security-opt seccomp:unconfined busybox /bin/sh -c 'i=0; while true; do echo $i; i=$(expr $i + 1); sleep 1; done'
91d68fafec8fcf11e7699539dec0b037220b1fcc856fb7050c58ab90ae8cbd13

內容解密：

  • 這個命令會啟動一個名為looper的容器，並執行一個無限迴圈，每秒輸出一個遞增的數字。
  • --security-opt seccomp:unconfined選項用於停用Seccomp組態，以避免某些系統呼叫被阻擋。

等待幾秒後，我們可以看到計數器的輸出，如下所示：

# sleep 5
# docker logs looper
0
1
2
3
4
5

內容解密：

  • docker logs命令用於檢視容器的輸出。
  • 在這個例子中，我們可以看到計數器已經執行了5秒，並輸出了0到5的數字。

接下來，我們將對容器進行檢查點並將狀態儲存在本地檔案系統上，如下所示：

# docker checkpoint create --checkpoint-dir=/tmp looper checkpoint
checkpoint

內容解密：

  • docker checkpoint create命令用於建立容器的檢查點。
  • --checkpoint-dir=/tmp選項指定了檢查點檔案的儲存位置。
  • looper是容器的名稱，checkpoint是檢查點的名稱。

建立檢查點後，除非在建立檢查點時指定了--leave-running旗標，否則容器looper將被終止。

然後，建立一個新的容器，但不啟動它，如下所示：

# docker create --name looper-clone --security-opt seccomp:unconfined busybox /bin/sh -c 'i=0; while true; do echo $i; i=$(expr $i + 1); sleep 1; done'
49b9ade200e7da6bbb07057da02570347ad6fefbfc1499652ed286b874b59f2b

內容解密：

  • docker create命令用於建立一個新的容器，但不啟動它。
  • 新容器的名稱是looper-clone，與原始容器具有相同的組態。

現在，我們可以使用儲存的狀態啟動新的looper-clone容器。等待幾秒後，我們可以看到結果，如下所示：

# docker start --checkpoint-dir=/tmp --checkpoint=checkpoint looper-clone
# sleep 5
# docker logs looper-clone
6
7
8
9
10

內容解密：

  • docker start命令用於啟動容器，並使用儲存的檢查點狀態。
  • --checkpoint-dir=/tmp和--checkpoint=checkpoint選項指定了檢查點檔案的位置和名稱。
  • 在這個例子中，我們可以看到新的容器從上次檢查點的狀態（計數器值為6）繼續執行。

容器化環境中的數位鑑識：CRIU 與 Sysdig Inspect 的應用

在現代化的容器化環境中，安全威脅的偵測與分析變得越來越重要。當容器內發生可疑活動時，如何有效地進行數位鑑識，成為了維護系統安全的關鍵課題。本文將探討兩種強大的工具：CRIU 和 Sysdig Inspect，並介紹它們在容器鑑識中的應用。

利用 CRIU 進行容器狀態儲存與還原

CRIU（Checkpoint/Restore In Userspace）是一種強大的工具，能夠對正在執行的容器進行狀態儲存（checkpoint）和還原（restore）。這種功能在容器鑑識中非常有用，尤其是在需要對可疑容器進行詳細分析時。

CRIU 的工作原理

CRIU 能夠將容器的當前狀態儲存到磁碟上，包括其記憶體狀態、處理程式狀態等。這使得我們可以在不影響原始容器的情況下，對儲存的狀態進行分析。

使用 CRIU 進行容器鑑識

  1. 儲存容器狀態：使用 CRIU 將可疑容器的狀態儲存下來。
  2. 終止可疑容器：為防止進一步的損害，可以終止該容器。
  3. 在沙盒環境中還原容器狀態：將儲存的狀態在一個隔離的沙盒環境中還原，以便進行深入分析。

程式碼範例

# 儲存容器狀態
criu dump --tree <container_pid> --images-dir ./checkpoint

# 還原容器狀態
criu restore --images-dir ./checkpoint

內容解密：

  • criu dump 命令用於儲存容器的狀態，--tree 引數指定要儲存的處理程式樹，<container_pid> 是容器的處理程式 ID。
  • --images-dir 引數指定儲存狀態的目錄。
  • criu restore 命令用於還原容器的狀態，同樣使用 --images-dir 引數指定狀態儲存的目錄。

利用 Sysdig 和 Sysdig Inspect 進行系統活動捕捉與分析

Sysdig 是另一種強大的開源工具，用於 Linux 系統的探索和故障排除，支援容器環境。Sysdig 可以捕捉系統呼叫和其他作業系統事件，使其成為容器化環境中進行數位鑑識的理想工具。

使用 Sysdig 和 Sysdig Inspect 的步驟

  1. 安裝 Sysdig kubectl 外掛：下載並安裝 kubectl-capture，這使得捕捉特定 Pod 的系統呼叫變得簡單。

    # 下載 kubectl-capture
wget https://github.com/sysdiglabs/kubectl-capture/releases/download/v0.1.0/kubectl-capture_0.1.0_linux_amd64.tar.gz

# 解壓並放置到適當的位置
tar -xvf kubectl-capture_0.1.0_linux_amd64.tar.gz
mv kubectl-capture /usr/local/bin/

    內容解密：

    • 使用 wget 命令下載 kubectl-capture 的壓縮檔。
    • 使用 tar 命令解壓縮檔案。
    • 將 kubectl-capture 移動到系統的可執行路徑下，如 /usr/local/bin/。

  2. 捕捉 Pod 的系統活動：使用 kubectl capture 命令捕捉可疑 Pod 的系統呼叫。

    # 捕捉特定 Pod 的系統呼叫
kubectl capture <pod_name> -n <namespace>

    內容解密：

    • kubectl capture 命令啟動對指定 Pod 的系統呼叫捕捉。
    • <pod_name> 是目標 Pod 的名稱，<namespace> 是 Pod 所屬的名稱空間。

  3. 使用 Sysdig Inspect 分析捕捉資料：將捕捉的資料匯入 Sysdig Inspect 進行詳細分析。

    # 啟動 Sysdig Inspect Docker 容器
docker run -d -v /path/to/capture:/captures -p 3000:3000 sysdig/sysdig-inspect:latest

# 瀏覽 http://localhost:3000 檢視分析結果

    內容解密：

    • 使用 Docker 啟動 Sysdig Inspect 容器，將捕捉檔案掛載到 /captures 目錄，並對映埠號 3000。
    • 在瀏覽器中存取 http://localhost:3000 以檢視分析結果。

結合 CRIU 和 Sysdig Inspect 進行深入分析

透過結合 CRIU 和 Sysdig Inspect，我們可以對容器化環境中的安全事件進行深入分析。CRIU 能夠幫助我們儲存和還原容器的狀態，而 Sysdig Inspect 則提供了對系統活動的詳細洞察。這兩種工具的結合，使得我們能夠更有效地進行數位鑑識和安全分析。