【Falco】运行时检测全景：缺口、五轴坐标系与 16 篇路线

Tetragon / eBPF 运行时安全 已把内核选择器、Override 与 JSON≠gRPC 导出钉到可排障精度；选型收束 排除树把「Falco 规则库已够且不要 Override」标为独立路径。可观测性 · 网络观测 与 linux/ebpf-security 给过产品级对照。中间仍缺一层：一次检测事件如何经 modern_ebpf 或 kmod、libscap 协商、libsinsp 富化与规则引擎变成告警，双引擎失败如何分列，以及相对 Tetragon / auditd / seccomp 何时不该上 Falco。

本文只做三件事：钉缺口、定义后续 15 篇共用的五条坐标系，并给出阅读路线。难点不在「会不会 Helm 装 Falco」，而在驱动与用户态交界上的可核对字段——Driver 行是否与预期引擎一致、API/Schema 是否协商成功、规则条件字段是否被富化、丢事件是否被当成「无威胁」。

本篇在系列中的位置

篇目	核心内容
第 1 篇 · 运行时检测全景	缺口、五轴坐标系、16 篇路线
第 2 篇 · 双引擎对照	modern_ebpf ∥ kmod、legacy eBPF 已删
系列目录	关键问题、阅读路径、全部价值点

版本锚定：Falco 0.44.1（源码 tag 0.44.1，发布 2026-06-11）。驱动钉 10.2.0+driver（随 0.44）。机制叙述对齐该 tag 与配套 falcosecurity/libs；官方 Kernel Events / Kernel Events Architecture 以与 0.44 文档树一致的内容为准。falco.org/docs/ live 站点是滚动文档，不以 /latest 冒充本版本。无真实 Falco 节点则不粘贴伪造 falco --version Driver 行 / 规则命中日志 / drop 计数。 0.44.0 已删除 legacy eBPF（engine.ebpf）、gVisor engine、gRPC output/server——不得写成当前能力。

一、相对站内已有内容，缺口在哪

下表列出各已有系列的视角，以及本系列补的格子。规则是：不重写已有内容，只填真正空着的格子。

结论：读者知道「Falco 用 eBPF 或内核模块做运行时检测」、会改 driver.kind，但不知道一次事件卡在驱动加载、scap 协商、sinsp 富化、规则条件还是 sink；为何 0.43 用户态配 0.44 驱动会失败；auto 回退是否可观测；旧清单里的 legacy ebpf 在 0.44 已删却仍被抄进 runbook。本系列补「Falco 运行时检测内核」那一格。

与通识教程的差别也在这里：多数「在 K8s 上装 Falco」文章停在一条敏感文件规则与 Helm values；本系列追问 进程起来之后「无告警 / 无事件 / 有命中无下游」仍落在哪一层，以及 错引擎、协商失败、富化字段空、规则异常过宽、丢事件各自如何表现。深度来自可证伪的阶段划分，而不是更长的规则清单。

本系列刻意不写 Helm values 百科、MITRE ATT&CK 规则库逐条映射、verifier 形式化全书、完整 SIEM 菜谱、未实测「比 Tetragon 少百分之几 CPU」排行榜。站内 linux/ebpf-security 对照表里的资源占用数字本系列不引用——那些数字未经本仓库实测，也不能从 0.44.1 官方文档核出。官方已经钉死、本系列会反复回指的机制差包括：modern_ebpf 与 kmod 是两条等级路径；libscap 启动时必须协商 API Version 与 Schema Version；legacy eBPF / gVisor / gRPC output 在 0.44 已删。若目标只是「把 DaemonSet 跑起来」，官方 Quickstart 与 observability/15 已够；若目标是「失败落在哪一层驱动 / 哪一次协商 / 哪条规则条件」，则必须沿五轴下钻。

本系列反复回指的版本门（不当本篇深挖）

官方 0.44.0 / 0.44.1 Release Notes 与 Changelog 把若干行为钉成升级破坏面。后面各篇会拆机制，本篇只登记为坐标系上的门：

