Go 主机安全面试：Linux 原始套接字与混杂模式滥用检测

Linux 主机上的抓包能力既能被运维、网络监控和故障排查正常使用，也能被入侵者用来窃取明文凭据、观察横向移动流量，或者配合 ARP 欺骗扩大影响范围。仅凭“进程打开了 Raw Socket”就告警，会把 tcpdump、网络探针和部分 DHCP 客户端全部打成风险；完全不采集，又会留下明显的主机侧盲区。

这组题重点考察 AF_PACKET、CAP_NET_RAW、混杂模式、network namespace、/proc/net/packet、进程归因和误报治理。回答时要分清“能收包”“能发包”“能看到其他主机流量”和“已经实施攻击”是四件不同的事。

岗位场景

Web 服务或容器被利用
  -> 攻击者获得可创建 AF_PACKET 套接字的权限
  -> 打开 SOCK_RAW/SOCK_DGRAM，绑定网卡或启用混杂模式
  -> 观察同网段、宿主机或容器网络中的协议与凭据
  -> 进一步发送伪造帧、修改邻居关系或外传收集到的数据
  -> Go Agent 关联 socket/bind/setsockopt、进程身份、网卡和后续行为
  -> 输出“谁在什么网络命名空间抓什么，证据和缺口分别是什么”

原始套接字本身是能力，不是结论。主机安全产品要把低层网络能力放进进程来源、权限、命名空间和攻击链中判断。

高频面试题

1. AF_PACKET 套接字和普通 TCP/UDP 套接字、AF_INET/SOCK_RAW 有什么区别？

简洁答案： 普通 TCP/UDP 套接字处理传输层数据；AF_INET/SOCK_RAW 让进程直接构造 IP 层报文；AF_PACKET 工作在链路层，能看到或发送带链路层头部的帧。安全检测中通常说的“抓包 socket”是 AF_PACKET。

关键知识点：

• AF_PACKET 的 SOCK_RAW 保留链路层头部，SOCK_DGRAM 会在收包时去掉链路层头部。[1]
• AF_PACKET 可以接收所有协议，也可以绑定到指定接口；它不是普通的“监听端口”服务。
• AF_INET/SOCK_RAW 和 AF_PACKET 的权限、可见范围、协议字段都不同，不能只按 SOCK_RAW 这个类型合并。
• /proc/net/raw 和 /proc/net/packet 描述的是不同对象，排查时不要看错文件。

Go 落地思路： 事件至少保留 family、socket_type、protocol、ifindex 和 netns。只存一个 raw=true 布尔值，后续既难区分是抓包还是手工构造 IP 包，也无法做精确基线。

2. 创建 AF_PACKET 套接字需要什么权限？混杂模式又意味着什么？

简洁答案： 创建 packet socket 需要进程所在 network namespace 对应的用户命名空间中具备 CAP_NET_RAW。混杂模式是让网卡接收并非发给本机 MAC 的帧，通常通过 PACKET_ADD_MEMBERSHIP + PACKET_MR_PROMISC 为某个 socket 增加成员关系；它扩大了可见范围，但不等于攻击者已经能控制流量。

关键知识点：

• packet(7) 明确要求创建 packet socket 的进程拥有 CAP_NET_RAW。[1]
• CAP_NET_RAW 同时允许使用 RAW/PACKET socket；ip link set ... promisc on 走的是网络管理路径，通常需要 CAP_NET_ADMIN，两种操作不能混为一谈。[2]
• PACKET_MR_PROMISC、PACKET_MR_ALLMULTI 和普通 BPF 过滤器的效果不同。过滤器减少拷贝，不自动扩大收包范围。
• 混杂模式按接口生效，并可能被多个使用者共同引用；不能因为当前进程关闭 socket 就认定接口立即退出混杂状态。
• 每个 network namespace 有自己的网卡和 packet socket 视图。容器里的 eth0 不是宿主机物理网卡。

