Falco / 运行时检测：从双引擎驱动到规则引擎
内容提要
本文介绍Falco 0.44.1运行时安全检测系列文章，聚焦用户态规则检测路径与双引擎（modern_ebpf和kmod）捕获机制。内容涵盖libscap/libsinsp协商、规则引擎、输出及丢事件排障，对比Tetragon、auditd和seccomp选型。强调版本锚定、双引擎不可互换性，并提供16篇路线图，帮助平台安全工程师从安装推进到可归因的告警排障。
延伸解读
双引擎不可互换的运维含义
文章明确modern_ebpf与kmod是两条等级路径，auto只是运维回退门而非第三条内核。这意味着在部署时不能简单依赖auto自动选择，而应根据节点内核、权限和签名要求明确指定引擎。若误用auto，可能掩盖引擎差异，导致后续排障困难。升级时0.43到0.44必须成对升级，否则会出现无事件而非规则错误的现象。
丢事件与无告警的排查思路
文章指出，规则已加载但无告警可能源于条件、富化、sink或丢事件，而非规则写错。这提示排查时应按五轴（驱动、libscap、libsinsp、规则、输出）逐层定位。特别是用户态与驱动版本错配常表现为无事件，容易被误判为规则问题。理解丢事件落在哪一层，有助于区分真实无威胁与检测失效。
选型时机的判断依据
文章对比了Falco与Tetragon、auditd、seccomp，强调并非所有场景都适合Falco。当需要内核策略机或强制能力时，Tetragon可能更合适；当仅需主机审计时，auditd更轻量。Falco的用户态规则税（如富化、规则引擎）在需要灵活规则和可归因告警时值得付出，但在简单场景下可能过度。选型应基于具体需求，而非默认使用Falco。
Q&A
Falco 0.44.1 中 modern_ebpf 和 kmod 两种驱动引擎有什么区别？
modern_ebpf 使用嵌入的 eBPF 程序，支持 CO-RE 和最小权限能力集；kmod 是独立的内核模块，需要签名和完整特权。两者不能互换，auto 只是运维回退门，不是第三种引擎。
Falco 检测事件从驱动到告警，丢失可能发生在哪些层？
丢失可能发生在驱动捕获、libscap 协商、libsinsp 富化、规则引擎匹配或输出阶段。排障时需按五轴（驱动、libscap、libsinsp、规则、输出）逐一排查。
为什么 Falco 用户态与驱动版本不匹配时表现为无事件，而不是规则错误？
版本不匹配会导致 libscap 与内核驱动之间的 API/Schema 协商失败，从而无法捕获事件，表现为无事件。这与规则写错无关，需成对升级用户态和驱动。
Falco 规则已加载但无告警，可能的原因有哪些？
可能原因包括：规则条件永远为假、字段依赖缺失、事件在驱动或 libscap 层丢失、libsinsp 富化失败、输出 sink 配置错误等。需按排障五轴逐一排查。
在什么情况下应该选择 Falco 而不是 Tetragon、auditd 或 seccomp？
当需要用户态规则检测、丰富的上下文富化和灵活的输出时，Falco 更合适；若需内核策略强制或最小权限，可考虑 Tetragon 或 seccomp；主机审计需求则用 auditd。具体选型见系列第 14-16 篇。
Falco 0.44.1 相比 0.43 有哪些破坏性变更？
0.44.0 删除了 legacy eBPF、gVisor engine 和 gRPC output，0.44.1 与 0.43 的用户态和驱动不兼容，升级必须成对进行。
Falco 的 auto 驱动模式有什么作用？
auto 模式是运维回退门，不是第三种内核引擎。它会在 modern_ebpf 不可用时自动回退到 kmod，但可能掩盖引擎差异，需谨慎使用。