二、五条坐标系（后续章节回指）

后面每一篇都落到下面某一条轴上。本篇钉名字、关键锚点与失败表象；具体生命周期与源码停顿点在对应篇展开。排障口诀：先点名轴，再下钻模块——不要一上来改规则 YAML 或重装 DaemonSet。双引擎在轴 1–2、部分轴 5 分列证据包；轴 3–4 共享用户态语义。

官方 Kernel Events Architecture 把跨内核边界的捕获收口到 libscap，把富化与规则求值收到 libsinsp（libs 仓库分工：libscap 读驱动；libsinsp 维护机器状态并做过滤/输出）。五轴是把这条管线按值班可核对的失败落格切开，而不是另造一套架构名词。

flowchart LR
  syscall["syscalls and related"] --> kmod["kmod driver"]
  syscall --> mebpf["modern_ebpf probe"]
  kmod --> scap["libscap capture"]
  mebpf --> scap
  scap -->|"API and Schema negotiate"| sinsp["libsinsp enrich and filter"]
  sinsp --> rules["rule engine"]
  rules --> out["outputs and plugins"]
  out --> siem["stdout file http plugin sinks"]

图：一次检测事件沿五轴从 syscall 走到 sink。节点为英文，避免窄框折行；正文用中文解释每条轴。modern_ebpf 与 kmod 在进入 libscap 之前分列。

Driver 加载轴

定义：Falco 用哪一种内核态仪表采集 syscall 上下文，以及该仪表如何被装上、需要什么权限、失败时用户态看到什么。

官方 Kernel Events（文档树已随 0.44 去掉 legacy eBPF）只保留两条驱动：Modern eBPF probe（默认路径之一）与 Kernel module。modern_ebpf 嵌入用户态 binary，依赖 BTF 与 BPF ring buffer 等特性，可走 least-privileged 能力集；kmod 需单独部署 .ko，文档写明不能用 Linux capabilities 做 least-privileged，需要完整特权。driver.kind=auto（falcoctl / Helm）先试 modern_ebpf 再回退 kmod——这是运维选择器，不是第三条内核路径。

「DaemonSet Ready 但 Driver 行不是你以为的引擎」或「modern_ebpf 注入失败却被 auto 静默换成 kmod」优先落本轴，而不是先改规则条件。展开见 第 2 篇、第 10 篇。

libscap / 协商轴

定义：用户态如何与已加载驱动建立会话，以及 API Version（通信机制）与 Schema Version（事件类型集合）如何对齐。

Kernel Events Architecture 写明：kmod 需单独安装，modern_ebpf 可由 libscap 直接安装；连接时 libscap 必须协商驱动识别的 API Version 与 Schema Version。通信机制因驱动而异（kmod 侧常见 ioctl + ring；modern_ebpf 侧用 maps 等，并随内核版本变化）。0.44 相对 0.43 的驱动 API/Schema 大 bump 使错配成为经典事故：表象常是启动失败或「没有任何 syscall 事件」，容易被误判成规则写错。

「升级了 chart 却忘了换 driver」优先落本轴。展开见 第 3 篇、第 12 篇。无环境则不粘贴伪造 falco --version 输出；语义上该命令用于核对 Libs / Driver API / Schema / Default driver 行。

libsinsp 状态轴

定义：原始 scap 事件如何被富化成规则可引用的字段（路径、网络元组、进程树、容器元数据），以及富化失败时条件为何「永远假」。

libs 把机器状态与规则求值放在 libsinsp。相对 Tetragon 第 2 篇 的内核 execve_map + exec_id，Falco 主路径仍是用户态状态表重建上下文——消除了「每次告警再扫一遍无结构日志」的痛苦，不消除 Garfinkel（NDSS 2003）指出的用户态检查窗口类问题。container / k8smeta 等 plugin 把额外字段并入同一求值面；元数据空时，带 container.* 的条件会静默不命中。

「规则在测试机命中、在集群不命中」优先查本轴的富化与 plugin，而不是先认定规则文件没加载。展开见 第 4 篇、第 9 篇。

