引言：为什么容器安全需要 eBPF
容器技术（Docker、containerd、Kubernetes）已经成为现代云原生基础设施的基石。然而，容器共享宿主机内核的架构特性，使得传统基于边界的安全模型面临严峻挑战。一旦容器内的进程突破 namespace 隔离（如容器逃逸漏洞 CVE-2019-5736），攻击者便能直接访问宿主机资源甚至横向移动至集群其他节点。
eBPF（extended Berkeley Packet Filter）作为 Linux 内核的一项革命性技术，允许在内核空间安全地运行沙箱化程序，无需修改内核源码或加载内核模块。这为容器安全监控带来了低开销、高可编程、内核级可见性的解决方案。
一、容器安全威胁模型
在深入技术实现前，我们需要明确容器环境面临的六大威胁维度：
1. 容器逃逸（Container Escape）
通过内核漏洞（如 Dirty COW、Dirty Pipe）、特权容器（privileged: true）、敏感挂载（/var/run/docker.sock）等方式突破 namespace 隔离。典型路径：容器内进程 → 内核漏洞利用 → 宿主机 namespace。
2. 横向移动（Lateral Movement）
攻击者攻陷一个容器后，利用集群内网络策略（NetworkPolicy）配置不当、Service Account token 泄露、etcd 未授权访问等方式，在 Kubernetes 集群内部横向扩散。
3. 供应链攻击（Supply Chain Attack）
恶意镜像（typosquatting）、被污染的 Dockerfile（base image 篡改）、CI/CD 管道注入等方式将恶意载荷引入生产环境。
4. 资源耗尽（Resource Exhaustion）
通过 fork bomb、内存压力、CPU 饥饿等方式实施拒绝服务攻击。缺乏 cgroup 限制的容器可能拖垮整个节点。
5. 敏感数据泄露（Data Exfiltration）
通过未加密的容器间通信、环境变量中的硬编码凭证、容器层文件系统中的残留密钥等方式窃取敏感信息。
6. 持久化与后门（Persistence）
通过修改 crontab、注入 LD_PRELOAD、写入 /proc/self/mem 等方式在容器内建立持久化机制。
二、eBPF 核心技术栈
2.1 eBPF 程序类型与安全监控覆盖
| eBPF 程序类型 | Hook 点 | 安全监控场景 |
|---|---|---|
| Kprobe/Kretprobe | 内核函数入口/出口 | 监控 execve、ptrace、mount 等敏感系统调用 |
| Tracepoint | 内核预定义事件点 | 稳定接口，跟踪进程创建、文件操作、网络事件 |
| XDP | 网卡驱动层 | DDoS 防护、网络层访问控制、包过滤 |
| Socket Filter | 套接字层 | 网络流量审计、端口扫描检测 |
| Cgroup Device | cgroup 设备控制 | 容器设备访问控制 |
| LSM Hook | Linux 安全模块 | 细粒度 MAC 策略执行（AppArmor/SELinux 替代） |
2.2 关键数据结构与 Map 类型
eBPF 程序通过 Map（键值存储）与用户空间通信，常用的 Map 类型包括：
- Hash Map：存储进程上下文、容器元数据、威胁指纹
- Ring Buffer：高性能事件流传输（替代 perf buffer，内核 5.8 ）
- LRU Map：缓存活跃连接、高频访问文件路径
- Per-CPU Map：多核无锁聚合统计（避免 CPU 间的缓存竞争）
2.3 BPF CO-RE（Compile Once, Run Everywhere）
BPF CO-RE 解决了 eBPF 程序跨内核版本兼容性问题。通过 BTF（BPF Type Format）提供的类型信息和 libbpf 的 relocations 机制，eBPF 程序编译一次即可在多个内核版本上运行，无需在内核机器上现场编译。
三、威胁检测三维度实现
3.1 进程行为监控层
通过 hook sched_process_exec 和 sched_process_fork tracepoint，实时捕获容器内所有进程创建事件。检测规则包括：
- 异常二进制执行（如 /bin/sh 在非交互容器中启动）
- 权限提升行为（setuid/setgid 调用、cap_capable 检查）
- 调试器附加（ptrace 系统调用，防反调试与防注入）
- 核心转储生成（可能泄露敏感内存数据）
3.2 文件系统审计层
通过 kprobe/vfs_read、kprobe/vfs_write、kprobe/vfs_unlink 监控文件系统操作：
- 敏感文件读取（/etc/shadow、/etc/kubernetes/pki/）
- 二进制目录写入（/bin、/usr/bin 的异常修改）
- 隐藏文件创建（以 . 开头的 ELF 文件）
- 符号链接攻击检测（symlink race condition）
3.3 网络流量分析层
结合 XDP 和 Socket-level eBPF 程序实现网络安全监控：
- 异常外联检测（容器不应直接访问公网 IP）
- 端口扫描行为识别（多个目标端口的 SYN 尝试）
- DNS 隧道检测（DNS 查询长度异常、频率异常）
- 明文凭证传输（未加密通道中的 Authorization header）
四、Falco 规则引擎实战
Falco 是 CNCF 孵化的开源运行时安全工具，使用 eBPF 作为默认的事件采集后端。其规则采用 YAML 声明式语法，支持丰富的条件表达式。
规则示例 1：检测容器内 shell 执行
- rule: Shell Spawned in Container
desc: Detect shell process (bash, sh, zsh) spawned inside a container
condition: container and proc.name in (bash, sh, zsh, ash, dash, csh, tcsh)
output: "Shell spawned in container (user=%user.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline container_id=%container.id image=%container.image.repository)"
priority: WARNING
tags: [container, shell, mitre_execution]
规则示例 2：检测容器逃逸尝试
- rule: Container Escape via Mount
desc: Detect mount/umount operations that could indicate container escape attempts
condition: container and evt.type in (mount, umount) and proc.args contains "/proc" or proc.args contains "/sys"
output: "Potential container escape via mount (proc=%proc.name args=%proc.args user=%user.name)"
priority: CRITICAL
tags: [container, escape, mitre_privilege_escalation]
规则示例 3：检测异常外联行为
- rule: Outbound Connection from Container
desc: Detect outbound network connections from containers that should be isolated
condition: container and evt.type in (connect, accept) and fd.typechar="4" and not fd.ip in (trusted_subnets)
output: "Unexpected outbound connection from container (connection=
发表评论 取消回复