Go 落地思路： 检测事件要同时表达“打开能力”和“扩大范围”两个阶段：packet_socket_opened、packet_promisc_enabled、packet_bound。把两者合成一个 raw_socket=true 字段，会丢掉最关键的风险差异。

3. /proc/net/packet 能告诉我们什么？不能告诉我们什么？

简洁答案： 它能列出当前 network namespace 中存活的 packet socket，包含引用数、socket 类型、协议、接口索引、运行标志、接收内存、UID 和 inode；它不直接给出 PID、进程名、命令行，也不显示这个 socket 是否启用了混杂模式。

关键知识点：

• 当前内核的格式是 sk RefCnt Type Proto Iface R Rmem User Inode。[4]
• Proto 是十六进制展示；Iface 是接口索引，不是接口名；Inode 才能用来连接 /proc/<pid>/fd。
• 读取 /proc/<pid>/net/packet 看到的是该进程所属 network namespace 的视图，不是宿主机全局视图。
• 该文件是快照，短命 socket、关闭后的复用和扫描期间的竞态都会影响结论。
• PACKET_MR_PROMISC 是一个 socket membership，不能只靠这个 procfs 文件判断网卡当前是否处于混杂模式。

Go 落地思路： 用标准库按行解析，先跳过表头，再校验固定字段数量。不要把 Iface 直接当网卡名，也不要把 Proto 当十进制数。

type PacketSocket struct {
	RefCount uint64
	Type     int
	Protocol uint16
	IfIndex  int
	Running  bool
	Rmem     uint64
	UID      uint32
	Inode    uint64
}

func parsePacketSockets(r io.Reader) ([]PacketSocket, error) {
	sc := bufio.NewScanner(r)
	if !sc.Scan() {
		return nil, sc.Err()
	}

	var out []PacketSocket
	for sc.Scan() {
		f := strings.Fields(sc.Text())
		if len(f) < 9 {
			return nil, fmt.Errorf("packet row has %d fields", len(f))
		}
		ref, err := strconv.ParseUint(f[1], 10, 64)
		if err != nil {
			return nil, err
		}
		typ, err := strconv.Atoi(f[2])
		if err != nil {
			return nil, err
		}
		proto, err := strconv.ParseUint(f[3], 16, 16)
		if err != nil {
			return nil, err
		}
		ifindex, err := strconv.Atoi(f[4])
		if err != nil {
			return nil, err
		}
		rmem, err := strconv.ParseUint(f[6], 10, 64)
		if err != nil {
			return nil, err
		}
		uid, err := strconv.ParseUint(f[7], 10, 32)
		if err != nil {
			return nil, err
		}
		inode, err := strconv.ParseUint(f[8], 10, 64)
		if err != nil {
			return nil, err
		}
		out = append(out, PacketSocket{
			RefCount: ref,
			Type:     typ,
			Protocol: uint16(proto),
			IfIndex:  ifindex,
			Running:  f[5] == "1",
			Rmem:     rmem,
			UID:      uint32(uid),
			Inode:    inode,
		})
	}
	return out, sc.Err()
}

代码只读元数据，不读取包内容；生产实现还要限制单次行数、记录解析失败，并标明读取的是哪个 netns。

4. 如何把 packet socket 准确归因到进程？为什么只用 PID 不够？

简洁答案： 优先从 socket、bind、setsockopt 事件直接拿 PID/TGID 和进程启动时间；快照场景再用 socket inode 扫描 /proc/<pid>/fd 补齐。PID 会复用，fd 会被继承，socket inode 也会在关闭后复用，必须同时保存进程实例和 network namespace。

关键知识点：

• /proc/<pid>/fd 中的 socket 常显示为 socket:[inode]，可用于从 inode 反查候选进程。[5]
• 同一个 socket 可能被 fork 后共享，因此 inode 与进程不是一一对应。
• 进程在扫描前退出、fd 不可读、hidepid、Yama/安全策略和容器权限都会造成归因失败。
• PID 必须搭配 /proc/<pid>/stat 的 starttime，最好再加 boot_id 和 netns 作为进程实例键。[6]
• 归因结果要区分“事件确认”和“快照推断”，不能把 procfs 快照当成实时发生顺序。

