​Falco—云原生安全守护者

一 Faclo 介绍

      在云原生应用和容器化环境中，安全性成为了一个至关重要的关注点。随着容器技术的普及和应用的快速发展，容器环境中的安全挑战也日益增加。为了保护应用程序和数据免受潜在威胁，开发者和运维团队需要有效的安全工具和机制。Falco是一个开源的云原生安全工具，通过实时监控和检测容器、主机和Kubernetes集群中的安全事件，为云原生环境提供智能的守护功能。Falco 可以监测调用 Linux 系统调用的行为，并根据其不同的调用、参数及调用进程的属性发出警告。例如，Falco 可轻松检测：

•      容器内运行的 Shell

•      服务器进程产生意外类型的子进程

•      敏感文件读取（如 /etc/shadow）

•      非设备文件写入至 /dev

•      系统的标准二进制文件（如 ls）产生出站流量等

  其原理如下图所示：

二FALCO 安装

Falco的安装方式相对比较简单，单机版安装方式可以参考：https://falco.org/docs/getting-started/falco-linux-quickstart/

K8S中的安装方式可以参考：

https://falco.org/docs/getting-started/try-falco/try-falco-on-kubernetes/

这里需要说明一下的是我在centos7 中进行的安装时，遇到了bpf驱动无法下载的问题，改成了centos9就可以了，看了一下是因为没有对应的内核驱动导致的，这点需要注意一下。

三 Falco 配置

  Falco 单机规则配置文件为自带的falco_rules.yaml，以及可以用于自定义规则的falco_rules.local.yaml文件构成，如果在K8S中使用自定义的规则文件，需要创建configmap 指定。

   Falco的配置规则由三大部分组成分别为：Lists,Macros,以及Rules

•      Lists: 项目的命名集合，可以用于macros、rule甚至其他lists中，由list及items两部分构成，例如定义一个user_lists:

• - list: user_lists 

•    items: [root,lion,admin,nginx,public]

• Macros:可以在里边定义一些规则片段，方便在Rules中重复使用，例如判断用户在上面的（user_lists）中，可以使用上面的list，由macro

• 和condition 组成，conditi顾名思义，是各种表达条件例如定义一个用户在user_lists中的条件:

• - macro：user_in_user_lists

•    condition: user.name in (user_lists)

• 更多的表达式可以参考 https://falco.org/docs/rules/conditions/

• Rules: 最重要的部分，生成告警的规则，由下面几个部分组成：

•       rule: 规则名字

•       desc: 规则描述

•       condition：定义具体的规则内容，也可以使用上面的宏

•       exceptions: 排除的条件

•       output：输出的内容

•       priority：报警的级别

•       tags：规则的分类标签

• 例如：当user_lists 中的用户执行了frp 便进行报警，输出用户名，进程号，进程id完整的规则为：

• -list: user_lists

•   items: [root,lion,admin,nginx,public]

• -macro：user_in_user_lists

•  condition: user.name in (user_lists)

• -rule: some_one_open_frp

• condition：user_in_user_list and proc.name contains “frp”

• output: "Detected frp process (user=%user.name command=%proc.cmdline pid=%proc.pid)" 

• 这里说明一下，falco有着非常丰富的可以作为条件判断源（condition）和输出（output）的字段，例如user.name，proc.pid 等等，大致分为：evt（事件类）例如:evt.source

• ，process（进程类）例如 proc.name

• ，user（用户类）例如 user.name

• ，group（组类）例如 group.name

• ，container（容器类）例如 container.name

• ，fd（文件类）例如 fd.filename ,fd.cip

• ，syslog例如syslog.severity

• ，k8s ,例如：k8s.pod.name 等等，完整列表可以参考https://falco.org/docs/reference/rules/supported-fields/。

• 下面就分别在单机及k8s中分别挑几个案例进行演示

• 3.1 FALCO 单机

• 判断主机有外连行为：

• 规则为：

当发现主机外联时会有如下告警：

这里生成了一个cs的后门，通过strace跟踪ip

在Falco中生成的告警：

• Webshell 或 其他文件访问敏感文件 例如/etc/shadow,规则为：

产生的告警为：

• 检测frp规则：

产生的告警为：

3.2 FALCO k8s

    在k8s中，falco 作为daemonset启动，利用configmap将自定义规则加入:

同样的，当一个容器访问了敏感文件:

产生的告警为：

检测当一个特权容器启动规则为：

对应告警：

Falco支持将告警通过syslog，web，文件等发送，这里我将falco的告警转发至es中，并用kibana 进行了展示，由于测试关系我没有对内容字段进行进一步拆解。

四 Faloc检测ebpf 后门

现在有很多关于ebpf的研究，我曾试着想利用falco发现ebpf后门，不过，经过测试，falco仅仅发现了系统调用了bpf函数,如下图所示，但是并未找到如何配置，让其产生告警。希望有兴趣的读者可以进一步进行研究。

五 与ossec 比较

  在我的《互联网安全建设从0到1》这本书中，介绍了一款主机ids-ossec，这里可以简单的将两个软件进行比较，ossec的告警更多是依赖log进行，对log进行decoder，从而匹配规则，进而产生告警。而falco本身依赖的是系统的系统调用捕获，因此可以更加深度的对系统行为进行分析，而ossec，对容器方面支持的不够完善，而这正是falco的优势，当然ossec 可以进行集中管理，这点上falco还是需要运维软件进行控制，在这点上，不如ossec。

六 结语

   以上便是对falco的一些简单介绍，而falco的规则，有了gpt后，便更加容易编写了，很多规则可以通过询问gpt进行编写了，这很好的降低了编写规则的难度，但依然需要进行测试，毕竟有的时候gpt还是会一本正经的胡说八道。另外毕竟falco在这里仅仅是一个工具，想要真正发挥它的作用，还需要在日常工作中不断的打磨，需要对falco的资源占用情况，告警准确情况，进行不断的了解，改进这又变成了运营问题。同样的，这个软件想要发挥最大的价值，还需要考虑到其在公司业务系统的覆盖率，毕竟工程化一个软件，比研究一个软件的功能要难很多。