关于linux:ebpflinux-安全双刃剑

EBPF 技术简介

eBPF 全称 extended BPF，Linux Kernel 3.15 中引入的全新设计, 是对既有 BPF 架构进行了全面扩大，一方面，反对了更多畛域的利用, 另一方面，在接口的设计以及易用性上，也有了较大的改良。

eBPF 是一个基于寄存器的虚拟机，应用自定义的 64 位 RISC 指令集，可能在 Linux 内核内运行即时本地编译的“BPF 程序”，并能拜访内核性能和内存的一个子集。

倒退历史

工作机制

ebpf 带来的平安威逼

eBPF 的 hook 点性能包含以下几局部：

1. 能够在 Storage、Network 等与内核交互之间；
2. 也能够在内核中的功能模块交互之间；
3. 又能够在内核态与用户态交互之间；
4. 更能够在用户态过程空间。
5. eBPF 的性能笼罩 XDP、TC、Probe、Socket 等，每个性能点都能实现内核态的篡改行为，从而使得用户态齐全致盲，哪怕是基于内核模块的 HIDS，一样无奈感知到这些行为。

网络层歹意利用 ebpf

以一个 SSH、WEB 服务的服务器为例，在 IDC 常见网络拜访策略中，凋谢公网 web 80 端口容许任意起源的 IP 拜访。而 SSH 服务只容许特定 IP，或者只凋谢内网端口拜访。

假如这台服务器曾经被黑客入侵，黑客须要留下一个后门，且须要一个暗藏、牢靠的网络链路作为后门通道，那么在 eBPF 技术上，会如何实现呢？

XDP/TC 层批改 TCP 包

为了让后门暗藏的更好，最好是不开过程，不监听端口（以后局部咱们只探讨网络层暗藏）。而 eBPF 技术在 XDP、TC、socket 等内核层的性能，可能实现流量信息批改，这些性能常被利用在 L3、L4 的网络负载平衡上。比方 cilium 的网络策略都是基于 eBPF XDP 实现。eBPF hook 了 XDP 点后，更改了 TCP 包的指标 IP，零碎内核再将该数据包转发进来。

依照 XDP 与 TC 在 Linux 内核中，解决 ingress 与 egress 的地位，能够更精确地确定 hook 点。

零碎层歹意利用 ebpf

实现流程

回顾 eBPF 的 hook 点，作用在 syscall 的 kprobe、tracepoint 事件类型，假使用在后门 rootkit 场景，是非常可怕的。比方，批改内核态返回给用户态的数据，拦挡阻断用户态行为等随心所欲。而更可怕的是，常见的 HIDS 都是基于内核态或者用户态做行为监控，这恰好就绕开了大部分 HIDS 的监控，且不产生任何日志.

tracepoint 事件类型 hook

在 SSHD 利用中，当用户登录时，会读取 /etc/passwd 等文件。用户态 sshd 程序，调用 open、read 等零碎调用，让内核去硬件磁盘上检索数据，再返回数据给 sshd 过程。

用户态生成 payload

用户态实现 /etc/passwd、/etc/shadown 等文件 payload 的生成，并通过 eBPF 的 RewriteConstants 机制，实现对 elf .rodata 的字段值替换。

内核态通过 ebpf 调用实现了随机用户名明码的 root 账号增加。在鉴权认证上，也能够配合 eBPF 网络层歹意利用 的 demo，利用 eBPF map 交互，实现相应鉴权。但 rootkit 自身并没有更改硬盘上文件，不产生危险行为。并且，只针对特定过程的做笼罩，隐蔽性更好。

平安进攻应答

运行前

在恶意程序运行前，缩小攻击面，这个思路是不变的。

环境限度

不论是宿主机还是容器，都进行权限收敛，能不赋予 SYS_ADMIN、CAP_BPF 等权限，就禁止掉。若肯定要凋谢这个权限，那么只能放到运行时的检测环节了。

seccomp 限度

在容器启动时，批改默认 seccomp.json，禁止 bpf 零碎调用，避免容器逃逸，留神此办法对于 Privileged 特权容器有效。

内核编译参数限度

批改函数返回值做运行时防护时，须要用到 bpf_override_return，该函数须要内核开启 CONFIG_BPF_KPROBE_OVERRIDE 编译参数，因而非非凡状况不要开启该编译参数。

非特权用户指令

大部分 eBPF 程序类型都须要 root 权限的用户能力调用执行。但有几个例外，比方 BPF_PROG_TYPE_SOCKET_FILTER 和 BPF_PROG_TYPE_CGROUP_SKB 这两个类型，就不须要 root。但须要读取系统配置开关。

运行时

监控

Linux 零碎中，所有的程序运行，都必须进行零碎调用，eBPF 程序也不例外。须要调用 syscall 为 321 的 SYS_BPF 指令。并且，所有的 eBPF 程序执行、map 创立都必须进行这个 syscall 调用。那么，在这个必经之路进行拦挡监控，是最好的计划。

依据程序白名单筛选

在一些 BPF 利用的业务服务器上，自身业务行为会产生大量调用，会给平安预警带来较大审计压力。对于已知的过程，咱们能够依据过程特色过滤。

获取以后过程 pid、comm 等属性，依据用户态写入 eBPF map 的配置，决定是否上报、是否拦挡。

依据 SYSCALL 类型筛选

在 BPF syscall 里，子命令的性能蕴含 map、prog 等多种类型的操作，bpf() subcommand reference 里有具体的读写 API。在理论的业务场景里，“写”的平安危险比“读”大。所以，咱们能够过滤掉“读”操作，只上报、审计“写”操作。

运行后

如果恶意程序比查看工具运行的早，那么对于后果存在伪造的可能。

平安工程师须要依据不同场景作不同的溯源策略：

命令 bpftool prog show，能够看到以后零碎正在运行的 BPF 程序、关联的 BPF map ID，以及对应的过程信息等。

命令 bpftool map show，通过查看 map 信息，能够与程序信息作辅助改正。并且，能够导出 map 内数据用来辨认歹意过程行为。

bpflist-bpfcc -vv 命令能够看到以后服务器运行的“局部”BPF 程序列表。

bpftool net show dev ens33 - p 命令能够用于查看网络相干的 eBPF hook 点。

结语

EBPF 目前作为一门绝对热门的技术，在越来越多技术人员理解到其方便性和高效率的同时，也会带来相当一大部分的“滥用”和“歹意利用”。正越来越成为平安畛域不可回避的一个安全隐患甚至平安危险。

平安技术人员，既须要了解 ebpf 的实现机制，相熟罕用 ebpf 工具，又要可能理解并发现零碎中被有心或者无心引入的这些 ebpf 的“泛滥”应用，加以封堵和标准，能力真正的用好 ebpf，这把 linux 内核的平安“双刃剑”。