Linux 中的 eBPF rootkit：通过承包商导致 DB 泄露

通过承包商部署的eBPF Rootkit：检测Linux中隐藏的数据库泄露

一台运行Ubuntu的数据库服务器在一个月内出站流量比入站流量高出5–10%。日志和进程看似正常，提供商确认网络运行正常。审计发现，攻击者通过一名DBA承包商被入侵的笔记本电脑部署了eBPF Rootkit。攻击者利用供应链安装了一个程序，隐藏进程并将PII数据外泄到C2服务器。

第一个线索：可疑的iptables规则

在/etc/iptables/rules.v4中，出现了一条允许出站TCP连接到承包商VPN池中IP的规则：

-A OUTPUT -d xxx.xxx.xxx.xxx -p tcp --dport YYYY -j ACCEPT

这条规则不属于基础配置。它允许隐蔽传输压缩的数据库表转储。分析/var/log/auth.log显示，承包商使用同一池中的IP通过SSH密钥登录。服务器访问在工作结束后被撤销，但VPN保持活动状态。

/proc中的不匹配指向Rootkit

ps auxf命令显示标准进程，但/proc中的目录数量比PID计数多一个。这表明getdents和getdents64系统调用被拦截。检查/proc/modules并使用LiveCD分析内核内存，未发现LKM模块——列表与基线匹配。

eBPF作为Rootkit基础：实现细节

bpftool实用程序揭示了附加到kprobe点__x64_sys_getdents和__x64_sys_kill的eBPF程序。一个额外的套接字程序重定向流量。在/usr/share/man/man3/中，发现了一个名为systemd-snoop的二进制文件，通过libbpf加载eBPF。

恶意软件在夜间转储PII表，压缩后发送到C2服务器。eBPF在模块列表中不可见，因为它通过bpf()系统调用加载。检测需要root权限运行bpftool或进行内核内存分析。在此案例中，对象未被隐藏。

攻击场景

• 承包商的笔记本电脑被入侵。
• 在通过SSH密钥的预定工作期间——登录到服务器。
• 添加iptables规则并安装systemd-snoop。
• 通过eBPF代理进行夜间数据外泄。

检测eBPF Rootkit的方法

标准AIDE无效——eBPF不修改/lib/modules中的文件。推荐方法：

• 定期收集bpftool prog list和bpftool map list并转发到SIEM。
• 通过auditd或ebpf_exporter审计bpf()系统调用。
• 使用Falco、Tracee或Osquery监控异常的eBPF活动。
• 分析NetFlow以检测流量差异，并与GeoIP关联。

保护供应链免受承包商威胁

身份验证和访问

• SSH强制使用2FA，即使使用密钥。
• 最小权限：无root访问，仅通过堡垒主机进行会话记录。
• 密钥每6个月轮换一次，终止后24小时内撤销。
• 临时VPN会话，自动断开连接。

基础设施

• 防火墙采用GitOps：iptables更改仅通过Ansible进行Git控制。
• 集中式ELK/Graylog + SIEM，用于关联日志、NetFlow和GeoIP。

关键要点

• eBPF Rootkit隐藏进程，在/proc/modules中不可见，通过bpftool检测。
• 通过承包商攻击：笔记本电脑入侵 + 残留VPN访问。
• 症状：流量不对称，/proc中PID不匹配。
• 保护措施：2FA、堡垒主机、bpf()审计、NetFlow监控。
• 工具：Falco、Tracee、ebpf_exporter用于运行时检测。

此案例展示了如何通过微小的流量异常发现长达一年的数据外泄。实施主动的eBPF监控和严格的访问控制，可以最小化外部团队带来的风险。

— Editorial Team