Falco 主机侧异常检测框架设计解析：基于 Count-Min Sketch 的 `anomalydetection` 插件提案

• 云原生
• 运行时防护
• IDS
• 应用安全

本篇文章以 Falco 仓库中的设计提案 proposals/20230620-anomaly-detection-framework.md 为核心，系统讲解 Falco 如何在保持单遍、零分配实时事件流的前提下，借助 Count-Min Sketch 概率数据结构为应用建立"行为画像（behavior profile）"，将计数估计暴露为新的 filtercheck 字段，供 Falco 规则基于"预过滤数据"而非原始事件流做异常检测。读完本文，你将理解该框架的动机、核心算法选型、面临的挑战、插件化接口设计方向与演进时间线，并能结合仓库源码看懂插件系统与规则引擎如何被接入。

一、背景与动机：规则匹配为何追不上攻击者

Falco 作为云原生运行时安全工具，其传统检测方式依赖规则与签名匹配——基于"我们认为攻击者会做什么"来建模。这一范式存在两个结构性短板：

1. 信息不对称：威胁行为者不断变换手法，规则与签名却假设攻击者的行为是静态的；
2. 信噪比失控：规则驱动的检测会产生大量告警，足以把安全分析师淹没在"沙暴"般的低质量信号中。

提案提出一个关键转向：检测"当前行为与过去行为的偏差"，而非仅匹配已知模式。通过高级数据分析，把 Linux 内核的精细信号与主机侧异常检测结合，识别运行应用的"过往行为模式"，从而把注意力从"签名与规则匹配"转移到"行为偏差"上。这套框架本质上是用攻击者的思维做检测工程——先观察和学习目标，从而产出更丰富、可操作的告警，无论该行为是否曾被见过。

二、核心思想（Elevator Pitch）：从"状态引擎"到"行为画像"

提案用一段精炼描述概括了整体思路：

Falco 在用户态处理事件时，规则引擎对事件做过滤，解析器同时更新并维护内部状态。该状态包含进程树缓存，能依据历史事件为告警提供上下文。目标是把这套"状态引擎"进一步升级，提供随时间监控应用行为的选项。

具体流程可以拆解为四个环节：

1. 定义行为画像：终端用户在配置中，将已有事件字段（如进程名proc.name、文件描述符fd、可执行文件路径、父进程谱系、命令行cmdline等）组合起来定义一个"行为画像"（behavior profile）；
2. 热路径压缩存储：在事件解析的热路径（hot path）上，Falco 将这些信息压缩并存入一种高效的概率数据结构（filter），在空间、时间、鲁棒性、准确性之间取得平衡；
3. 随时间提供计数估计：随着时间推移，Falco 能给出应用行为计数的更精确估计，并把事件标记为rare（稀有）或heavy hitters（高频项）；
4. 基于预过滤数据写规则：分析对象不再是原始事件流，而是预过滤后的数据，规则可以直接消费 sketch 的计数估计。

这套方案带来的直接价值是：

• 数据驱动、实时：异常行为的识别来源于"观察与学习"，无需运营人员重新配置 Falco；
• 零分配、单遍流：设计灵感来自大数据流处理与数据库查询优化，保证 Falco 维持精简的实时单遍（one-pass）流，且零分配（zero allocations）；
• 多画像协作：与 Falco 规则类似，事件分析可能需要多个不同维度的行为画像，这些画像可以**并行投票（vote in parallel）或级联（cascading）**工作——这是成熟算法中的常见做法；
• DAST 式冷启动缓解：提案展望了更进阶的用法——以类似 DAST（动态应用安全测试）的能力，在工作负载上以测试数据构建"预状态模式文件"，再分发到生产环境以缓解冷启动问题。

三、挑战与设计考量

3.1 数据正确性假设

Falco 项目持续致力于扩大内核信号覆盖面并提升其质量，例如验证 execve 调用是否关联到仅存在于内存中的文件描述符、提升可执行文件路径符号链接解析的效率与可靠性。本提案的异常检测框架假设已有"正确"的数据，与上述提升日志覆盖面与质量的工作互补——框架的核心是从现有"正确"数据中挖掘更多价值。

