无解的博客

Appearance

wxvirus2026-07-06
1904
7m

Go 主机安全面试：procfs 进程画像与异常行为识别 ​

Linux 主机安全面试经常会问：Agent 不上 eBPF 时，怎样低成本拿到进程上下文？/proc 是最常见的答案。Go 研发要能说清楚 procfs 能提供什么、哪些字段不可信、怎样控制扫描开销，以及如何把进程画像用于异常行为识别。

岗位场景 ​

text
Linux 主机
  -> /proc/<pid> 读取进程元数据
  -> 解析 exe / cmdline / environ / status / fd / net
  -> 补全用户、父进程、容器、网络连接
  -> 生成进程画像
  -> 检测异常命令、可疑解释器、隐藏进程、敏感文件访问

procfs 适合做轻量巡检和上下文补全，但它不是万能采集器。面试重点通常在“能不能稳定读、能不能解释行为、能不能避免拖垮主机”。

高频面试题 ​

1. procfs 能为 HIDS/EDR 提供哪些进程字段？ ​

简答：提供进程身份、启动参数、父子关系、可执行文件、权限、文件句柄和部分网络上下文。

关键知识点：

  • /proc/<pid>/cmdline：启动参数，字段用 \0 分隔。
  • /proc/<pid>/exe：可执行文件软链接，可用于识别临时目录执行、文件被删除后仍运行。
  • /proc/<pid>/status：PPid、Uid、Gid、线程数、能力位等状态。
  • /proc/<pid>/fd/：打开的文件、socket、pipe，能补充敏感文件访问证据。
  • /proc/<pid>/environ：环境变量，可能包含代理、动态库注入、敏感凭据痕迹。

Go 落地要点：

  • 用 os.ReadDir("/proc") 枚举纯数字目录。
  • 读取失败要当正常情况处理，因为进程可能刚退出。
  • 对 cmdline 这种 NUL 分隔内容，用 bytes.Split 或 strings.ReplaceAll 清洗，不要按普通文本行解析。
go
func parseCmdline(raw []byte) []string {
	raw = bytes.TrimRight(raw, "\x00")
	if len(raw) == 0 {
		return nil
	}
	parts := bytes.Split(raw, []byte{0})
	args := make([]string, 0, len(parts))
	for _, p := range parts {
		args = append(args, string(p))
	}
	return args
}

2. 为什么读取 /proc/<pid> 经常失败？应该怎么处理？ ​

简答：进程生命周期很短，枚举时存在、读取时可能已经退出；安全 Agent 应该容忍这种竞争。

关键知识点：

  • ENOENT：进程退出或文件瞬时不存在。
  • EACCES：权限不足，尤其是跨用户或开启 hidepid 时。
  • 软链接读取失败：exe、cwd、root 可能被权限或命名空间影响。
  • 容器场景下，宿主机视角和容器视角的 PID 可能不同。

Go 落地要点：

  • 单个 PID 读取失败不要中断整轮扫描。
  • 记录失败类型用于健康度观测，但不要把所有失败都打成告警。
  • 每个文件设置小而固定的读取上限，避免异常大内容拖慢 Agent。

3. 如何用 procfs 识别“可执行文件已删除但进程仍在运行”？ ​

简答：读取 /proc/<pid>/exe 软链接，如果目标路径带 (deleted)，说明磁盘文件已经被删除但进程还在。

关键知识点：

  • 攻击者可能运行临时文件后删除落地文件，降低取证难度。
  • 正常升级、热更新也可能出现 deleted exe，不能单独判定为攻击。
  • 要结合路径、父进程、命令行、用户、网络外连和哈希证据综合判断。

Go 落地要点：

  • 用 os.Readlink 读取 exe。
  • 对 /tmp、/dev/shm、Web 上传目录下的 deleted exe 提高风险分。
  • 如果能读取 /proc/<pid>/fd，保留可疑文件句柄证据。

4. procfs 如何辅助发现反弹 Shell 或可疑解释器？ ​

简答：看进程名、命令行、父进程、tty、网络 socket 和工作目录的组合，而不是只匹配 bash。

