深入浅出云原生环境信息收集技术（二）_安全_阮博男

FinOps有望降低企业50%+的云成本！了解详情 



 写点什么

摘要

信息收集在攻击和防御两端都是非常重要的一环，优质的信息收集成果是后续工作顺利展开的首要条件。然而，信息的琐碎性和云原生本身的复杂组成为云原生环境下的信息收集工作带来了一定挑战。本文将分享体系化的云原生环境信息收集思路和方法。

前言

信息收集在攻击和防御两端都是非常重要的一环。从宏观的角度来说，大多数信息相关的工作都可以看作信息收集和信息处理交替进行的循环。优质的信息收集成果是后续工作顺利展开的首要条件。《孙子兵法》有云：故善战人之势，如转圆石于千仞之山者，势也。在掌握了充足信息后，攻防工作将“如转圆石于千仞之山”。

然而，信息的琐碎性和云原生本身的复杂组成为云原生环境下的信息收集工作带来了一定挑战。有些朋友也许会说，这有何难？比如，执行 uname -a 命令，就能收集到内核信息了。没错，信息收集确实是一步步进行、一项项完成的。但是，如果只是想当然地进行，收集到的信息难免陷于凌乱琐碎，也很可能不全面。

对此，笔者结合在攻、防两端积累的经验，希望与大家探讨四个问题：

站在攻击者视角，云原生环境下的收集信息方式有哪些？
站在攻击者视角，云原生环境下的信息分类维度有哪些？
站在攻击者视角，收集到的云原生环境信息有什么价值？
站在攻击者视角，有没有可能阻碍或影响防守者收集信息？

就“信息收集”这个话题而言，毫无疑问，防守者是占尽天时地利的，无论是能够收集到的信息种类、规模，还是信息收集开始的时间、收集信息所需的权限，都远远在攻击者之上。防守者更需要关注的是如何使用、分析收集到的信息。因此，我们从攻击者的角度出发进行探讨。这并不意味着防守的同学不需要关注。相反，只有对攻击者的技术了然于胸，才能更好地识别攻击行为、判定攻击意图。

本系列第一篇文章讨论了云原生环境下的收集信息方式，给出“通过远程交互收集信息”、“在容器内收集信息”和“基于镜像收集信息”三种思路。作为本系列的第二篇文章，本文将讨论第二个问题：站在攻击者视角，云原生环境下的信息分类维度有哪些？

注：文中案例相关操作均在实验环境中进行，相关技术仅供研究交流，请勿应用于未授权的渗透测试。

站在攻击者视角，云原生环境下的信息分类维度有哪些？

我们会结合实践从信息收集的“广度与深度”、“软件栈层次”和“特定需求”三个方面来介绍云原生环境下的信息分类维度和体系化的收集思路，其中：

“广度与深度”分别指代收集到的信息覆盖的资产规模和对资产（尤其是可利用性）的了解程度。
“软件栈层次”能够帮助我们对云原生环境的信息收集工作作出具体分层分类。
面向“特定需求”收集信息是一个“补集”性质的选项，相对于全面撒网式收集而言，有时收集少量信息达到目的即可。

1. 信息收集的广度与深度

信息的收集与分类离不开资产，脱离资产空谈信息收集是没有实际意义的。除了扮演攻击者角色的渗透测试同学，从事安全防御和网络空间测绘的同学也都十分重视资产。对于前者来说，有效防御的前提是确保重要资产都处于安全系统和安全管理流程的覆盖范围内，在此基础上不断监控资产状态、收集资产信息，对异常状态和行为进行分析、预警和处置；对于后者来说，测绘能力一定程度上等同于对资产信息的收集分析能力。

站在攻击者的角度，我们也可以将信息关联到资产上，从而将信息分类问题转化为资产分类问题。通常情况下，攻击者不像防守者（尤其是入侵检测系统、EDR 等）那样拥有近乎上帝视角下的信息收集能力，却要比网络空间测绘以外在暴露特征为主的信息收集工作更主动、更有力。攻击者能够、且有必要去挖掘纵深渗透过程中接触到的每一个信息的可利用性。基于这些观察，我们将云原生环境中处于不同层次上的集群、主机、容器、进程及文件都定义为资产，并提出以下两个观点：

