eBPF 容器逃逸检测与运行时审计 EDR

仅检测与审计。非强制执行传感器。 没有任何 BPF 程序返回 -EPERM；没有任何系统调用被阻断。此代理是运行时观测平面，而非防御平面。参见 docs/SECURITY.md 和 THREAT_MODEL.md。

eBPF EDR Demo

一个超轻量级、仅审计的 Linux EDR 代理，使用 eBPF (C) 和高效率的 Go 守护进程构建。它面向 Linux 内核 5.15 LTS 及以上版本，具有零分配热路径、低于 30MB 的内存占用以及深度容器/K8s 上下文增强能力。

✨ 为什么选择此框架？

🎯 金丝雀文件（零误报）： 在内核中植入不可见路径。如果攻击者触碰它们（例如 K8s 服务账户令牌），会立即触发 CRITICAL 告警。
☁️ K8s 上下文增强： 异步轮询 Kubelet API，将 cgroup_id 映射到 Pod 名称、命名空间和 ServiceAccount，而不会膨胀 208 字节的内核传输格式。
🐧 兼容 5.15 LTS： 对 Ubuntu 22.04 和 Debian 12 提供结构性支持，已在内核 6.12 上测试并验证。
⚡ 高性能： 在 25,000 次 fork 压力测试下，空闲 CPU 占用 0.40%，ringbuf 丢弃 0 次。

状态： 阶段 2.7 已完成。覆盖 16 个动作的 13 项 MITRE ATT&CK 技术。已在内核 6.12.111 上完成端到端验证（82 通过 / 0 失败）。

覆盖范围

#	动作	严重级别	MITRE	钩子
1	Container_Namespace_Unshare	HIGH	T1611	kprobe/__x64_sys_unshare
2	Container_Pivot_Root_Escape	CRITICAL	T1611	kprobe/__x64_sys_pivot_root
3	Sensitive_File_Access	HIGH	T1003.008	tracepoint/sys_enter_openat + open
4	Process_Execution	INFO/MEDIUM	T1059.004	tracepoint/sys_enter_execve
5	Network_Connection	INFO/HIGH	T1071	tracepoint/sys_enter_connect
6	Process_Injection	HIGH	T1055.008	tracepoint/sys_enter_ptrace
7	Log_Tampering	HIGH	T1562.001	tracepoint/sys_enter_unlinkat
8	Ebpf_Tampering	HIGH	T1562.001	tracepoint/sys_enter_bpf
9	Perf_Event_Open	MEDIUM	T1562.001	tracepoint/sys_enter_perf_event_open
10	Suspicious_Mount	HIGH	T1611	tracepoint/sys_enter_mount
11	Namespace_Switch	HIGH	T1611	tracepoint/sys_enter_setns
12	Chroot_Escape	HIGH	T1611	tracepoint/sys_enter_chroot
13	Executable_Memory	MEDIUM	T1620	tracepoint/sys_enter_mprotect
14	Core_Pattern_Modification	CRITICAL	T1611	tracepoint/sys_enter_openat + open
15	Cgroup_Release_Agent	CRITICAL	T1611	tracepoint/sys_enter_openat + open
16	Canary_Triggered	CRITICAL	T1552.001	tracepoint/sys_enter_openat + open

动作 9 和 13 已挂载，但默认通过 config.toml 中的 disabled_actions 在内核侧被抑制。

架构

内核钩子（14 个）依次经过 comm/cgroup 过滤器、canary_paths O(1) 哈希查找，然后进行 action_enabled 查找。事件被推送到一个 1 MiB 的 ringbuf，携带 208 字节记录。用户态读入固定的池化缓冲区，应用按动作的令牌桶，使用进程血缘和 cgroup 路径，以及来自有界 LRU 缓存的 K8s Pod 元数据进行增强，并通过 Encoder + Sink 路由到任意目的地。

完整详情：docs/ARCHITECTURE.md。

SIEM 集成

ebpf edr 通过格式 + 传输层将告警导出到任意 SIEM。

[output]
format = "ecs"        # json | ecs | ocsf | cef | leef
target = "webhook"    # file | stdout | syslog | webhook

[output.webhook]
url         = "https://splunk.internal:8088/services/collector/event"
auth_header = "Splunk ${SPLUNK_HEC_TOKEN}"
splunk_hec  = true

支持的传输方式：file、stdout、syslog（UDP/TCP/TLS）、HTTPS webhook。支持的格式：原生 JSON、ECS 8.11、OCSF 1.3.0、CEF、LEEF 2.0。

适用于 Splunk、Elastic、Sentinel、QRadar 和通用 syslog 的配置方案： docs/SIEM_INTEGRATION.md。

缺少 [output] 时，行为与 v1.x 逐字节一致。

要求

Linux 内核 >= 5.15 LTS，且启用 CONFIG_DEBUG_INFO_BTF=y（/sys/kernel/btf/vmlinux）
已在 Debian 13（内核 6.12）上测试。完整兼容性矩阵见 docs/KERNEL_COMPATIBILITY.md。
clang、gcc、Go >= 1.21、bpftool、libbpf 头文件
具有 CAP_BPF CAP_PERFMON CAP_SYS_ADMIN 权限的 root

构建

make kernel        # kernel/bpf_program.o
make userspace     # userspace/ebpf_controller
make emulation     # emulation/adversary

验证（15 个核心阶段 + 2 个 SIEM 阶段）

