无解的博客

Appearance

wxvirus2026-09-20
2597
9.4m

Go 主机安全面试：Linux eBPF Rootkit 与异常内核探针检测 ​

eBPF 常被安全 Agent 用来采集 execve、网络连接和系统调用，但攻击者也可能利用 eBPF 程序做隐藏进程、过滤日志、截获凭据或绕过普通用户态检测。面试官通常会追问：eBPF 是安全能力还是攻击面？Go Agent 如何发现异常 BPF 程序？怎样区分自家 Agent、云厂商组件和恶意 Rootkit？

岗位场景 ​

text
Linux 主机
  -> 采集 BPF program、BPF map、挂载点、bpffs、kprobe/tracepoint、进程和内核版本
  -> 标准化程序类型、attach 点、加载者、owner、tag、pinned path 和权限能力
  -> 识别未知 BPF 程序、异常探针、敏感 hook、短时加载和隐藏痕迹
  -> 关联 Web RCE、提权、内核模块、凭据访问和网络外联

这类题考的是 Linux 内核观测、eBPF 权限模型、Rootkit 行为、主机安全降噪和 Go Agent 的低开销巡检能力。

高频面试题 ​

1. 为什么 eBPF 既是安全采集能力，也是攻击面？ ​

简洁答案：eBPF 可以在内核态观察或影响系统行为，安全产品用它采集事件，攻击者也可能用它隐藏行为、截获数据或干扰检测。

关键知识点：

  • eBPF 程序可以挂在 kprobe、tracepoint、LSM、socket、cgroup 等位置。
  • 新内核有 verifier、权限和 helper 限制，但高权限攻击者仍可能加载恶意程序。
  • 恶意 eBPF 常见目标是进程隐藏、网络隐藏、命令过滤、凭据截获和安全 Agent 对抗。
  • “看到 eBPF”不等于恶意，很多监控、网络、容器和安全产品都会用 eBPF。

Go 落地思路：

  • 把 eBPF 资产当成主机运行态对象，定期采集并做基线 diff。
  • 事件字段保留 program_id、type、tag、name、loaded_at、uid、attach_type、attach_target、pinned_path。
  • 规则层按“未知来源 + 敏感 attach 点 + 攻击链上下文”组合判断，不做单点误杀。

2. Go Agent 如何枚举主机上的 BPF 程序和 map？ ​

简洁答案：优先使用内核提供的 BPF syscall 或 bpftool 能力，读取程序、map、link 和 pinned path，再补充加载进程、权限和挂载点信息。

关键知识点：

  • BPF 程序和 map 有内核对象 ID，进程退出后对象仍可能因为 pinned 或引用计数存在。
  • /sys/fs/bpf 通常是 bpffs 挂载点，pinned path 能提示对象归属。
  • 只看进程列表不够，BPF 对象可能没有明显用户态进程长期持有。
  • 不同内核版本支持的 BPF 类型、link 信息和统计字段不完全一致。

Go 落地思路：

  • 采集层做能力探测，例如是否能枚举 BPF、读取 pinned path、读取 program info。
  • 不要把 bpftool 输出当作唯一依赖；生产 Agent 更适合直接走 syscall 或受控 helper。
  • 上报采集能力和失败原因，例如 permission_denied、kernel_too_old、bpffs_missing。
go
type BPFProgram struct {
	ID           uint32
	Name         string
	Type         string
	Tag          string
	AttachType   string
	AttachTarget string
	PinnedPath   string
	LoadedByUID  uint32
}

3. 哪些 eBPF attach 点更值得重点关注？ ​

简洁答案：和进程执行、文件访问、网络连接、权限检查、LSM hook、系统调用入口相关的 attach 点更敏感，因为它们能观察或影响关键安全行为。

关键知识点：

  • kprobe/__x64_sys_execve、sched_process_exec 能看到进程执行。
  • socket、cgroup、XDP 相关程序能影响或观测网络流量。
  • LSM BPF 可能参与安全决策，误用或恶意使用影响更大。
  • tracepoint/kprobe 事件量大，规则过宽会带来性能风险。

Go 落地思路：

  • 给 attach 点做风险分层：普通观测、敏感观测、可能影响决策。
  • 对敏感 attach 点保存 reason code，例如 hook_execve、hook_security_file_open、hook_tcp_connect。
  • 和进程、文件、网络事件关联：谁加载了程序，加载前后是否有 Web RCE、提权或异常外联。

4. 如何区分安全产品的 eBPF 程序和恶意 eBPF Rootkit？ ​

简洁答案：看来源、签名、路径、加载者、命名、pinned path、attach 点、加载时间和行为链路，而不是只看程序类型。

关键知识点：

  • 合法程序通常来自固定安装目录、稳定命名和已知服务进程。
  • 恶意程序可能名称伪装、短时加载、pinned 在可疑路径，或由 shell、脚本、临时目录二进制加载。
  • 云厂商 Agent、容器网络插件和可观测性组件都可能产生大量 eBPF 对象。
  • 降噪应落在资产、租户、版本和路径基线上，而不是全局放行某个类型。

Go 落地思路：

  • 建立 program tag + attach target + pinned path + vendor 的基线。
  • 新增未知对象时记录首次出现时间、加载者和主机角色。
  • 对可信组件做精确白名单，白名单也要有过期和审计字段。

5. eBPF Rootkit 可能隐藏哪些主机行为？ ​