规则引擎轴

定义：已富化事件如何经条件、优先级、异常变成一次告警（或被异常吞掉）。

规则语言与引擎在用户态（libsinsp 内）。本系列写求值与加载失败模式，不写默认规则集百科。加载路径（本地文件、falcoctl 远程）见第 7 篇；与 Tetragon 内核 selector 的对照见第 14 篇。

「规则 YAML 已 mount、falco -L 能看见、生产无告警」优先区分：条件字段空（轴 3）、异常过宽（本轴）、还是根本没有原始事件（轴 1–2）。展开见第 6–7、13 篇。

输出与丢事件轴

定义：告警离开引擎后去哪，以及驱动/用户态缓冲丢掉的事件如何与「规则未命中」区分。

0.44.1 仍支持的 sink 以官方输出配置为准（stdout/file/http 等）；gRPC output 已删，旧 runbook 若仍接 gRPC 会在升级后门失败。丢事件发生在驱动缓冲或用户态消费跟不上时；0.44 引入 BPF iterators 辅助 drop recovery，0.44.1 允许在容器场景关闭 iterators。命中了但下游无，与从来没有 scap 事件，证据包不同。

「SIEM 安静、节点 CPU 却很高」或「drop 计数在涨却无人当事故」优先落本轴。展开见第 5、8、11、13 篇。

三、坐标系背后的三个不变量

相对「只在 CNI 上做 NetworkPolicy」与「Tetragon 内核 selector + Override」，Falco 检测路径同时钉住三条不变量：

1. 采集发生在驱动，判定发生在用户态：modern_ebpf 与 kmod 只保证把 syscall 上下文送出内核；规则命中与否在 libsinsp。代价是必须分清「无原始事件」与「有事件无告警」。
2. 双引擎是等级路径，不是默认与弃子：权限模型、部署形态、协商与丢事件恢复可以分叉；auto 回退若不可见，排障会指错引擎。代价是证据包必须按 Driver 行分列。
3. 富化与输出是独立失败域：规则条件引用的字段可能从未被填上；sink 背压或已删除的 gRPC 输出会让「引擎已命中」在下游消失。代价是不能把 SIEM 空窗直接写成「没有攻击」。

排障时先问「哪条不变量被触碰」，再落到对应轴。例如：Driver 行是 kmod 但你按 modern_ebpf 能力集排权限 → 不变量 2；条件里 fd.name 为空 → 不变量 3；falco -L 有规则但 scap 会话未打开 → 不变量 1。

这三条不变量也解释了系列边界：本系列不重写 verifier 证明义务（外链 ebpf/），也不写 TracingPolicy Override（外链 tetragon/）。我们只在 Falco 检测内核里追问：给定这三条约束，0.44.1 如何实现、何处失败、与系统调用拦截的经典假设差在哪。

四、设计谱系：过滤虚拟机 → 系统调用拦截 → 用户态规则引擎

McCanne & Jacobson, USENIX Winter 1993（经典 BPF：内核过滤虚拟机）
  → 扩展 BPF（通用内核可编程；站内 ebpf/ 展开 verifier/JIT）
  → Garfinkel, NDSS 2003（系统调用拦截的陷阱：TOCTOU、/proc 窗口、覆盖不全）
  → audit / sysdig scap 谱系 → Falco（驱动采集 + 用户态规则）
  → 仍争：内核过滤完整性 vs 用户态规则可移植性；modern_ebpf 便利 vs kmod 可达性

1. 经典 BPF（McCanne & Jacobson, USENIX Winter 1993）定义「在内核里用受限虚拟机过滤」的范式；今天的 eBPF 是能力与安全模型都大幅扩展后的后代，细节见 ebpf/。
2. 系统调用拦截的陷阱（Garfinkel, NDSS 2003）列出 TOCTOU、通过 /proc 重建状态的竞态、以及「以为检查了入口其实参数已变」。Falco 用驱动把事件送出内核，在用户态求值——缩短了「无结构审计」的痛苦，不自动获得 Tetragon 式 inline Override。
3. 生产分叉（0.44.1）：仅 modern_ebpf ∥ kmod；libscap 协商 API/Schema；libsinsp 富化后规则引擎告警；plugin 扩展事件源；gRPC output 退出舞台。