3.2 "稀有"概念的内生难点

普遍认知是：当数据或信号组合适当时，针对运行中云应用的攻击及其入侵指标通常是稀有的。但把"稀有"应用于稳健的数据分析存在固有挑战：

• 攻击向量多样：攻击者可能在取得初始访问后投放新的恶意二进制（传统规则与高价值内核信号相对容易检测）；也可能利用现有二进制、shell 内建命令加混淆技术"就地取材（live off the land）"。后者在图灵完备性上意味着无穷多的攻击可能性；
• 信号选择更难：真正的难点往往不在攻击本身，而在于识别正确的信号及其恰当组合，以区分正常与异常行为。应用行为随时间的自然波动、临时性的合法调试活动、例行部署更新，都会造成扰动；
• 噪声场景：某些应用正常运行时会生成随机文件名或执行任意可执行路径；初次观察应用时还面临固有的"冷启动（cold start）"问题；
• 数据表征差异：数据不一致、数值与语义各异的字符串混杂等，都进一步增加复杂度。

提案强调：算法必须像人类一样，通过考察文件名组合、命令参数、父进程谱系等属性来识别"相同性"，具备灵活性与鲁棒性。

3.3 运维人员启发式知识：算法的"引导之手"

提案用一个生动的例子说明：现有算法能生成人脸，但早期经常生成不同颜色眼睛的图像；如果告诉机器"人类通常双眼颜色一致"，机器很快就能修正这个偏差。这体现了安全工程师作为算法引导之手的作用——既包括噪声容忍度的处理，也包括选择合适的数据喂给算法。这一点至关重要，因为机器目前从有限数据与受限内存中得出有意义观察的能力仍然有限。数据驱动的异常检测与规则匹配的融合，正是这一框架的落点。

3.4 主机侧实时分析的独特价值

在主机上做实时异常分析的价值在于它提供了其他方式无法实现的选项：主机上可以基于所有相关且被观测到的内核事件观察异常；而把海量内核事件发送到集中式系统则极不现实——数据管道管理与数据湖计算会带来高昂成本。这正是"为什么选择在主机本地做异常检测"的核心论据。

四、初始范围：Count-Min Sketch + n 个共享 sketch + filtercheck

初始范围明确为三件事：

1. 实现 Count-Min Sketch 算法：使用 n 个共享 sketch（n shared sketches），并将其计数估计暴露为新的 filtercheck，供 Falco 规则使用；
2. MVP 探索：提案提到可在 libs 仓库的草案 PR（libs #1453，wip: new(userspace/libsinsp): MVP CountMinSketch Powered Probabilistic Counting and Filtering）中探索 MVP 实现；
3. 透明的插件用户接口：初始异常检测框架将包含一个透明的anomalydetection插件界面，用于定义应用行为画像，并在 Falco 规则中使用 sketch 计数估计。

首要的直接收益：为生产环境中的 Falco 规则建立"安全边界（safety boundary）"——允许更广泛地监控规则，同时防止规则在生产中"爆炸（blow up）"。

此外，Falco 项目将为采用者提供：

• 有价值的初始用例（use cases）；
• 推荐的阈值（recommended thresholds）；
• 已知问题的提示（known issues callouts）；
• SRE 反模式的识别指导；
• 配置参数的非常清晰的设定指引，包括推荐最小值；
• 定义应用行为画像时，需要观察哪些指标以判断是否需要调整、以及向哪个方向调整的指导。

五、高层技术设计：概率数据结构与插件接口

5.1 概率数据结构选型：Count-Min Sketch

实现概率过滤器的一个选择是使用稳健的二维概率数据结构Count-Min Sketch（CMS）。它被广泛用于 Apache Spark、Apache Storm、Apache Flink 等分布式流处理框架，以及 Redis、PostgreSQL 等数据库中。

提案针对选型给出了关键决策点：

5.2 管道与接口：与现有插件/规则机制的集成

