Go 主机安全面试：Agent 采集能力探测与降级设计

主机安全 Agent 不可能在每台机器上都拥有相同的采集能力。内核版本、BTF、内核配置、容器权限、Linux lockdown、seccomp、审计策略和客户安全软件，都可能让 eBPF、auditd、procfs 或 netlink 的能力发生变化。

面试官问“某台机器为什么没有进程或网络事件”时，真正想考的是：你能不能区分“没有发生事件”和“采集器没有能力看到事件”，并且在能力受限时给出可解释、可观测、不会拖垮主机的降级方案。

岗位场景

Agent 启动
  -> 探测内核、权限、文件系统和采集入口
  -> 生成能力快照与覆盖范围
  -> 按能力选择 eBPF、auditd、procfs、netlink 等采集方式
  -> 运行时监控探针、读取器和队列健康
  -> 局部失败时降级，不影响其他采集器
  -> 上报能力状态、覆盖缺口和恢复时间

这类题的核心不是“所有机器都必须使用 eBPF”，而是让检测结果带着能力边界。没有观测能力时要明确告诉服务端和客户，不能把未知伪装成安全。

高频面试题

1. 为什么 Agent 启动时要先做能力探测？

简洁答案：同一个二进制在不同主机上的可观测范围可能不同。启动时先探测，可以提前选择采集路径、报告覆盖缺口，并避免等到线上丢事件后才发现探针根本没有加载成功。

关键知识点：

• 内核版本、架构、BTF、CONFIG_BPF 和 CONFIG_AUDIT 会影响能力。
• root、CAP_BPF、CAP_PERFMON、CAP_SYS_ADMIN 等权限会影响 eBPF 操作。
• 容器中的 /proc、/sys/kernel/debug、/sys/fs/bpf 可能不可见或不可写。
• Linux lockdown、seccomp 和安全软件可能阻止加载、挂载或读取。

Go 落地思路：

• 探测结果至少区分 available、degraded、unavailable，不要只用布尔值。
• 每项能力保存原因码和探测时间，例如 missing_btf、permission_denied、kernel_unsupported。
• 启动探测只做低成本检查，不要为了验证 eBPF 而长时间挂载或加载大量生产探针。

2. eBPF 不可用时，应该如何降级？

简洁答案：按事件类型选择替代路径，而不是把所有能力粗暴切到一种后备方案。进程执行可以退回 auditd 或有限的 procfs 扫描，网络连接可以使用 netlink 快照，文件行为则根据风险决定是否使用 fanotify 或定时基线。

关键知识点：

目标	首选	可选降级	主要损失
进程执行	eBPF exec 事件	auditd、procfs 轮询	实时性或完整性下降
网络连接	eBPF connect/close	netlink 快照	短连接可能漏掉
进程画像	procfs	auditd 命令线索	字段不完整或读取受限
文件落地	fanotify/inotify	定时扫描、基线比对	事件时序和瞬时文件难捕获

Go 落地思路：

• 用事件类型到采集器的固定映射，避免运行时随意切换造成重复事件。
• 切换采集器时保留 source、coverage 和 degraded_reason 字段。
• 降级后的事件不要伪装成首选路径产生的完整事件，规则层要知道证据强度变化。

type CapabilityState string

const (
	StateAvailable   CapabilityState = "available"
	StateDegraded    CapabilityState = "degraded"
	StateUnavailable CapabilityState = "unavailable"
)

type Capability struct {
	Name   string
	State  CapabilityState
	Source string
	Reason string
}

3. 如何判断“没有进程事件”是没有进程执行，还是采集器失效？

简洁答案：不能只看事件数量。要同时看探针状态、采集器心跳、内核计数器、读取错误、最近一次成功时间和其他独立信号。

关键知识点：

