本文已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

容器取证分析

作者：Adrian Reber (Red Hat) | 2023 年 3 月 10 日，星期五

在我之前的文章 Kubernetes 中的取证容器检查点中，我介绍了 Kubernetes 中的检查点，以及如何设置和使用它。该功能的名称是取证容器检查点，但我没有详细介绍如何对 Kubernetes 创建的检查点进行实际分析。在本文中，我想详细介绍如何分析检查点。

检查点在 Kubernetes 中仍然是一个 alpha 功能，本文旨在预览该功能在未来可能如何工作。

准备工作

有关如何配置 Kubernetes 和底层 CRI 实现以启用检查点支持的详细信息，请参见我的 Kubernetes 中的取证容器检查点文章。

例如，我准备了一个容器镜像 (quay.io/adrianreber/counter:blog)，我想在本篇文章中对其进行检查点并进行分析。这个容器允许我在容器中创建文件，并将信息存储在内存中，我稍后想在检查点中找到这些信息。

要运行该容器，我需要一个 pod，在本例中，我使用以下 Pod 清单

apiVersion: v1
kind: Pod
metadata:
  name: counters
spec:
  containers:
  - name: counter
    image: quay.io/adrianreber/counter:blog

这会在一个名为 counters 的 pod 中运行一个名为 counter 的容器。

容器运行后，我使用该容器执行以下操作

$ kubectl get pod counters --template '{{.status.podIP}}'
10.88.0.25
$ curl 10.88.0.25:8088/create?test-file
$ curl 10.88.0.25:8088/secret?RANDOM_1432_KEY
$ curl 10.88.0.25:8088

第一次访问会在容器中创建一个名为 test-file 的文件，内容为 test-file，第二次访问会将我的秘密信息 (RANDOM_1432_KEY) 存储在容器内存中的某个位置。最后一次访问只是向内部日志文件添加一个额外的行。

分析检查点之前的最后一步是告诉 Kubernetes 创建检查点。如上一篇文章所述，这需要访问 kubelet 仅 checkpoint API 端点。

对于名为 counter 的容器，位于名为 counters 的 pod 中，位于名为 default 的命名空间中，kubelet API 端点可在以下位置访问

# run this on the node where that Pod is executing
curl -X POST "https://127.0.0.1:10250/checkpoint/default/counters/counter"

为了完整起见，以下 curl 命令行选项是必要的，以使 curl 接受 kubelet 的自签名证书并授权使用 kubelet checkpoint API

--insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key

检查点完成后，检查点应在 /var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar 可用

在本文的后续步骤中，我将在分析检查点存档时使用名称 checkpoint.tar。

使用 `checkpointctl` 进行检查点存档分析

为了获取有关检查点容器的一些初始信息，我使用工具 checkpointctl，如下所示

$ checkpointctl show checkpoint.tar --print-stats
+-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+
| CONTAINER |              IMAGE               |      ID      | RUNTIME |       CREATED       | ENGINE |     IP     | CHKPT SIZE | ROOT FS DIFF SIZE |
+-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+
| counter   | quay.io/adrianreber/counter:blog | 059a219a22e5 | runc    | 2023-03-02T06:06:49 | CRI-O  | 10.88.0.23 | 8.6 MiB    | 3.0 KiB           |
+-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+
CRIU dump statistics
+---------------+-------------+--------------+---------------+---------------+---------------+
| FREEZING TIME | FROZEN TIME | MEMDUMP TIME | MEMWRITE TIME | PAGES SCANNED | PAGES WRITTEN |
+---------------+-------------+--------------+---------------+---------------+---------------+
| 100809 us     | 119627 us   | 11602 us     | 7379 us       |          7800 |          2198 |
+---------------+-------------+--------------+---------------+---------------+---------------+

这已经给了我一些关于检查点存档中检查点的信息。我可以看到容器的名称，关于容器运行时和容器引擎的信息。它还列出了检查点的大小 (CHKPT SIZE)。这主要是检查点中包含的内存页的大小，但也包含容器中所有更改的文件的大小信息 (ROOT FS DIFF SIZE)。

