【CSDN 编者按】eBPF 目前已经成了安全研究人员和黑客手中强大的工具，亦正亦邪，取决于使用者的选择。
随着 eBPF 技术在各种行业领域上的使用和普及，人们在享受着技术变革红利的同时，也遭受着无孔不入的恶意攻击，就像任何事物都有两面性一样。没有任何一项技术只有高高在上的优势，而没有弊端，只有更加清晰的刨析清楚 eBPF 的内核，才能推动它不断的进步，趋利避害，尽可能发挥正向的作用。
那么，eBPF 是天使，亦或恶魔？
越来越严峻的 Linux 安全形势
根据安全分析机构 ESG 云原生安全研究（链接见文末），88% 的网络安全专业人士表示，在过去 12 个月中，他们的云原生应用程序和基础设施遭受过攻击 。然而，许多旨在保护 Linux 的云安全解决方案可能很麻烦且具有破坏性，因为它们是从 Mac 或 Windows 操作系统上移植而来，这些方案有时会影响到 Linux 系统的处理能力，甚至进行更改。
1. 从端点监视和收集可能暗示威胁的活动数据
2. 评估收集的数据以确定威胁模式
3. 自动响应已识别的威胁以消除或遏制它们，并通知安全人员
4. 使用取证和分析工具研究已识别的威胁并寻找可疑活动
目前在 Linux 环境下，对于 EDR、XDR 产品也提出更加严格的要求：
1. Linux 威胁和攻击媒介与 Windows/Mac OS 对应物不同，需要单独构建策略。
2. Linux 通常是生产系统的基础，不能因为产品的中断或干扰会对业务产生负面影响。
3. 构建轻型 Linux EDR 传感器专为 Linux 构建和优化，对系统的影响降到最小。
基于 Linux 系统的云原生基础架构设施
云原生应用程序的组合是 CI/CD 持续集成和交付的 API、容器、VM 和无服务器功能的组合。保护这些应用程序、底层基础设施和协调其部署的自动化平台，需要重新审视威胁模型、获得组织一致性并利用有目的的控制。此外，随着安全性和 DevOps 不断融合，云安全控制正在得到整合。将孤立的方法发展为统一的策略，以保护云原生应用程序和平台是目前很多安全厂商发力的目标，也是甲方实实在在的需求。与此同时，更多的安全厂商正在尝试将云安全态势管理 (CSPM)、云工作负载保护 (CWP)、容器安全等方案，整合到集成的云安全套件中，从而增大自身安全产品在市场上的竞争力和话语权，也避免安全产品的碎片化。
云原生的基础设施包含 CPU 硬件、指令集，操作系统等，增强操作系统的高性能和安全性，也是目前 eBPF 技术正在深入的领域，所以 eBPF 自身的安全能力，也是检验该项技术是否有可持续发展的重要指标。
eBPF （扩展的 Berkeley 数据包过滤器）席卷了 Linux 世界。它于 2013 年首次推出以支持可编程网络，现在用于可观察性、安全性、网络等。许多大公司——包括 Meta、谷歌、微软和 Netflix——都致力于帮助开发和支持它，尤其是在云原生领域的重要性越来越高。注意：“ eBPF ”和“ BPF ”实际上是同义词，社区经常互换使用这些术语，部分原因是 eBPF 几乎完全取代了经典的 BPF 技术。
在过去的几年里，黑产组织一直在研究利用 eBPF 来开发并扩大 Linux 恶意软件方面的作用，安全研究人员则不停的修复漏洞，并试图提前感知预测 0-day 漏洞。最近，有一些 eBPF 相关的 CVE 报告示例频繁的出现在 DEFCON 和 BlackHat 等顶级安全会议上，也让人们更加的重视和担心 eBPF 的安全性，如下 topic，后续我会逐步翻译验证，并同步分享出来：
Evil eBPF In-Depth: Practical Abuses of an In-Kernel Bytecode Runtime
Warping Reality - creating and countering the next generation of Linux rootkits using eBPF eBPF, I thought we were friends !
With Friends Like eBPF, Who Needs Enemies?
Fixing a Memory Forensics Blind Spot: Linux Kernel Tracing
（3）只能与 kprobes 一起使用
eBPF 的核心是可以在 Linux 内核中类似虚拟机结构中运行的一种指令集架构 (ISA)，拥有寄存器、指令和堆栈等。为了使用 eBPF，用户可以创建 eBPF 程序并将它们附加到系统的适当位置，通常是在内核中。当与附加点相关的事件发生时，程序运行并有机会从系统读取数，将该数据返回给用户空间中的控制应用程序。总而言之，eBPF 允许用户动态安装在内核上下文中执行，但可从用户空间编排的代码。它有点像用户空间应用程序和 Linux 内核模块之间的混合体。
关于 eBPF 的基础知识无需赘述，网络上已经有太多丰富的教程和分析文章，个人建议初学者可以先从官方网站 上开始了解 eBPF 的前生今世，也可以直接在 kernel 源码具体实例中学习和验证。eBPF 在为诸多 Linux 内核开发者提供便利的同时，也为恶意软件的开发者提供了新的利用领域，这也就是“天使恶魔”的混合体来源。
下图总结了 eBPF 程序的整个生命周期：
安全优势：
1. Socket filters 套接字过滤器是经典 BPF 的原始用例。套接字过滤器是一个可以附加到套接字的 eBPF 程序。然后该程序可以过滤该套接字的传入流量。Berkley Packet Filter 的名称暗示它是一种旨在过滤数据包数据的技术。这个功能甚至一直保留到现代 eBPF 中。
2. ByteCode eBPF 程序通常以“受限”C 程序开始。受限意味着堆栈大小、程序大小、循环、可用函数等与普通 C 程序相比受到限制。C 代码被编译成 eBPF 字节码。
3. Verifier 在 eBPF 代码完全加载到内核之前，它会通过验证器运行。验证者的工作是确定 eBPF 程序是否可以安全运行。“安全”是指它不会陷入无限循环，没有不安全的内存操作，并且低于最大复杂度/代码大小。
安全策略：
1. 确保非特权 eBPF 被禁用。 如今，要安装 eBPF 程序，您通常需要 root——或至少需要 CAP_SYS_ADMIN 和/或 CAP_BPF。情况并非总是如此。围绕内核 4.4 引入了非特权 eBPF。请务必通过运行以下命令检查此配置选项：
sysctl kernel.unprivileged_bpf_disabled2. 禁用不需要的功能。管理员可以通过编程方式禁用诸如 kprobes 之类的东西：
echo 0 > /sys/kernel/debug/kprobes/enabled3. 在不支持 kprobes、基于 eBPF 的 TC 过滤器或完全支持 eBPF 的情况下构建内核（尽管这可能不是许多人的选择）。
4. ONFIG_BPF_KPROBE_OVERRIDE 除非绝对必要，否则不设置 Ensure。
安全检测：
从安全周期的角度来看，一场检测分为三个大阶段：事前（运行前）、事中（运行时）、事后（攻击后）。安全人员都希望可以在运行前通过一系列的静态分析方法来检测出异常，从而将问题扼杀在摇篮里。但现实往往事与愿违，更多的异常检测场景发生在运行时，这个时候就需要安全人员设计的产品模型具有很强的鉴白和鉴黑能力，这也是绝对了最终方案是否成功的基石。
从 eBPF 以及 Linux Tracing 的维度来看看具体方案：
1. 寻找加载的意外 kprobes。
#cat /sys/kernel/debug/kprobes/列表
ffffffff8ad687e0 r ip_local_out+0x0 [FTRACE]
ffffffff8ad687e0 k ip_local_out+0x0 [FTRACE]2. 用 bpftool 列出系统中正在使用 eBPF 的程序。
# bpftool prog
176: cgroup_skb tag 6deef7357e7b4530 gpl
loaded_at 2022-10-31T04:38:09-0700 uid 0
xlated 64B jited 54B memlock 4096B
185: kprobe tag a7ce508aab49e47f gpl
loaded_at 2022-10-31T10:03:16-0700 uid 0
xlated 112B jited 69B memlock 4096B map_ids 40
# bpftool perf
pid 543805 fd 22: prog_id 3610 kprobe func tcp_v4_connect offset 0
pid 543805 fd 23: prog_id 3610 kprobe func tcp_v6_connect offset 0
pid 543805 fd 25: prog_id 3611 kretprobe func tcp_v4_connect offset 0
pid 543805 fd 26: prog_id 3611 kretprobe func tcp_v6_connect offset 0
pid 543805 fd 28: prog_id 3612 kretprobe func inet_csk_accept offset 03. 查找加载的 XDP 程序。
$ ip link show dev <interface>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
prog/xdp id 220 tag 3b185187f1855c4c jited4. 检查 bpffs（BPF 文件系统）中是否有任何 pinned objects。
$ mount | grep bpf
…
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
…
#ls -la /sys/fs/bpf/5. 检查是否加载了任何 TC 程序。
#tc filter show dev <device-name>6. 监视系统日志中是否提及 BPF 帮助程序生成的警告消息。
#dmesg -k | grep ‘bpf_probe_write_user’总之，eBPF 目前已经成了安全研究人员和黑客手中强大的工具，亦正亦邪，取决于使用者的选择。由于这种范式将过去实施恶意利用的方式和流程进行了转变，对于安全人员也提升了要求，需要研究和理解新兴威胁的前沿技术及利用。
随着不断地地分析并认识到了如何识别和检测 eBPF 的恶意滥用，我们未来将更深入地了解此类利用的原理、行为方式以及检测它的最佳方式，后续研究分析将持续分享。
作者简介：
许庆伟：龙蜥社区 eBPF 技术探索 SIG 组 Maintainer 、高级内核技术专家，对 Linux 内核、系统稳定性领域有深入研究。
参考链接：
eBPF 技术探索 SIG 主页：https://openanolis.cn/sig/ebpfresearch
安全分析机构 ESG 云原生安全研究：https://www.esg-global.com/research/esg-research-report-the-maturation-of-cloud-native-security
本文经授权转自微信公众号 OpenAnolis（龙蜥）
☞华为回应出售手机业务传闻：假消息；微软将ChatGPT整合到更多工具中：不用写代码就能开发应用；苹果更新Mac产品线|极客头条 ☞不写代码就能开发应用，微软借助 ChatGPT，正在打造一个全新的商业软件帝国！ ☞没有 Nginx 的未来，Cloudflare 工程师正在用 Rust 重构代码！