2. 流量采集点与采集策略设计
流量取证的第一道工程决策不是“用什么工具分析”，而是“在哪里把包拿到手”。采集点选错，后续再强的协议解析和关联分析都会受限于证据本身的完整性与可信度。本节围绕交换机镜像、TAP、主机抓包、虚拟化与云环境采集、无线流量采集五类典型位置，说明其适用场景，以及采集位置如何影响证据的完整性和可分析性。
一、采集位置决定“能看到什么”
同一段通信，在不同位置被捕获，得到的报文集合并不相同。核心差异来自三点：可见范围（能否看到全部会话）、丢包风险（高负载下是否漏包）、证据属性（是否可被篡改、时间戳是否可信）。
- 交换机镜像（SPAN）：把指定端口或VLAN的流量复制到监控口。优点是零侵入、无需断开链路，适合办公网、服务器区日常取证与临时排查。缺点是镜像口本身可能因带宽超限而丢包，且交换机内部转发的部分异常流量（如某些硬件丢弃）未必被镜像。
- 网络TAP：在链路中串接无源或有源分光器，把流量按比例复制给分析设备。优点是全量、线速、不丢包，且不依赖交换机CPU，证据完整性最好，适合核心链路、出口链路和需要长期取证的场景。缺点是需要中断链路施工，成本较高。
- 主机抓包：在终端或服务器上用tcpdump、Wireshark、pcap库直接抓取本机网卡流量。优点是能看到本机进程级上下文，适合主机失陷取证、恶意进程外联分析。缺点是只能看到本机视角，且抓包进程本身可能被攻击者发现或终止。
- 虚拟化与云环境采集：在Hypervisor虚拟交换机、vSwitch端口镜像、云厂商流量镜像或VPC流日志中采集。优点是覆盖东西向流量，适合云主机横向移动分析。缺点是部分云平台只提供流日志而非原始包，且镜像策略受平台能力限制。
- 无线流量采集：通过无线网卡监听模式或AP镜像采集空口帧。优点是能捕获未加密的管理帧、探测请求和关联过程，适合无线入侵与非法AP取证。缺点是空口共享介质、信道干扰大，且加密流量需配合密钥才能解密。
二、采集策略设计：从场景反推采集点
实际工程中，采集策略不是“选一个最好的点”，而是根据取证目标组合多个采集点。以下给出一个可参考的决策表，用于快速判断不同场景下的首选采集位置。
| 取证目标 | 首选采集点 | 备选/补充 | 关键参数 |
|---|---|---|---|
| 出口异常外联排查 | 出口链路TAP | 防火墙镜像、NetFlow | 全量包、时间同步NTP |
| 服务器区横向移动 | 核心交换机SPAN | 主机抓包、EDR日志 | 镜像口带宽≥被镜像口总和 |
| 主机失陷进程分析 | 主机抓包 | 内存取证、进程日志 | 抓包过滤表达式、存储空间 |
| 云主机东西向流量 | vSwitch镜像/VPC流日志 | 云防火墙日志、安全组日志 | 镜像策略、流日志采样率 |
| 非法AP与无线入侵 | 无线监听模式 | AP镜像、WIDS日志 | 信道、监听网卡、解密密钥 |
三、采集位置对证据完整性的具体影响
以交换机镜像为例，若被镜像端口总流量为800Mbps，而镜像口只有1Gbps，看似够用，但突发流量可能瞬间超过1Gbps，导致镜像口缓存溢出丢包。此时抓到的包会出现TCP重传、会话中断等假象，分析时容易误判为网络攻击。因此，镜像口带宽应至少为被镜像端口总带宽的1.5倍，并开启端口镜像的流量统计功能，观察丢包计数。
再以主机抓包为例，若在服务器上直接运行tcpdump，抓包进程会占用CPU和磁盘IO。高流量下，内核缓冲区（默认约2MB）可能迅速填满，导致丢包。工程上应调整ring buffer和snaplen，例如：
tcpdump -i eth0 -s 0 -B 4096 -w /data/capture.pcap -Z root
# -s 0 抓取完整包，-B 4096 设置4MB内核缓冲区
# 抓包前确认磁盘剩余空间：df -h /data
# 抓包后校验：tcpdump -r capture.pcap -nn | wc -l对于云环境，很多平台只提供VPC流日志，字段包括源IP、目的IP、源端口、目的端口、协议、字节数、包数、开始/结束时间、动作（ACCEPT/REJECT）。这类数据适合做连接关系与流量基线分析，但无法还原HTTP请求内容或DNS查询域名。若取证目标需要载荷，必须申请云厂商的流量镜像能力，或在该云主机内部署主机抓包。
注意：无线采集时，若目标网络使用WPA2/WPA3加密，仅抓到空口帧无法直接读取应用层内容。需要在合法授权下获取PSK或使用已关联客户端的密钥材料，才能解密。否则只能分析管理帧、EAPOL握手和流量元数据。
四、采集策略的工程闭环
一个可执行的采集策略应包含以下要素：明确采集点位置与覆盖范围、确认采集设备性能余量、配置过滤规则减少无关流量、统一时间源（NTP）保证多源数据可关联、设置存储与轮转策略防止磁盘写满、记录采集配置与哈希值以备证据链审计。只有把“在哪里采”和“怎么采”一起设计，才能让后续的协议分析、会话重组和入侵判定建立在可信的数据基础之上。