工业反例 CVE-2022-26316（GHSA-6v9j-2vm2-ghf7，影响低于 0.31.1 的检查窗口）放在第 14 篇对照：它验证 Garfinkel 的 argument race，不是「必须弃用 Falco」的充分条件，也不是本篇展开完整漏洞史。

五、开放争论（先立靶，后各章拆）

不在第 1 篇宣布胜负；每组争论要求后续篇给出可核对机制或选型边界，而不是「看业务场景」空话。

对「内核路径 vs 用户态规则」额外钉一句：本系列不比较未实测的 CPU 排行榜，只比较失败模式是否可归因到五轴中的某一层。若安全产品把采集与判定藏在黑盒里，工程师就失去了 Driver 行 / API·Schema / 规则条件 / drop 计数这类抓手——这是架构选择，不是性能排名。

六、16 篇路线与阅读建议

flowchart TD
  overview["01 Overview"] --> dual["02 Dual Engines"]
  dual --> scap["03 libscap"]
  scap --> sinsp["04 libsinsp"]
  sinsp --> drop["05 Drops Buffers"]
  drop --> rules["06 Rule Language"]
  rules --> load["07 falcoctl Load"]
  load --> out["08 Outputs"]
  out --> plug["09 Plugins"]
  plug --> deploy["10 driver.kind"]
  deploy --> tax["11 Overhead"]
  tax --> ops["12 Upgrade"]
  ops --> trouble["13 Troubleshoot"]
  trouble --> vs["14 vs Alternatives"]
  vs --> eco["15 Response Ecosystem"]
  eco --> select["16 Selection"]
  overview --> select

读法：先读本篇建立缺口与五轴；若你的症状是「装了没事件」，优先 02→03→13；若是「有事件无告警」，优先 04→06→07→13；若是「命中了下游没有」，优先 05→08→13。选型决策读 14→16，不要跳过排除树直接比较品牌口号。

强制执行与 TracingPolicy 见 Tetragon；eBPF VM 见 ebpf/；产品勾选见 observability/15 与 linux/ebpf-security。

七、本篇不写什么

• Helm values 逐项百科、各云厂商一键市场截图。
• 默认规则集 / MITRE 映射全书。
• verifier / JIT / CO-RE 形式化（外链 ebpf/）。
• Tetragon Override / Runtime Hooks 重讲（外链 tetragon/）。
• 未实测跨方案 CPU% / 内存排行；照抄 linux/ebpf-security 数字。
• 把 live 文档后版本能力写成 0.44.1；把 legacy eBPF / gVisor / gRPC output 写成当前选项。
• 伪造 Driver 行、规则命中样本、drop 曲线。

参考资料

规范 / 官方文档 / 源码（A）

• Falco 0.44.1 / 0.44.0 Release Notes 与 Changelog（legacy eBPF / gVisor / gRPC output 删除；drivers 10.2.0+driver；0.44.1 BPF iterators 可禁用）
• Falco Kernel Events；Kernel Events Architecture（libscap 协商 API/Schema；kmod vs modern_ebpf 安装差）
• falcosecurity/libs：libscap / libsinsp / driver/（modern_bpf 与 kmod）分工说明
• 本系列 PLAN.md §一、§七、§八

站内对照（A/B）

• Tetragon 16 · 选型收束（Falco 叶）
• Tetragon 14 · 对照替代路径
• observability/15；linux/ebpf-security
• ebpf/

学术谱系（A）

• McCanne & Jacobson, The BSD Packet Filter, USENIX Winter 1993
• Garfinkel, Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools, NDSS 2003

工业反例（B，展开在第 14 篇）

• GitHub Advisory GHSA-6v9j-2vm2-ghf7 / CVE-2022-26316（Falco < 0.31.1 检查窗口）

上一篇：系列目录

下一篇：双引擎对照