关键知识点：

  • 可疑解释器：sh、bash、python、perl、php、node、nc、socat。
  • 可疑父进程：nginx、apache、php-fpm、tomcat、java 等 Web 服务拉起 shell。
  • 可疑网络：进程持有外连 socket，目标为非常规公网 IP 或高危端口。
  • 可疑环境：工作目录在 Web 目录、临时目录，或者没有交互式 tty。

Go 落地要点：

  • 先生成进程快照，再做规则判断，避免检测逻辑散落在采集代码里。
  • 规则输出要带证据字段：pid、ppid、exe、cmdline、cwd、uid、remote_addr。
  • 网络 socket 从 /proc/<pid>/fd 关联 inode，再查 /proc/net/tcp，实现成本比 eBPF 低，但实时性更弱。

5. 进程画像里哪些字段不能完全信任？ ​

简答：命令行、环境变量、进程名都可能被伪装；安全判断要依赖多源证据。

关键知识点：

  • 进程名可以通过 prctl 或程序自身行为修改。
  • cmdline 可能被覆盖，也可能为空。
  • environ 可能包含敏感信息，采集要最小化并做脱敏。
  • /proc 视图可能受权限、容器命名空间、内核配置影响。

Go 落地要点：

  • 把字段分为“身份字段”和“证据字段”，不要用单字段直接定罪。
  • 对敏感字段做白名单采集，例如只提取 LD_PRELOAD、LD_LIBRARY_PATH、代理变量。
  • 上报前限制长度，避免命令行或环境变量造成带宽和存储膨胀。

6. 如何控制 procfs 扫描的性能开销？ ​

简答：降低扫描频率、限制字段读取、缓存稳定字段，并把慢路径放到命中可疑条件之后。

关键知识点：

  • 全量扫描 /proc 是 O(进程数)，高频执行会影响 CPU 和 IO。
  • cmdline、status 成本低，fd、environ、网络 inode 关联成本更高。
  • 进程创建时间可作为缓存 key 的一部分，避免 PID 复用导致误关联。
  • 大规模主机上要做限速和超时，不能为了安全检测拖垮业务。

Go 落地要点：

  • 第一层只读取 status、cmdline、exe。
  • 命中可疑父进程、可疑路径、可疑命令后，再读取 fd 和网络信息。
  • 用 context.Context 控制整轮扫描预算，超时后下轮再补，不阻塞 Agent 主循环。

7. procfs 和 eBPF 在主机安全里怎么分工？ ​

简答：eBPF 更适合实时事件，procfs 更适合快照巡检和上下文补全。

关键知识点：

  • eBPF 能捕获短生命周期事件，比如瞬时 execve 或 connect。
  • procfs 只能看到“读取时仍存在”的状态，容易漏掉短进程。
  • procfs 部署门槛低，不依赖内核探针加载权限。
  • 两者结合时，eBPF 负责事件触发，procfs 负责补字段和复核当前状态。

Go 落地要点：

  • 事件驱动路径：收到 exec/connect 事件后，按 PID 读取 procfs 补上下文。
  • 巡检路径：定时扫描长时间运行的异常进程、deleted exe、敏感 fd。
  • 统一输出结构，避免 eBPF 事件和 procfs 快照各写一套字段。

学习要点 ​

  • procfs 是 Linux 主机安全 Agent 的基础能力，重点是稳定读取和字段解释。
  • 检测异常进程要看组合证据：父子关系、命令行、路径、用户、网络和文件句柄。
  • 读取失败、字段为空、PID 复用都是正常工程问题，不能写成脆弱逻辑。
  • 低成本扫描先拿关键字段，高成本补证据放在可疑命中之后。

小练习 ​

  1. 写一个 Go 函数，枚举 /proc 下所有数字 PID，并读取 cmdline、exe、status。
  2. 给进程画像结构体增加 RiskHints []string，标记 deleted exe、临时目录执行、Web 父进程拉起 shell。
  3. 设计一个规则：php-fpm -> sh/bash -> 外连 socket，列出需要哪些 procfs 字段才能输出可解释告警。
  4. 思考一个误报场景：正常发布或热更新为什么也可能出现 (deleted)？你会加哪些条件降噪？
最近更新