大家好！我是大聪明-PLUS，我们正在继续探索如何利用真实案例攻击来发现和利用容器化环境中的漏洞。

容器网络接口 (CNI) 配置错误可能导致跨容器攻击，例如通过 ARP 欺骗

CNI 配置错误会使容器网络容易受到跨容器攻击，包括 ARP 欺骗等技术。ARP 欺骗允许攻击者伪造 ARP 响应，将容器之间的流量重定向到自己的容器，从而拦截或篡改数据。这种漏洞在微服务架构中尤其危险，因为容器之间通过网络通信并处理敏感数据。

容器网络中的ARP欺骗工作原理

ARP（地址解析协议）用于在本地网络中将 IP 地址解析为 MAC 地址。当一个容器想要向同一网络上的另一个容器发送数据时，它会发送一个 ARP 请求来获取接收方的 MAC 地址。在 ARP 欺骗攻击中，攻击者会使用伪造的 MAC 地址来响应该请求，从而将受害者的流量重定向到自己的容器。

如果配置错误，CNI 可能缺少 ARP 限制，攻击者可以成功伪造 ARP 响应并执行中间人(MITM) 攻击来拦截、修改和重定向流量。

CNI漏洞和配置问题导致ARP欺骗

• 网络隔离不足：如果没有适当的网络策略，同一命名空间或子网内容器之间的流量将不受限制。因此，攻击者可以轻易发送 ARP 应答，将流量从一个容器重定向到另一个容器。

• 网络安全功能已禁用： Calico 和 Cilium 等 CNI 插件允许您配置网络策略以限制流量。如果这些策略被禁用或配置错误，容器可以自由交换 L2 流量，从而为攻击（包括 ARP 欺骗）创造机会。

• 缺乏 ARP 级身份验证：某些容器网络缺乏验证 ARP 消息的机制，这使得攻击者可以轻易发送伪造的 ARP 响应。

• 共享网络命名空间：在 Kubernetes 和 Docker 中，如果容器共享一个网络命名空间（例如，在 Kubernetes 中使用 `hostNetwork: true`），它们可以直接在主机网络层进行通信。攻击者可以利用这一点向该命名空间中的所有容器发送伪造的 ARP 数据包。

容器网络中的 ARP 欺骗攻击示例

假设我们有两个容器（容器 A 和容器 B）位于同一网络上，它们之间可以通信。攻击者位于容器 C 上，并且也位于该网络上。如果 CNI 配置错误，没有限制 ARP 请求，则攻击者可以按如下方式执行 ARP 欺骗：

— ARP欺骗：容器C中的攻击者向容器A发送伪造的ARP响应，声称容器B的IP地址绑定到容器C的MAC地址。这导致容器A将原本发往容器B的流量转发到容器C。

—流量拦截和修改：现在容器 C 中的攻击者接收到了原本应该发送到容器 B 的流量。他们可以简单地拦截数据进行分析，或者在将其转发到 B 之前对其进行修改，从而执行中间人攻击。

防止容器网络中的 ARP 欺骗攻击

为了保护容器网络免受 ARP 欺骗等攻击，可以使用以下几种方法：

• 配置 Kubernetes 网络策略：配置网络策略以限制容器之间的流量。这可以通过使用网络 CNI 插件（例如 Calico 或 Cilium）来实现，这些插件允许您创建规则，根据 Pod 的标签和命名空间来限制 Pod 之间的网络通信。

• 使用网络级身份验证：一些 CNI 插件，例如 Weave Net，支持流量加密和身份验证机制，以防止 L2 攻击。

• 网络命名空间隔离：尽可能避免使用共享网络命名空间（例如 hostNetwork），以防止容器访问主机系统资源，并限制容器在主机网络级别上的直接通信。

• 使用 ARP 过滤和防止 ARP 欺骗：可以在网络接口级别启用 ARP 过滤（例如，使用主机网络接口内置的工具或通过 CNI 插件级别的设置），以拒绝可疑的 ARP 请求。

• 定期漏洞扫描：扫描并验证 CNI 配置是否存在潜在漏洞和潜在错误配置，这些漏洞和错误配置可能允许攻击者执行跨容器攻击。

容器网络接口 (CNI) 配置错误会严重损害容器网络安全，为 ARP 欺骗等攻击打开方便之门。配置和维护网络策略、实施身份验证检查以及应用安全功能有助于最大限度地降低风险，并确保容器间网络通信的安全。

包含硬编码密钥或以 root 用户身份运行的 Dockerfile：

Dockerfile 编写错误会导致严重的安全问题，尤其是在 Dockerfile 包含硬编码的敏感数据或容器以 root 权限运行时。这些错误使攻击者能够轻松访问敏感信息（例如访问密钥和密码），并可能导致容器乃至宿主机系统遭到入侵。

