Go 主机安全面试：Linux C2 Beacon 周期性外联检测

主机被植入后门或木马后，不一定马上出现反弹 shell、下载 payload 或大量扫描。很多 C2 通信会伪装成低频 HTTP、HTTPS、DNS 或 TCP 心跳：每隔几十秒、几分钟甚至更长时间连接一次控制端，获取任务、回传状态，再等待下一轮指令。面试官常会追问：周期性外联为什么可疑？怎样区分正常 Agent 心跳和 C2 Beacon？Go 侧如何在不保存海量连接明细的情况下做实时检测？

岗位场景

Linux 主机
  -> 采集进程启动、网络连接、DNS、用户、容器和主机角色
  -> 识别低频、周期性、带 jitter 的可疑外联
  -> 关联可疑进程来源、落地路径、父进程、命令行和后续执行动作
  -> 区分监控 Agent、业务 SDK、长连接客户端、定时任务和恶意 C2
  -> 输出可解释的时间序列证据与降噪依据

这类题考的是网络行为建模、时间窗口统计、进程归因、误报治理、攻击链还原，以及 Go Agent 的流式聚合和资源控制能力。

高频面试题

1. 什么是 C2 Beacon，为什么主机侧要检测它？

简洁答案：C2 Beacon 是被控端周期性连接控制端获取命令或上报状态的通信行为。它通常流量小、频率低、协议正常，边界流量设备不一定能直接判断恶意，主机侧能补上“哪个进程在连、从哪里启动、之前发生过什么”。

关键知识点：

• C2 不一定表现为持续交互式连接，更多时候是短连接心跳。
• Beacon 常有固定周期，也可能加入 jitter，让间隔在一个范围内轻微波动。
• 单次访问公网 IP 不一定异常，但同一进程稳定访问陌生目标更值得关注。
• 主机侧能看到进程路径、用户、父进程、cwd、容器、落地文件和执行链。
• 检测目标不是替代流量分析，而是把网络模式和主机行为合并成证据链。

Go 落地思路：

• 将网络事件标准化为 process_key + dst + protocol + timestamp。
• 对同一进程和目标维护短期时间序列，只保存摘要，不保存无限明细。
• 告警要描述“周期、抖动、进程来源、目标信誉、前序行为”，不要只写“周期性连接”。

2. Beacon 和正常心跳有什么区别？

简洁答案：正常心跳通常来自已知组件、固定路径、固定用户、明确域名和可解释业务；恶意 Beacon 更常来自临时目录、异常父进程、未知二进制、可疑解释器、陌生公网目标，并伴随下载、提权、凭据访问或持久化线索。

关键知识点：

维度	正常心跳	可疑 Beacon
进程身份	已知 Agent、业务程序	临时目录文件、解释器、未知路径
目标	固定域名、厂商网段	新注册域名、裸 IP、非常规端口
周期	文档可解释，监控可见	固定或带 jitter，业务无解释
上下文	服务启动链正常	Web RCE、落地执行、账号异常后出现
处置	降权或白名单审计	关联为攻击链证据

Go 落地思路：

• 白名单绑定 process_path + hash/signature + user + dst_domain + host_role。
• 对没有进程归因的网络事件先降级，不要直接高危。
• 对命中白名单的连接也保留低成本计数，方便后续基线漂移分析。

3. 如何用时间间隔识别周期性外联？

简洁答案：对同一聚合键记录最近若干次连接时间，计算相邻间隔的均值、方差和命中次数。间隔稳定、次数足够、目标可疑且主体异常时，再提高风险等级。

关键知识点：

• 至少需要 4 到 6 次连接才能比较稳地判断周期性。
• 固定 60 秒、300 秒很可疑，但攻击者会加入 10% 到 30% jitter。
• 检测不要只看“完全相等的间隔”，要允许合理误差范围。
• 高频业务轮询、监控上报、NTP、DNS、消息队列客户端都可能周期性外联。
• 周期性只是行为特征，必须和进程、目标和主机上下文组合。

Go 落地思路：

func intervalStats(ts []int64) (avg, maxDeviation int64) {
	if len(ts) < 3 {
		return 0, 0
	}
	intervals := make([]int64, 0, len(ts)-1)
	for i := 1; i < len(ts); i++ {
		intervals = append(intervals, ts[i]-ts[i-1])
		avg += ts[i] - ts[i-1]
	}
	avg /= int64(len(intervals))
	for _, d := range intervals {
		if diff := abs64(d - avg); diff > maxDeviation {
			maxDeviation = diff
		}
	}
	return avg, maxDeviation
}

func abs64(v int64) int64 {
	if v < 0 {
		return -v
	}
	return v
}

• 热路径里只保留最近 N 个时间戳，例如 8 到 16 个。
• 判断时使用相对偏差，例如 maxDeviation <= avg/3。
• abs64 这类小函数单独测试，避免边界值导致规则抖动。

4. Beacon 检测需要采集哪些字段？

简洁答案：至少需要进程键、网络目标、时间戳、用户和主机上下文；如果要减少误报，还需要父进程、命令行、进程路径、文件来源、DNS 域名、容器信息和目标信誉。

关键字段：

• 进程：pid、start_time、ppid、exe、argv、uid、cwd。
• 网络：dst_ip、dst_port、protocol、direction、bytes_out、duration。
• DNS：查询域名、解析结果、TTL、是否首次出现。
• 文件：进程文件路径、inode、hash、是否来自临时目录或下载目录。
• 上下文：主机角色、容器 ID、运行用户、资产分组、维护窗口。

Go 落地思路：

type BeaconKey struct {
	HostID     string
	ProcessID int
	StartTime uint64
	Dst       string
	Port      uint16
	Protocol  string
}

type BeaconWindow struct {
	LastSeen []int64
	Reasons  []string
}