• 零事件可能代表零执行，也可能代表 attach 失败、ring buffer 读取停止或权限变化。
• 采集器要有独立健康信号，不能用“收到事件”代替健康检查。
• 进程执行计数、丢弃计数、解析失败计数和上报计数要分开。
• 发生能力变化时，应记录状态转换，而不是只覆盖最后状态。

Go 落地思路：

• 为每个采集器维护 last_success、last_error、events_read、events_dropped。
• 读循环遇到可恢复错误时重试，遇到权限或内核不支持时转为降级并上报原因。
• 服务端看到“长时间零事件 + 健康检查失败”时，展示覆盖缺口而不是生成“主机无活动”结论。

4. 运行时能力变化有哪些典型原因？

简洁答案：能力不是启动后永久不变的。管理员可能修改审计规则、卸载 BPF 文件系统、调整容器权限、切换 lockdown 状态，或者 Agent 自身探针因资源不足退出。

关键知识点：

• auditd 规则可能被重载、清空或被其他管理工具覆盖。
• BPF map、ring buffer 或 perf buffer 可能因为资源不足、程序退出或 pin 路径异常而失效。
• /proc、/sys 和网络命名空间可能发生变化，尤其是在容器或服务重启后。
• 内核升级、Agent 热更新和安全策略变更都可能改变采集条件。

Go 落地思路：

• 采集循环发现 EOF、读错误或丢失计数异常时，先做有限次数重连。
• 恢复成功后上报 capability_recovered，让服务端能解释时间段内的覆盖缺口。
• 重试要有退避和上限，避免探针故障时忙等消耗 CPU。

5. 如何设计采集能力的状态机？

简洁答案：用少量明确状态覆盖启动、运行、降级、恢复和停止，状态转换必须带原因和时间。不要把每种内核错误都设计成一个状态。

一个够用的状态流转是：

probing -> available
probing -> degraded
probing -> unavailable
available -> degraded -> recovering -> available
available -> unavailable

关键知识点：

• degraded 表示还有部分覆盖，unavailable 表示该能力完全不可用。
• recovering 用于避免恢复过程中的频繁抖动。
• 状态转换应幂等，重复的相同错误不能产生告警风暴。
• 能力状态和主机安全告警是两类对象，不能把每次降级都当攻击。

Go 落地思路：

• 一个小的 Capability 结构和状态转换函数就够用，不需要引入状态机框架。
• 对相同 name + state + reason 在时间窗口内合并，只保留首次、最近一次和计数。
• 规则判断读取能力快照，遇到关键证据缺失时输出“无法确认”或降低置信度。

6. procfs 和 netlink 作为降级采集时，有哪些边界？

简洁答案：procfs 和 netlink 适合补充快照，但不能假设它们能替代所有实时事件。它们有读取权限、时间窗口、短生命周期对象和命名空间等边界。

关键知识点：

• /proc/<pid> 需要进程仍然存在，短命进程可能在扫描前已经退出。
• /proc 中的命令行、环境变量和 fd 信息可能被权限或 mount 选项限制。
• netlink 连接表是快照或状态变化信息，不一定保留每一次短连接。
• 容器和宿主机的 PID、网络命名空间不同，采集器必须记录 namespace 归属。

Go 落地思路：

• 读取 procfs 时先打开目标文件，再基于已打开的 fd 读取，减少 PID 复用带来的误归因。
• netlink 快照使用连接唯一键做增量比较，避免每轮重复上报。
• 记录 pid + start_time + boot_id，网络对象记录 namespace 和五元组。
• 对读取失败分类为目标退出、权限不足、格式异常和 IO 错误，不能统一吞掉。

7. 能力探测和降级信息应该怎样上报？

简洁答案：上报的是“当前覆盖范围和证据边界”，不是一长串原始错误日志。服务端需要知道哪类事件可采、使用什么来源、从什么时候开始降级、预计损失是什么。

建议字段：

