容器跑起来才是危险的开始：聊聊 Falco + eBPF + 行为检测这套“运行时安全真功夫”

大家好，我是 Echo_Wish。
混运维、安全这些年，有个感受越来越强烈：

现在的系统，最危险的时刻，不是上线前，而是“已经稳定跑了一段时间之后”。

镜像扫了、依赖查了、漏洞报表一堆，看起来挺安全。
可真出事的时候，十有八九是：

• 容器里突然多了个 shell
• 进程莫名其妙访问 /etc/shadow
• 应用半夜开始连奇怪的 IP
• K8s 里有人在 exec，但你不知道是谁

这类问题，有个统一的名字：运行时安全问题。

今天咱就不聊“安全大而全”，专门聊一件事：
Falco、eBPF 和行为检测，为什么是当下最靠谱的一条路。

一、先泼一盆冷水：运行时安全 ≠ 装个工具就完事

很多团队对运行时安全的理解，还停留在：

“是不是装个 Falco 就行了？”

我负责任地说一句：

只装 Falco，不理解行为模型，等于装了监控却不看告警。

运行时安全的本质不是“拦截”，而是：

• 看清楚系统正在干什么
• 判断这件事该不该发生
• 在不影响业务的前提下第一时间发现异常

这三点，正好对应：

• eBPF：看得清
• Falco：规则化
• 行为检测：判断对不对

二、eBPF：为什么说它是“运行时安全的眼睛”

以前做运行时安全，靠什么？

• 内核模块（风险高）
• ptrace（性能差）
• 日志分析（太慢）

eBPF 出来之后，本质上解决了一个老问题：

如何在不改内核、不影响性能的情况下，看清系统调用行为？

比如，一个进程在干什么？

• 起了哪些子进程
• 打开了哪些文件
• 连了哪些网络地址
• 有没有提权行为

用 eBPF，这些都能“实时、低开销”地拿到。

这也是为什么现在主流运行时安全方案，底层几乎清一色 eBPF。

三、Falco：不是“神器”，而是一套规则引擎

很多人对 Falco 的期望过高，觉得它能“自动发现攻击”。

其实 Falco 的定位非常清晰：

Falco = 基于系统调用的行为规则引擎

举个最常见的规则例子：

- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: container and proc.name in (bash, sh, zsh)
  output: Shell spawned in container (user=%user.name container=%container.name)
  priority: WARNING

这条规则干嘛的？

• 容器里
• 起了 bash / sh
• 直接告警

是不是攻击？不一定。
但在“不可变基础设施”的理念下：

生产容器里起 shell，本身就是异常行为。

Falco 不负责“判断动机”，
它负责 把不该发生的行为第一时间亮出来。

四、行为检测：真正拉开差距的地方

说点更现实的。

如果你在一个稍微复杂点的生产环境用过 Falco，很快会遇到一个问题：

告警太多了。

原因只有一个：
规则是死的，业务是活的。

这时候，行为检测就上场了。

1️⃣ 什么叫行为检测？

简单说一句人话：

先学“正常是啥样”，再抓“不像正常人的行为”。

比如：

• 某服务平时只访问 2 个内部域名
• 某容器启动后几乎不 fork 新进程
• 某 Pod 从不读 /proc、/sys

突然有一天：

• 开始频繁 fork
• 开始扫端口
• 开始连外网

这不需要 CVE，也不需要攻击特征。
它本身就“很不对劲”。

2️⃣ Falco + 行为检测怎么配合？

一个成熟的姿势是：

• Falco 做底线规则

  • shell
  • 提权
  • 敏感文件

• 行为检测做“偏离分析”

  • 行为频率
  • 行为组合
  • 行为时间段

我的理解是：

Falco 负责“抓现行”，行为检测负责“看气质不对”。

五、一个真实又常见的场景

某业务容器，某天 Falco 报警：

• 访问 /etc/passwd
• 执行 curl

乍一看像被入侵了。

但结合行为检测一看：

• 这是新发布的版本
• 引入了一个诊断脚本
• 行为只出现一次
• 没有后续横向动作

结论：误报，可放行并收敛规则。

反过来再看另一个：

• 夜里 3 点
• 非发布窗口
• 新增网络连接
• 连续 fork + exec
• 行为持续 10 分钟

哪怕 Falco 只报了一个低优先级告警，
这个也必须立刻处理。

六、我个人非常认同的一句话

运行时安全，不是“有没有攻击”，而是“系统有没有开始不像它自己”。

这也是为什么我越来越不迷信“规则大全”“CVE 全覆盖”。

真正有用的，是：

• 对业务行为有认知
• 对系统正常状态有基线
• 对异常变化保持敏感

七、给运维 / SRE 的几条实操建议

1️⃣ 别一上来就追求 0 告警
先追求“重要告警不漏”

2️⃣ 规则要分环境
生产、预发、测试，标准不一样

3️⃣ 行为检测一定要结合发布节奏
否则误报会把人逼疯

4️⃣ 运行时安全一定要进值班体系
不进 on-call，等于没装

写在最后

很多人觉得运行时安全“离业务很远”，
但我想说一句比较重的话：

越是核心系统，越不能只靠“上线前的安全”。

系统一旦跑起来，它就有了“生命”，
而 运行时安全，就是你听它心跳、看它脸色的方式。