附加参数 --print-stats 对检查点存档中的信息进行解码，并在第二个表（CRIU 转储统计信息）中显示它们。此信息在检查点创建期间收集，概述了 CRIU 需要多少时间来检查容器中的进程，以及在检查点创建期间分析和写入了多少内存页。

深入研究

借助 checkpointctl，我可以获得一些关于检查点存档的高级信息。为了能够进一步分析检查点存档，我必须将其提取出来。检查点存档是一个 tar 存档，可以使用 tar xf checkpoint.tar 进行提取。

提取检查点存档将产生以下文件和目录

bind.mounts - 此文件包含有关绑定挂载的信息，在还原期间需要此文件，以将所有外部文件和目录挂载到正确的位置
checkpoint/ - 此目录包含由 CRIU 创建的实际检查点
config.dump 和 spec.dump - 这些文件包含还原期间所需的关于容器的元数据
dump.log - 此文件包含在检查点期间创建的 CRIU 的调试输出
stats-dump - 此文件包含 checkpointctl 用于显示转储统计信息 (--print-stats) 的数据
rootfs-diff.tar - 此文件包含容器文件系统上所有已更改的文件

文件系统更改 - `rootfs-diff.tar`

进一步分析容器检查点的第一步是查看我的容器中已更改的文件。这可以通过查看文件 rootfs-diff.tar 来完成

$ tar xvf rootfs-diff.tar
home/counter/logfile
home/counter/test-file

现在可以研究容器中更改的文件

$ cat home/counter/logfile
10.88.0.1 - - [02/Mar/2023 06:07:29] "GET /create?test-file HTTP/1.1" 200 -
10.88.0.1 - - [02/Mar/2023 06:07:40] "GET /secret?RANDOM_1432_KEY HTTP/1.1" 200 -
10.88.0.1 - - [02/Mar/2023 06:07:43] "GET / HTTP/1.1" 200 -
$ cat home/counter/test-file
test-file

与容器镜像 (quay.io/adrianreber/counter:blog) 这个容器所基于的镜像相比，我可以看到文件 logfile 包含有关对容器提供的服务的所有访问的信息，并且文件 test-file 正如预期的那样被创建了。

借助 rootfs-diff.tar，可以检查所有与容器的基础镜像相比被创建或更改的文件。

分析检查点进程 - `checkpoint/`

目录 checkpoint/ 包含 CRIU 在检查点容器中的进程时创建的数据。目录 checkpoint/ 中的内容由不同的镜像文件组成，可以使用作为 CRIU 一部分分发的工具 CRIT 进行分析。

首先，让我们了解一下容器内部的进程

$ crit show checkpoint/pstree.img | jq .entries[].pid
1
7
8

此输出表示我的容器的 PID 命名空间内有三个进程，其 PID 为：1、7、8

这只是容器的 PID 命名空间内部的视图。在还原期间，将重新创建这些确切的 PID。从容器的 PID 命名空间外部，PID 将在还原后更改。

下一步是获取有关这三个进程的一些其他信息

$ crit show checkpoint/core-1.img | jq .entries[0].tc.comm
"bash"
$ crit show checkpoint/core-7.img | jq .entries[0].tc.comm
"counter.py"
$ crit show checkpoint/core-8.img | jq .entries[0].tc.comm
"tee"

这意味着我的容器中的三个进程是 bash、counter.py（一个 Python 解释器）和 tee。有关这些进程的父子关系的详细信息，可以在 checkpoint/pstree.img 中分析更多数据。

让我们将迄今为止收集的信息与仍在运行的容器进行比较

$ crictl inspect --output go-template --template "{{(index .info.pid)}}" 059a219a22e56
722520
$ ps auxf | grep -A 2 722520
fedora    722520  \_ bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile
fedora    722541      \_ /usr/bin/python3 /home/counter/counter.py
fedora    722542      \_ /usr/bin/coreutils --coreutils-prog-shebang=tee /usr/bin/tee /home/counter/logfile
$ cat /proc/722520/comm
bash
$ cat /proc/722541/comm
counter.py
$ cat /proc/722542/comm
tee