发现更多未知资产等同于提高信息收集的“广度”；挖掘已知资产的属性等同于提高信息收集的“深度”。
上层资产的属性 = 下层资产 + 上层资产自身的元数据。

在以上两个观点的基础上，我们可以制作出面向资产的信息收集结构树：

这棵树是我们在面对云原生集群目标时制定信息收集策略的好帮手，其中：

发现、访问同层次结点增加了信息广度；自顶向下（上图中从左向右）访问结点增加了信息深度。
网络信息主要由拓扑信息（如隔离策略、子网划分等）和实体信息（如提供网络服务的进程等）两部分组成；前者归属于集群、节点或 Pod 元数据，后者归属于进程元数据。

通过建立广度和深度的概念，我们总结出云原生环境中的资产关系，并绘制出信息收集结构树。这确实能够帮助我们把握信息收集的方向，但依然有些抽象，不能有效指导具体收集工作。接下来，我们将把这棵树具体化——结合实例来分享如何层次化收集云原生环境的信息。

2. 信息收集的软件栈层次

将上一节的信息收集结构树展开，可以获得下面这样的信息收集矩阵：

其中，集群处于最高层次，覆盖的信息采集点最多；容器是最低层次，覆盖自身元数据和进程、文件的元数据。进程和文件作为叶子结点资产，不可再分，没有独立划出来。与 ATT&CK 矩阵类似，上图列出了常用的信息采集点，但信息收集矩阵本身在不同的软件栈层次上都是持续增长的。随着软件的更迭和技术的发展，失去价值的信息采集点可能会弃用，新的信息采集点可能会出现。

前面提到，没有上帝视角的攻击者能够收集到的信息注定是有限的。因此，我们必须充分利用收集到的信息，为目标集群画像，在黑盒状态下建立威胁模型，并尽可能不断完善这个模型。有的朋友可能会问：又是树，又是矩阵，到底有什么用呢？我们将在第三篇文章中详细讲述收集到的云原生环境信息的利用价值。在此之前，大家可以通过下面这幅测试环境下的实践图先睹为快：

上图是我们对目标云原生环境应用信息收集矩阵的部分输出结果。可以看到，我们能够利用信息收集矩阵获取相当多的有价值信息，为后续的渗透测试指出方向。这些信息均采用本系列第一篇文章[2]中介绍的方法收集。下面，我们以检测命名空间共享情况为例来讲解具体的收集过程。

Linux Namespaces 机制是构成容器的技术基石，包括不同类型的命名空间，实现对不同类型资源的隔离。判断容器是否与宿主机共享命名空间的关键是找到在攻击者信息收集能力范围内的共享与不共享两种情况之间的差异点。接下来，我们将介绍 PID、Network 命名空间的判断方法。

对于 PID namespace 来说，一种简单但不太精确的方法是观察/proc 目录下的进程数。通常来说，宿主机上的进程要大大多于普通容器内的进程，进程执行的命令行（/proc/[PID]/cmdline）也种类各异。根据这些情况，人类也许很容易给出倾向性的判定，但却很难由机器自动化。我们的方法是读取/proc/sys/kernel/cad_pid 的值，1 表明是宿主机的 PID 命名空间，0 则代表容器的独立 PID 命名空间：

rambo@t-matrix:~# docker run --rm -it ubuntu cat /proc/sys/kernel/cad_pid0

rambo@t-matrix:~# docker run --rm -it --pid=host ubuntu cat /proc/sys/kernel/cad_pid1

根据内核文档[3]，这个文件的值表示系统重启时接收 Ctrl-Alt-Delete 信号的进程的 PID。可以发现，在宿主机上该值为 1，在容器内该值为 0。

对于 Network namespace 来说，可以通过检查容器的/etc/hosts 文件是否有容器内部 IP 来判断。如下面的命令行操作所示，在共享宿主机 Network namespace 的情况下，容器内的/etc/hosts 中没有 172.17.0.2 的内部 IP：

rambo@t-matrix:~# docker run --rm -it --net=host centos:latest cat /etc/hosts127.0.0.1 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

# The following lines are desirable for IPv6 capable hosts

::1 localhost ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

ff02::3 ip6-allhosts