终极目标是把这些新能力作为插件引入。大量工作将投入必要的"管道（plumbing）"，使其与现有规则过滤、libsinsp和plugin机制集成，提供一个对用户友好的、可配置的 opt-in 框架。接口设计需要让终端用户能够：

• 定义误差容忍度，进而推导sketch 维度（宽度与深度）；
• 配置其他调优参数、边界与设置；
• 最终定义n 个行为画像，以在 Falco 规则中使用计数估计。

5.3 仓库中的插件系统佐证

该提案所依托的插件系统，在仓库中已有完整的设计与实现沉淀，可对照阅读：

• 插件系统设计提案：proposals/20210501-plugin-system.md 定义了 source 插件与 extractor 插件两类能力，以及事件源（event source）、filtercheck 字段提取、插件动态库（.so/.dll）与plugin_*导出符号约定；
• 插件配置解析：falco.yaml中的load_plugins与plugins配置节由 userspace/falco/configuration.cpp 解析，plugin_config结构体（含m_name、m_library_path、m_init_config、m_open_params）定义于 userspace/falco/configuration.h；当load_plugins未定义时全部插件默认加载，指定时则仅加载匹配名称的插件，否则抛出 "Cannot load plugin" 逻辑错误；
• 插件加载动作：userspace/falco/app/actions/load_plugins.cpp 展示了 Falco 如何先注册插件、获取插件事件源并建立事件源与 filtercheck 列表的映射——anomalydetection插件的接入点与此完全一致：它作为事件源插件注册，为规则引擎提供新的 filtercheck 字段；
• 插件列表查看：userspace/falco/app/actions/list_plugins.cpp 对应falco --list动作，可枚举已配置插件及其字段信息，便于调试行为画像字段是否被正确导出。

从插件系统的成熟度看（详见下文"为什么是现在"），插件已能协作现有的 syscall 事件源——这正是提案中k8smeta插件所演示的能力，其在 Helm 图表中已有配置沉淀，见 chart/falco/values.yaml。

5.4 典型配置形态（基于现有插件配置语法推演）

虽然行为画像的最终定义位置（插件配置还是规则文件）在提案中尚未定论（见下文社区反馈），但基于 falco.yaml 中现有的插件配置语法（plugins列表 +load_plugins选择加载），可以合理推演其接入形态：

# 在 falco.yaml 中声明 anomalydetection 插件（示意，字段以最终实现为准） load_plugins: [anomalydetection] plugins: - name: anomalydetection library_path: libanomalydetection.so init_config: | # 定义误差容忍度，进而推导 sketch 维度 error_tolerance: 0.001 ...

需要强调的是：该配置仅为基于现有插件接口（library_path、init_config、open_params等，见 userspace/falco/configuration.h 的解析实现）的推演示例，最终配置键与行为画像语法以插件实际发布版本为准。从源码结构看，插件配置采用 YAML 解码为plugin_config，init 配置可以是字符串或 YAML 映射，这为承载"画像字段列表"这类结构化配置提供了空间。

六、该框架不是什么（边界澄清）

提案明确划定了框架边界，避免误用：

• 不是事件聚合器/增强器：不像 netflow 数据那样做事件聚合或富化。它的唯一目的是充当单个事件的异常过滤器，利用现有 sinsp 状态、通过 sketch 新建的状态以及现有规则引擎；
• 不受过度特定用例左右：框架开发不会被限制其广泛采用与覆盖面的、过于具体的用例所牵制；
• 初期不追求完美检测：它不会从一开始就提供无懈可击的威胁检测，而是作为全面事件日志与分析的第一步——捕获所有表现出任何形式"新的或变化行为"的事件。因此，初期的最大价值在于：将常规 Falco 规则与基于异常过滤后事件流的检测结合使用。

七、为什么是现在：时机的成熟度论证

提案从两个维度论证"为什么是当下"：