• 用 pid + start_time 避免 PID 复用串错事件。
• 对域名和 IP 分开建模：域名能反映 C2 轮换，IP 能反映真实连接。
• 网络事件到达时先做轻量打标，命中候选后再补充 hash、父进程链和 DNS 历史。

5. 如何处理 jitter、长周期和低频样本不足？

简洁答案：不要要求间隔完全固定，也不要在样本很少时给高危结论。可以用分层策略：少量样本先标记观察，多次稳定命中后升为告警，再结合攻击链证据提高严重性。

关键知识点：

• C2 常用 jitter 避免固定周期被简单规则命中。
• 长周期 Beacon 可能一天只出现几次，Agent 端短窗口容易看不出来。
• 服务端更适合做跨小时、跨天的慢速 Beacon 关联。
• 样本不足时高危告警容易伤害客户信任。
• 检测应记录“证据不足但可疑”的候选态，供后续补证。

Go 落地思路：

• Agent 端做 5 到 30 分钟的短窗口实时候选。
• 服务端按 host + process_path + dst 做更长周期聚合。
• 输出分层状态：candidate、suspicious、high_confidence。
• 对候选事件设置 TTL，过期自动清理，避免内存长期增长。

6. 如何把 Beacon 和攻击链上下文关联起来？

简洁答案：看 Beacon 进程之前是否有异常来源，之后是否触发敏感行为。比如 Web 服务拉起临时目录二进制后，它周期性访问公网 IP，并随后读取凭据或写入持久化项，这比孤立网络周期更可信。

常见链路：

T0  php-fpm/java 拉起 sh 或下载器
T1  payload 写入 /tmp/.cache 或 /dev/shm/.x
T2  新进程启动，路径异常或 hash 未知
T3  每 60 到 90 秒访问同一公网目标
T4  拉取命令后执行 whoami、id、uname、cat /etc/passwd
T5  写入 cron/systemd/authorized_keys 或访问云元数据

关键知识点：

• Beacon 是“等待命令”的通信模式，真正危害常在后续动作里体现。
• 父进程、落地路径、执行用户和后续命令能显著提升置信度。
• 告警时间线比单条规则名更利于客户复盘。
• 已有反弹 shell、临时目录执行、凭据访问规则可以作为上下文信号复用。

Go 落地思路：

• 规则引擎内部使用 reason code，例如 periodic_outbound、temp_exec_parent、unknown_binary、post_beacon_command。
• 同一主机同一进程树只聚合成一条攻击链告警，避免多规则刷屏。
• 关联窗口按行为设置：进程和文件通常几分钟，持久化和凭据访问可以更长。

7. 如何降低 Beacon 检测的误报？

简洁答案：误报治理靠精确白名单、资产角色、目标信誉、历史基线和证据分层。不要把所有周期性公网连接都判成 C2。

关键知识点：

• 监控、日志、APM、安全 Agent 都会周期性上报。
• 数据库客户端、消息队列、服务发现、许可证校验也可能固定访问。
• 白名单只按进程名很危险，攻击者可以把二进制命名成 agent 或 update。
• 新上线业务会改变基线，白名单需要过期时间和审批记录。
• 低危候选可以先汇总到风险画像，不一定马上打扰客户。

Go 落地思路：

• 白名单条件至少包含进程路径、hash 或签名、用户、目标域名/网段和主机角色。
• 对命中白名单但行为突然变化的样本保留统计指标，例如目标变化、频率变化。
• 对同一规则使用去重键：host_id + process_hash + dst + period_bucket。
• 调参时用误报样本回放，不要只在生产环境凭感觉改阈值。

8. 如果客户说“这是正常监控心跳”，你怎么排查？

简洁答案：先还原告警证据，看命中原因是否只有周期性；再核对进程身份、安装来源、hash、目标域名、主机角色和上线时间。如果确实是合法心跳，要用有边界的白名单或降权规则收敛，而不是关闭 Beacon 检测。

排查步骤：

1. 查看 reasons：是否只有 periodic_outbound，还是同时命中 unknown_binary、temp_path、web_parent。
2. 核对进程路径、hash、签名、包管理归属和启动方式。
3. 查询目标域名、证书、IP 归属、历史出现时间和访问主机范围。
4. 对比同资产组其他主机是否也有同样心跳。
5. 调整规则：加入精确 allowlist、降低 severity、或要求客户补充业务标签。

Go 落地思路：

• 告警中保存规则版本、窗口统计、样本时间戳和白名单命中详情。
• 支持离线回放同一批网络事件，验证规则调整不会放过真实样本。
• 对客户配置变更记录审计字段，便于后续复盘“为什么当时没报”。

学习要点

• Beacon 检测不是单个 IOC 匹配，而是时间序列、进程上下文和攻击链证据的组合。
• Linux 网络事件需要和进程启动时间、父进程、用户、路径、DNS 解析结果关联。
• jitter、长周期和样本不足会影响判断，要分层输出候选、可疑和高置信告警。
• Go Agent 热路径要控制内存和 CPU：有界窗口、TTL、去重、可疑后补证据。
• 降噪要基于可解释白名单和回放验证，不能只按进程名或固定端口放行。

小练习

1. 设计一个 BeaconKey，说明为什么只用 pid + dst_ip 不够。
2. 给定时间戳 [0, 61, 119, 183, 244, 303]，计算平均间隔和最大偏差，判断是否像带 jitter 的 Beacon。
3. 写一个规则评分表：周期性、未知二进制、临时目录、Web 父进程、目标首次出现分别加多少分？
4. 设计一条白名单，要求同时约束进程路径、hash、用户、目标域名和主机角色。
5. 思考：如果只有服务端网络日志、没有进程信息，Beacon 检测会少哪些关键证据？