Go 落地思路： 统一使用进程实例键，而不是裸 PID：

type ProcessRef struct {
	PID       uint32
	StartTime uint64
	BootID    string
	NetNS     uint64
}

type PacketSocketRef struct {
	BootID    string
	NetNS     uint64
	IfIndex   int
	Protocol  uint16
	SocketType int
	Inode     uint64
}

事件里保留 attribution=event|procfs|unknown。快照缺失不是“没有抓包”，只是“当前没有观察到”。

5. Go Agent 应如何采集 AF_PACKET 与混杂模式，而不把事件量打爆？

简洁答案： 用 eBPF 或审计事件采集 socket 的系统调用入口和返回值，再采集 bind、setsockopt 的关键参数；用户态只做轻量过滤、聚合和归因。procfs 快照作为降级和对账，不应高频全量扫描。

关键知识点：

• socket(AF_PACKET, SOCK_RAW|SOCK_DGRAM, htons(ETH_P_ALL)) 的入口事件只能证明“尝试”，必须看返回 fd 才能确认成功。
• bind 的 sockaddr_ll 能给出协议和接口索引；setsockopt(SOL_PACKET, PACKET_ADD_MEMBERSHIP, ...) 才可能体现混杂模式启用。
• 用户指针不能无界复制。读取 packet_mreq 时应限制结构长度并校验 mr_type、mr_ifindex。
• eBPF 关闭、内核版本不支持、容器权限不足时，要显式降级到 auditd 或 procfs，并上报能力状态。
• 不要把每个 recvfrom 或每个数据包都上报；主机安全缺的是“谁获得了抓包能力”，而不是复制一份网络流量。

Go 落地思路： 事件模型按阶段拆开，便于回放和排查：

packet.socket.attempt
packet.socket.opened
packet.bind.success
packet.promisc.enabled
packet.sendto.attempt
packet.socket.closed

同一 process_instance + netns + inode 在短窗口内聚合，输出首次时间、最后时间、接口集合、协议集合和失败次数。对内核事件丢失、fd 不可读、netns 未覆盖分别打独立指标。

6. 出现 packet socket 就告警，为什么误报会很高？哪些组合更有价值？

简洁答案： packet socket 是 tcpdump、网络性能探针、DHCP 客户端、虚拟化和容器网络组件的正常工作方式。更有价值的是：非预期进程获得能力、启用混杂模式、长期观察宿主机上行流量，并伴随伪造帧发送、邻居变化、异常子进程或敏感文件访问。

关键知识点：

• 仅“能收包”不等于“能收到其他主机的包”；是否扩大范围取决于接口、混杂模式、网络拓扑和命名空间位置。
• SOCK_RAW packet socket 也能发送任意链路层帧，风险高于只读监控；但发送动作需要单独采集，不能从 socket 类型推断。
• 正常网络探针通常有明确二进制路径、包管理归属、服务单元、固定接口和长期稳定性。
• Web worker、临时目录程序、已删除可执行文件、脚本解释器子进程突然创建 packet socket，风险明显更高。
• 容器中保留 CAP_NET_RAW 并不罕见，是否异常要结合该容器的安全策略、业务角色和实际网卡范围。[3]

Go 落地思路： 告警输出证据组合，而不是单一分数：

packet_socket_from_unexpected_process
+ promiscuous_mode_enabled
+ interface_is_host_uplink
+ long_lived_capture
+ packet_send_observed
+ neighbor_or_arp_change
+ child_shell_or_temp_binary

“临时目录进程 + 宿主机上行网卡 + 混杂模式 + 持续抓包”通常比“进程名不是 tcpdump”可靠。