sudo -E make verify

运行环境探测、构建、C/Go 结构体布局断言、BPF 验证器试运行、运行时冒烟测试、对抗模拟、性能、配置矩阵、 SIGHUP 重载、空闲 CPU、血缘增强、缓存边界、新钩子、格式矩阵和 webhook 投递。

安装（systemd）

sudo ./install.sh --dry-run
sudo ./install.sh
sudo ./install.sh --uninstall

安装 /usr/local/sbin/ebpf-edr、 /usr/local/lib/ebpf-edr/bpf_program.o、 /etc/ebpf-edr/config.toml（保留现有文件；新默认配置位于 .new）、 /etc/systemd/system/ebpf-edr.service、 /etc/logrotate.d/ebpf-edr。

配置

TOML 配置文件位于 /etc/ebpf-edr/config.toml。优先级：CLI > 环境变量（EDR_*）> 文件 > 默认值。

mode = "audit"

disabled_actions = [
    "Perf_Event_Open",
    "Executable_Memory",
]

[log]
path        = "/var/log/ebpf_edr.json"
max_bytes   = 52428800
max_backups = 5
level       = "info"

[filter]
comm_allowlist   = []
cgroup_allowlist = []
canary_paths     = ["/var/run/secrets/kubernetes.io/serviceaccount/token"]

[k8s]
enrichment = true

[rates]
events_per_sec = 200
burst          = 400

[container]
cache_max_entries = 5000

[context]
lineage_max_depth  = 16
lineage_cache_size = 20000
cgroup_cache_size  = 5000

重载：sudo systemctl reload ebpf-edr。mode = "enforce" 会被拒绝；此构建仅支持审计模式。

事件模式（v3，线上传输 208 字节）

{
  "timestamp": "2026-10-15T23:52:41Z",
  "pid": 1370, "ppid": 1369, "uid": 0,
  "start_time_ns": 180763002635,
  "command": "unix_chkpwd",
  "action": "Sensitive_File_Access",
  "target": "/etc/shadow",
  "severity": "HIGH",
  "mitre_id": "T1003.008",
  "mitre_technique": "OS Credential Dumping: /etc/shadow",
  "cgroup_id": 3874,
  "cgroup_path": "/user.slice/user-0.slice/session-3.scope",
  "runtime": "host",
  "lineage_summary": "systemd > sshd > bash > sudo > unix_chkpwd",
  "lineage": [
    {"pid": 1370, "ppid": 1369, "comm": "unix_chkpwd",
     "exe": "/usr/sbin/unix_chkpwd", "start_time_ns": 180763002635},
    {"pid": 1369, "ppid": 1368, "comm": "sudo",
     "exe": "/usr/bin/sudo", "start_time_ns": 180762998100}
  ]
}

字段 aux_u16、aux_u32、aux_u64 携带动作特定的上下文。

操作

每 60 秒输出一次健康状态行：

[health] recv=N written=N dropped=N rate_limited=N parse_err=N
         ver_mismatch=N ringbuf_err=N reloads=N reload_fail=N
         chan=N/4096 lineage_cache=N/20000 lineage_hits=N
         lineage_misses=N cgroup_cache=N/5000
         sink_sent=N sink_failed=N sink_dropped=N sink_retries=N
         sink_queue=N sink_circuit=bool

目标值：dropped = 0，ver_mismatch = 0，lineage_cache 低于容量。

开发

目标	用途
`make kernel`	构建 BPF 对象
`make userspace`	构建守护进程
`make emulation`	构建对抗性测试框架
`make test`	Go 单元测试
`make test-race`	带竞态检测器的 Go 测试
`make fuzz`	每个目标 60 秒模糊测试
`make verify`	15 阶段核心验证 + 2 阶段 SIEM 验证
`make verify-siem`	仅 2 阶段 SIEM 验证
`make ci`	本地 CI：gofmt、vet、race、fuzz、verify
`make install` / `uninstall`	系统安装 / 卸载
`make test-attacks`	模拟覆盖断言
`make clean`	删除构建产物

文档

docs/ARCHITECTURE.md - 数据流、内核程序、缓存、版本管理。
docs/OPERATIONS.md - 安装、配置、重载、故障排查。
docs/MITRE_MATRIX.md - 完整技术映射及钩子名称。
docs/SECURITY.md - 威胁模型、能力、沙箱、故障模式。
docs/SIEM_INTEGRATION.md - Splunk、Elastic、Sentinel、QRadar 集成方案。
docs/KERNEL_COMPATIBILITY.md - 内核最低版本（5.15 LTS）、功能矩阵及 vmlinux.h 固定策略。
SECURITY.md - 漏洞披露政策及支持版本。
CONTRIBUTING.md - 贡献流程及本地 CI 门禁。
CODE_OF_CONDUCT.md - 社区准则。
THREAT_MODEL.md - 威胁模型及安全假设。

验证证据

最近一次完整运行（内核 6.12.111+deb13-amd64）：82 通过，1 警告，0 失败 覆盖 15+2 个阶段。唯一的警告是合成性能工作负载的 CPU 读数，空闲 CPU 已单独验证为 0.40%。

Kubernetes 与 Docker（阶段 2.7）

该框架设计为以 Kubernetes DaemonSet 运行，以提供集群范围的 EDR 覆盖。

ebpf-container-escape-framework

最受欢迎