不安全的 Dockerfile 如何导致数据泄露

• 硬编码密钥和密码：创建 Dockerfile 时，有时会包含 API 密钥、密码和数据库凭据等敏感数据，以便应用程序连接到外部服务。如果这些数据没有加密或混淆，攻击者一旦获得镜像或容器的访问权限，就能轻易提取这些数据。

• 以 root 用户身份运行容器：默认情况下，容器以 root 用户身份运行，除非在 Dockerfile 中另有指定。这很危险，因为容器内的 root 权限赋予攻击者广泛的命令执行权限。如果容器突破隔离，root 访问权限也可能扩散到宿主机系统。

• 未移除临时文件和敏感信息：如果在 Docker 镜像构建过程中添加了敏感文件（例如 .env 文件或 API 密钥），且在使用后未将其移除，则这些文件在最终镜像中仍然可访问。即使容器不再使用这些数据，也很容易恢复它们。

• 权限过高：为运行进程设置特权权限（例如，使用 --privileged 标志）会降低容器的安全性，因为它允许应用程序访问主机的系统资源。

一个不安全的 Dockerfile 示例

我们来看一个包含硬编码密钥并以 root 用户身份运行的错误 Dockerfile 示例：

# 不要这样做

来自 python:3.9

# 硬编码密钥和密码

ENV AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

ENV AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# 安装依赖项

运行 apt-get update && apt-get install -y \

curl \

vim

# 以 root 用户身份运行应用程序

CMD ["python", "app.py"]

此 Dockerfile 存在以下不安全问题：

• 硬编码密钥：AWS 密钥保持公开状态，任何有权访问镜像的人都可以使用。

• 以 root 用户身份运行：如果在 Dockerfile 中未明确指定用户，则 Dockerfile 将以 root 用户身份运行。

• 冗余软件包：安装不必要的工具（例如 vim）会造成额外的攻击面。

如何提高 Dockerfile 的安全性

• 避免硬编码密钥：切勿将敏感数据添加到 Dockerfile 中。而应使用传递密钥的机制，例如：

• 启动时的环境变量：使用 docker run -e 命令在容器启动期间设置包含敏感信息的环境变量。

• Docker Swarm 中的密钥：Docker Swarm 允许您安全地将密钥推送到容器，这些密钥将存储在内存中，不会在镜像中留下任何痕迹。

• 密钥库系统（例如 HashiCorp Vault）：使用专门的系统来管理密钥。

• 不要使用 root 用户：在 Dockerfile 中添加一个单独的用户，以最小权限运行应用程序。

来自 python:3.9

# 创建一个权限最低的用户

运行 useradd -m appuser

用户 appuser

# 安装依赖项

运行 apt-get update && apt-get install -y \

卷曲

CMD ["python", "app.py"]

在这种情况下，即使攻击者获得了对容器的访问权限，他们也无法执行具有 root 权限的命令。

删除临时文件：如果您的配置需要使用敏感文件（例如 .env 文件），请在使用

COPY .env /app/.env 命令删除它们之后再删除它们。

运行 source /app/.env && rm /app/.env

扫描镜像漏洞：部署前，请使用 Snyk、Trivy 或 Docker Bench 等安全扫描工具，确保镜像不存在漏洞和硬编码密钥。

例如，在构建镜像后，在 Jenkins 流水线中使用 Twistlock：

`sh ' tt images pull-and-scan --user "${TWISTLOCKUSER}":"${TWISTLOCKAPI}" --url "${TWISTLOCKAPIADDRESS}" --imagetype prod --iam-api-key ${CLOUDAPI} -g ${TWISTLOCKGROUP} ${SCAN_REGISTRY}/${IMAGE}:${TAG}'`

最小镜像：使用像 Alpine Linux 这样的最小镜像，而不是像 Ubuntu 这样的大型基础镜像，可以降低包含可能被攻击者利用的不必要工具的可能性。

安全 Dockerfile 示例

# 最小基础镜像

来自 python:3.9-alpine

# 创建一个权限最低的用户

运行 adduser -D appuser

用户 appuser

# 安装依赖项并删除临时文件

运行 apk add --no-cache curl

# 启动应用程序

CMD ["python", "app.py"]

此 Dockerfile：

• 不包含硬编码的密钥。

• 以权限受限的用户身份运行。

• 基于极简设计，缩小尺寸并降低潜在缺陷。

Dockerfile 中的错误，例如硬编码密钥和以 root 用户身份运行，可能会危及容器甚至整个主机的安全。遵循最佳实践，例如使用非 root 用户、实施安全的密钥管理以及定期扫描，有助于最大限度地降低这些风险，并确保生产环境中容器的安全。