7. 如何降低抓包检测的误报，同时避免用进程名做脆弱白名单？

简洁答案： 用可验证的主体特征做基线：可执行文件 inode/hash、包管理归属、签名或受控路径、服务单元、父进程、netns、接口和持续时间；再结合管理员变更或工单。进程名和命令行只能作为辅助证据。

关键知识点：

• 二进制改名、脚本包装、exec -a 和临时复制都能伪造进程名，不能单靠 comm= tcpdump 放行。
• 以可执行文件 hash 做长期白名单也会误伤正常升级，需要把版本、包来源和变更事件一起考虑。
• 基线应按主机角色区分：网络探针节点允许持续抓包，普通 Web 节点不应默认允许。
• 对短期排障抓包，最好有开始/结束时间、目标接口和操作者信息；没有审批信息时只能降低优先级，不能直接删除证据。
• 对混杂模式应做状态差分：记录启用前后接口索引、IFF_PROMISC 线索和 socket 关闭，避免把持续状态每秒重复告警。

Go 落地思路： 规则先生成 entity + behavior + scope，再由策略层决定抑制。比如同一二进制 hash、同一服务单元、同一接口的已知网络探针，可在限定时间窗内静默；临时目录中的同 hash 程序仍应重新评估，因为父进程和运行位置已经变化。

8. 主机侧是否应该采集抓到的数据包？性能与隐私如何权衡？

简洁答案： 默认不采集 payload。先采集 socket 元数据、进程身份、接口、协议、持续时间和发送行为；只有在明确授权、确有取证需求且已评估隐私和容量后，才对特定接口、特定五元组和有限时长做最小化抓包。

关键知识点：

• 主机上可能有密码、令牌、业务请求、数据库语句和个人信息，抓包会把敏感数据复制到 Agent 缓冲区和上传链路。
• 混杂模式和大缓冲区会增加内核与用户态内存压力；高频包还可能挤占 exec、file、network 等关键安全事件。
• 内核过滤器能减少拷贝，但不能替代采集授权和保留期限。
• 用户态排队应采用有界队列、采样和聚合；队列满时要记录丢包类别，而不是静默覆盖。
• 证据链要能证明“观察到了抓包能力”和“实际采集量”，不要用完整 payload 才能成立告警。

Go 落地思路： 把 payload 采集设计成独立的受控能力，而不是默认规则动作。事件上报只带 capture_requested、filter_hash、duration、bytes_observed 等元数据；原始数据应有单独加密、访问审计和过期删除策略。

9. 客户反馈“原始套接字告警是误报”或“抓包没有检测到”，怎么排查？

简洁答案： 先确认告警指向的是 packet socket、IP raw socket 还是普通监听端口，再核对进程实例、network namespace、接口和能力状态；漏报则依次检查采集阶段、过滤条件、返回值和事件丢失。

排查顺序：