字段	含义
capability	process_exec、network_connect、file_write 等能力
state	available、degraded、unavailable
source	ebpf、auditd、procfs、netlink
reason	机器可读的失败原因
since	当前状态开始时间
coverage	实时、快照、部分字段或不可用
agent_version	便于关联版本和回滚

Go 落地思路：

• 能力事件和业务安全事件共用传输链路，但使用不同类型和优先级。
• 启动时发送完整快照，状态变化时发送增量事件，周期性发送心跳摘要。
• 失败原因用有限枚举，原始错误放受限诊断字段，避免把内核日志无限上传。

8. 客户说“Agent 没有报攻击”，如何快速定位？

简洁答案：先确认攻击行为是否真实发生，再检查对应能力是否可用，最后核对事件是否采到、是否标准化、是否进队列、是否上报和是否被规则降噪。不要先改规则阈值。

排查顺序：

确认客户复现动作
  -> 查看能力快照与降级时间线
  -> 查看采集器心跳、错误和丢弃计数
  -> 查看原始事件是否产生
  -> 查看标准化和规则命中原因
  -> 查看队列、上报、ACK 与服务端入库

关键知识点：

• 没有告警可能是未采到、采到但解析失败、采到但上报失败，或者规则确实未命中。
• 若能力不可用，正确结论是“当前证据不足”，不是强行承诺“没有攻击”。
• POC 和白盒测试要记录能力前置条件，否则不同机器的结果无法比较。
• 线上修复优先恢复采集能力，再评估规则是否需要调整。

Go 落地思路：

• 诊断包包含能力快照、状态转换、采集器指标、版本、内核信息和脱敏样本。
• 每类事件保留从采集到上报的计数链路，方便定位在哪一层减少。
• 将客户复现样本离线 replay，避免直接在生产机上反复执行高风险动作。

通俗答案

可以把 Agent 想成一组传感器，而不是一个万能摄像头。eBPF 像实时传感器，procfs 和 netlink 更像定时巡检，auditd 依赖系统审计配置；它们看到的范围、延迟和字段都不同。

所以 Agent 的正确行为是：

1. 启动时说明哪些传感器能工作。
2. 运行中发现传感器失效时，切换到可用的后备路径。
3. 明确告诉服务端哪些时间段、哪些事件类型存在覆盖缺口。
4. 不把“没看到”误写成“没发生”。

Go 落地要点

• 用 available/degraded/unavailable 三态表达能力，不用布尔值掩盖边界。
• 每个采集器独立失败和恢复，避免一个探针拖垮整个 Agent。
• 记录能力状态、来源、原因、覆盖范围和时间区间。
• 降级采集器必须标注证据强度，规则层据此调整置信度。
• 采集、标准化、队列和上报分别计数，排障才有闭环。
• 失败重试要有退避和上限；持续失败时优先保护主机资源。

学习要点

方向	需要掌握
Linux 能力	eBPF、BTF、auditd、procfs、netlink、namespace、lockdown
采集设计	探测、心跳、状态转换、降级、恢复、覆盖范围
Go 工程	context、goroutine 生命周期、退避重试、原子计数、结构化错误
数据质量	原始事件、标准化事件、丢弃数、解析失败、上报 ACK
安全判断	能力不足不等于安全，证据缺失要降低结论置信度
线上排障	能力快照、版本关联、诊断包、脱敏样本、离线 replay

小练习/复盘题

1. 设计一个 Capability 结构，要求能表达来源、状态、失败原因、覆盖范围和状态开始时间。
2. eBPF exec 探针加载失败，但 auditd 可用时，你会如何生成进程执行事件并标记证据缺口？
3. 为什么“连续 10 分钟没有进程事件”不能直接说明主机没有执行命令？
4. 设计三个指标，分别判断采集器失效、事件被丢弃和上报链路阻塞。
5. 客户主机启用了 Linux lockdown，Agent 仍要提供最小进程和网络覆盖，你会选择哪些降级路径？
6. 如何避免能力降级本身制造告警风暴？请写出状态去重键和恢复条件。