在此输出中，我首先检索容器中第一个进程的 PID，然后在容器运行的系统上查找该 PID 和子进程。我看到三个进程，第一个进程是 “bash”，它是容器 PID 命名空间内部的 PID 1。然后我查看 /proc/<PID>/comm，我找到了与检查点映像中完全相同的值。

重要的是要记住，检查点将包含来自容器 PID 命名空间内的视图，因为该信息对于还原进程至关重要。

关于 crit 可以告诉我们关于容器的最后一个示例是关于 UTS 命名空间的信息

$ crit show checkpoint/utsns-12.img
{
    "magic": "UTSNS",
    "entries": [
        {
            "nodename": "counters",
            "domainname": "(none)"
        }
    ]
}

这告诉我 UTS 命名空间内部的主机名是 counters。

对于 CRIU 在检查点期间收集的每个资源，checkpoint/ 目录都包含相应的镜像文件，可以使用 crit 进行分析。

查看内存页

除了可以使用 CRIT 解码的来自 CRIU 的信息之外，还有一些文件包含 CRIU 写入磁盘的原始内存页

$ ls  checkpoint/pages-*
checkpoint/pages-1.img  checkpoint/pages-2.img  checkpoint/pages-3.img

当我最初使用容器时，我在内存中的某个位置存储了一个随机密钥（RANDOM_1432_KEY）。让我们看看是否能找到它。

$ grep -ao RANDOM_1432_KEY checkpoint/pages-*
checkpoint/pages-2.img:RANDOM_1432_KEY

果然，我的数据就在那里。这样我可以轻松地查看容器中所有进程的内存页面内容，但也要记住，任何可以访问检查点归档文件的人都可以访问容器进程内存中存储的所有信息。

使用 gdb 进行进一步分析

查看检查点镜像的另一种方法是使用 gdb。CRIU 存储库包含一个脚本 coredump，它可以将检查点转换为 coredump 文件。

$ /home/criu/coredump/coredump-python3
$ ls -al core*
core.1  core.7  core.8

运行 coredump-python3 脚本会将检查点镜像转换为容器中每个进程的一个 coredump 文件。使用 gdb 我也可以查看进程的详细信息。

$ echo info registers | gdb --core checkpoint/core.1 -q

[New LWP 1]

Core was generated by `bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile'.

#0  0x00007fefba110198 in ?? ()
(gdb)
rax            0x3d                61
rbx            0x8                 8
rcx            0x7fefba11019a      140667595587994
rdx            0x0                 0
rsi            0x7fffed9c1110      140737179816208
rdi            0xffffffff          4294967295
rbp            0x1                 0x1
rsp            0x7fffed9c10e8      0x7fffed9c10e8
r8             0x1                 1
r9             0x0                 0
r10            0x0                 0
r11            0x246               582
r12            0x0                 0
r13            0x7fffed9c1170      140737179816304
r14            0x0                 0
r15            0x0                 0
rip            0x7fefba110198      0x7fefba110198
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

在这个例子中，我可以看到检查点创建时所有寄存器的值，也可以看到容器 PID 1 进程的完整命令行：bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile。

总结

借助容器检查点技术，可以在不停止容器且容器不知情的情况下创建正在运行的容器的检查点。在 Kubernetes 中检查容器的结果是一个检查点归档文件；可以使用 checkpointctl、tar、crit 和 gdb 等不同工具来分析检查点。即使使用 grep 这样的简单工具，也可以在检查点归档文件中找到信息。

我在这篇文章中展示的分析检查点的不同示例只是一个起点。根据您的需求，您可以更详细地查看某些内容，但本文应该为您提供如何开始分析检查点的入门指南。

如何参与？

您可以通过多种方式联系 SIG Node