简洁答案：常见目标是隐藏进程、过滤网络连接、过滤文件路径、干扰日志或截获敏感数据，本质是让普通观测源看到“不完整事实”。

关键知识点：

  • Rootkit 可能让 /proc、命令输出或某些采集链路看不到目标进程。
  • 网络隐藏可能表现为监听端口、连接或包统计不一致。
  • 文件隐藏可能表现为目录枚举和 inode、打开文件句柄、审计事件不一致。
  • 单一数据源被绕过时，多源交叉验证更可靠。

Go 落地思路：

  • 对关键证据做交叉检查，例如 procfs 进程快照、调度事件、网络连接、文件句柄。
  • 发现不一致时先标记 evidence_gap，再结合 BPF 异常和攻击链提高置信度。
  • 告警解释要写清楚“哪个数据源缺失、哪个数据源仍能看到”，方便客户复盘。

6. 如何检测短时加载后卸载的恶意 BPF 程序？ ​

简洁答案：只靠低频巡检容易漏掉短时对象，需要把 BPF 加载 syscall、审计日志、进程执行和周期快照结合起来。

关键知识点：

  • 攻击者可能加载 BPF 程序完成一次窃取或过滤后立刻卸载。
  • 低频扫描只能看到当前状态，看不到历史加载行为。
  • auditd/eBPF 自身采集、内核日志和进程命令行能补足加载证据。
  • 事件量要受控，不能把所有 syscall 原样上报。

Go 落地思路：

  • 对 bpf() syscall 加载、更新 map、pin/unpin 行为做摘要采集。
  • 本地维护短 TTL 的加载事件窗口，和快照 diff、进程事件关联。
  • 只上传结构化摘要：操作者、操作类型、对象 ID、类型、目标和结果。

7. eBPF 检测有哪些性能和兼容性问题？ ​

简洁答案：不同内核、发行版、权限和容器环境差异很大；采集要先能力探测，再按风险分层启用，避免在客户机器上强行打开高成本路径。

关键知识点：

  • 老内核可能缺少 BPF link、BTF 或部分 program info。
  • 容器环境里宿主机和容器 namespace 视角不同。
  • 枚举 BPF 对象通常成本不高，但频率过高仍会带来系统调用开销。
  • 采集失败也要上报，否则服务端会误以为“没有异常”。

Go 落地思路：

  • 启动时记录能力矩阵：内核版本、是否 root、是否有 CAP_BPF/CAP_SYS_ADMIN、bpffs 状态。
  • 巡检使用固定间隔和超时，失败后指数退避。
  • 把“无权限采集”和“未发现异常”分成两个状态。

8. 客户反馈 eBPF 异常告警误报，你会怎么排查？ ​

简洁答案：先确认程序来源和 attach 点，再核对主机角色、安装软件、加载时间、加载进程、pinned path 和同批主机基线，最后看是否有关联攻击链。

关键知识点：

  • 可观测性、容器网络、安全软件和云厂商 Agent 都可能加载合法 eBPF。
  • 误报治理不能只删规则，要保留为什么放行的证据。
  • 同一程序如果只在少量异常主机出现，比全租户一致出现更可疑。
  • 客户现场排查要避免要求上传敏感 payload 或完整内核对象内容。

Go 落地思路：

  • 输出排障字段：program_id、tag、name、attach_target、pinned_path、loader_process、host_role。
  • 支持离线回放客户样本，验证 suppression 不会压掉 Web RCE、提权后的恶意加载样本。
  • 降噪规则限制到具体 vendor、路径、tag、版本和租户范围。

通俗答案 ​

可以把 eBPF 理解成“能挂到内核关键位置的小程序”。安全产品用它看清进程和网络，攻击者也可能用它遮住证据。面试回答时不要把 eBPF 神化成万能采集，也不要一看到 eBPF 就报警。更稳的思路是：先盘点主机上有哪些 BPF 对象，再看它们挂在哪里、谁加载的、是否符合资产基线，最后和进程、文件、网络、提权链路放在一起判断。

Go 落地要点 ​

  1. 采集层：枚举 BPF program、map、link、pinned path 和能力矩阵。
  2. 标准化层：统一 id、tag、type、attach_target、loader、source。
  3. 检测层：对未知来源、敏感 hook、短时加载和多源证据不一致做评分。
  4. 降噪层：按 vendor、路径、tag、主机角色和租户基线做精确 suppression。
  5. 排障层：保留采集失败原因、能力缺口和告警 reason code。

学习要点 ​

  • 熟悉 eBPF 的 program、map、link、bpffs、kprobe、tracepoint、LSM 基本概念。
  • 理解高权限攻击者可以把安全采集技术反过来作为攻击面。
  • 掌握多源交叉验证：procfs、进程事件、网络事件、文件句柄和 BPF 对象。
  • 能把性能、权限、兼容性和误报治理讲成工程方案。

小练习 / 复盘题 ​

  1. 设计一个 BPFProgram 事件模型，列出最小字段和可选字段。
  2. 写一条规则：未知程序挂到 execve 相关 hook，且加载者来自临时目录，输出需要的证据字段。
  3. 说明为什么“主机上存在 eBPF 程序”不能直接判定为 Rootkit。
  4. 复盘一个误报场景：容器网络插件升级后新增大量 BPF 程序，如何降噪但保留审计？
  5. 如果客户环境没有权限枚举 BPF 对象，你会保留哪些降级检测能力？
最近更新