1. 算法已成熟：高级数据分析如今是主流，Falco 可以直接复用业界生产环境中广泛验证的稳健算法，创新的重点在于解决网络安全领域特有的数据编码挑战，而非重新发明算法；
2. 插件系统已就绪：过去多个 Falco 版本显著提升了稳定性、可配置性与能力。过去一年插件系统被持续打磨，能够高效访问完整的libsinsp状态，并新增了改进的CPP SDK；更重要的是，插件现已能与现有主 syscall 事件源无缝协作——这偏离了其最初"处理新数据源"的定位，使得交互更直观，k8smeta插件就是例证。因此，现在正是进一步增强经过验证的威胁检测能力、进一步扩展插件系统的合适时机。

八、社区反馈与待决事项

8.1 KubeCon NA 2023 演讲反馈

提案引用了 KubeCon NA 2023 的演讲（"A Wind of Change for Threat Detection"）反馈：

• 整体评价非常积极，尤其认可其直接的现实收益——为 Falco 规则提供安全边界，使监控范围更广而不至于在生产中爆掉；
• 未来发展方向建议包括：把 sketch 直接集成进内核驱动（若可行将是里程碑式成果）；
• 多人询问该功能的可用时间线。

演讲材料以 PDF 形式附于仓库：proposals/kubeconna23-anomaly-detection-slides.pdf。

8.2 Falco 社区例会（2024-01-17）关键反馈

• filtercheck 访问权限：插件目前无法访问现有libsinsp的 filtercheck。社区反馈（来自 @jasondellaluce）认为应开放该访问，以避免重新实现它们并持续面临与libs不同步的风险；@leogr 表示随时间推移支持这一点是可能的；
• 画像定义位置未决：每个 sketch 的行为画像定义（即被字符串拼接并计数的字段）究竟放在插件配置还是规则文件中，尚未定论——后者可能需要一个新规则组件。最终决定将推迟到后期，以确保配置直观，并保证在尝试用anomalydetection插件运行 Falco 规则时 sketch 定义正确；
• 规则名暴露：一个用例（判断某规则是否曾在某容器中触发过）可由该框架解决，但如何暴露规则名尚不明确，因为libsinsp并不感知规则名。这可能作为后期优化，不阻塞初版开发；
• 未来扩展：未来用例可能涉及统计不同值（distinct counting），可引入HyperLogLog算法，但存在额外技术挑战；
• 驱动与用户态互通：有人建议未来在驱动与用户态之间传递情报（例如内核侧过滤方向），但这属于长期考量。

九、提案时间线与当前仓库状态

提案提出的时间线如下：

作为佐证，该提案本身经由 PR（falco #2655）合入仓库，相关记录可见 CHANGELOG.md。需要说明的是：上述时间线是提案撰写时的规划，当前仓库主版本线（截至 CHANGELOG 最新条目为 v0.45.0）的实际发布节奏与特性状态，应以各版本的发布说明与插件仓库为准，本文不做过度的版本断言。

十、参考资料与延伸阅读

• 提案原文：proposals/20230620-anomaly-detection-framework.md
• 插件系统设计提案：proposals/20210501-plugin-system.md
• 特性采纳与弃用机制（配置成熟度标签的背景）：proposals/20231220-features-adoption-and-deprecation.md
• KubeCon NA 2023 演讲材料（仓库附件）：proposals/kubeconna23-anomaly-detection-slides.pdf
• 插件配置主文件：falco.yaml
• 插件配置解析实现：userspace/falco/configuration.cpp 与 userspace/falco/configuration.h
• 插件加载动作实现：userspace/falco/app/actions/load_plugins.cpp
• Helm 图表中的插件编排示例（k8smeta）：chart/falco/values.yaml

提案在技术细节上还引用了若干经典资源供深入钻研：关于大数据应用的概率数据结构与算法专著（Probabilistic Data Structures and Algorithms for Big Data Applications）、Count-Min Sketch 的系列博客、Count-Min Log Sketch 论文、Count-Min Sketch with Conservative Updates（CMS-CU）论文，以及将xxHash（xxh3）作为新增依赖以提供快速可靠哈希的设想。这些资源的完整书目信息均列于提案末尾的 Resources / References 一节。

• 云原生
• 运行时防护
• IDS
• 应用安全