1. 用进程实例而不是裸 PID 定位 /proc/<pid>/exe、cmdline、父进程、UID、cgroup、启动时间和包归属。
2. 在授权范围内检查 /proc/<pid>/net/packet 与 /proc/<pid>/fd/*，确认 packet socket 的 inode、类型、协议和接口索引。[4][5]
3. 检查进程是否具备 CAP_NET_RAW，是否位于容器 netns，接口是否为 veth/lo/宿主机上行口；不要跨 namespace 比较接口索引。
4. 查看 PACKET_ADD_MEMBERSHIP、bind 和 setsockopt 事件是否存在；只有 socket() 成功不等于启用了混杂模式。
5. 检查 eBPF/auditd 规则是否只过滤了 SOCK_RAW 而漏掉 SOCK_DGRAM，是否只记录入口没有记录返回值。
6. 检查 ring buffer drop、用户态队列丢弃、权限不足、fd 扫描失败和能力降级指标。
7. 用同一份回放样本分别验证“tcpdump 正常抓包”“容器内无 NET_RAW”“socket 创建失败”“成功创建但未绑定”“成功启用混杂模式”，确认规则结论不同。

Go 落地思路： 告警详情拆成“观测事实”“归因结果”“风险推断”和“采集缺口”。例如没有看到 PACKET_MR_PROMISC 事件时，应写“未观察到混杂模式事件”，不能写“没有启用混杂模式”。

Go 实现要点

一条最小可用的检测链可以按下面分层：

1. 采集层： 采集 packet socket 创建、绑定、成员关系、发送和关闭事件，保存 family、type、protocol、ifindex、netns、返回值及进程实例。
2. 归因层： 事件优先；快照用 inode 扫描 fd 补齐。明确标记 event、procfs、unknown 三种归因来源。
3. 标准化层： 把 AF_PACKET/SOCK_RAW 与 AF_INET/SOCK_RAW 分开，把“创建成功”和“混杂模式启用成功”分开，把“接收能力”和“发送动作”分开。
4. 检测层： 按主机角色、二进制来源、父进程、netns、接口、持续时间和后续行为评分；不要把 tcpdump 这个名字当成唯一白名单。
5. 治理层： 做有界聚合、短期抑制、能力状态上报和覆盖率指标；默认不采集 payload，确需取证时走独立授权链路。

一个实用的事件结构可以是：

type PacketEvent struct {
	At          time.Time
	Phase       string
	Process     ProcessRef
	Family      uint16
	SocketType  int
	Protocol    uint16
	IfIndex     int
	Inode       uint64
	ReturnCode  int32
	Source      string // ebpf、auditd、procfs
	NetNS       uint64
	LostFields  []string
}

规则层应把 Source 和 LostFields 带入告警。同一条行为由 eBPF 实时事件确认，和由 procfs 快照推断，证据强度不同。

学习要点

方向	需要掌握
网络基础	AF_PACKET、SOCK_RAW、SOCK_DGRAM、链路层与 IP 层、ETH_P_ALL
权限与隔离	CAP_NET_RAW、CAP_NET_ADMIN、network namespace、容器 capability
抓包范围	绑定接口、混杂模式、multicast、BPF 过滤器、veth 与物理网卡差异
可观测性	socket/bind/setsockopt、/proc/net/packet、/proc/<pid>/fd、eBPF/auditd
归因准确性	PID 复用、starttime、socket inode、fd 继承、namespace 视图
检测治理	进程来源、二进制基线、接口范围、持续时间、发送行为、告警聚合
隐私与性能	最小化采集、内核过滤、有界队列、payload 授权和保留期限

小练习 / 复盘题

1. 设计一个事件模型，能区分 AF_PACKET、AF_INET/SOCK_RAW、普通 TCP 监听和只有 socket() 失败尝试四种情况。
2. 为什么 /proc/net/packet 里看不到混杂模式开关？还需要采集什么事件或状态来补证？
3. 同一条告警中，容器内 eth0 与宿主机 eth0 的 ifindex 都是 2，应该怎样避免错误关联？
4. 写出从 packet socket inode 到进程实例的关联步骤，并列出至少三个可能的失败条件。
5. 为“tcpdump 正常抓包”和“Web worker 子进程在临时目录长期抓包”设计不同的基线策略。
6. 如果只能使用 procfs、不能使用 eBPF/auditd，你会如何限制扫描开销并声明覆盖缺口？
7. 设计一条“启用混杂模式后出现异常 ARP 行为”的规则，说明哪些事实是观测到的，哪些只是推断。
8. 设计四个回放样本：正常网络探针、仅创建失败、成功抓包但未启用混杂模式、长期混杂抓包，断言规则输出不同。

参考资料

1. Linux man-pages：packet(7)
2. Linux man-pages：capabilities(7)
3. Linux man-pages：ip-link(8)
4. Linux 内核源码：net/packet/af_packet.c
5. Linux man-pages：proc_pid_fd(5)
6. Linux man-pages：proc_pid_stat(5)