拆分大型 PCAP——提取单次会话不失上下文
如何分割大型 PCAP 文件，提取一个 TCP 或 UDP 会话，并为协议故障排除保留足够的上下文。
大型 PCAP 文件难以打开、共享和审阅。从繁忙的服务器、摄像头网关、USB-over IP 实验室或生产事件捕获的数据可能会迅速增长到千兆字节。显而易见的解决方法是拆分文件或提取一个对话。风险在于切断解释失败的背景。
正确的问题不仅仅是“如何使 PCAP 更小？”问题是“什么样的环境必须保留下来，这样较小的捕获仍然有用？”
为什么大型捕获变得难以使用
大量捕获会产生实际问题：
- 数据包分析器内存压力
- 索引速度慢
- 难以上传到支持门户
- 敏感的无关流量
- 太多对话
- 时间跨度长
- 真实事件周围的重复噪音
按大小拆分可以使文件易于管理。提取对话可以使证据集中。但这两种操作都可以隐藏重要的设置、DNS、ARP、TLS 或重传上下文。
提取对话需要五个以上元组
TCP 或 UDP 会话通常由源 IP、目标 IP、端口和协议来标识。这是一个好的开始。但故障排除可能还需要：
- 连接前进行 DNS 查找
- ARP 或邻居发现
- TCP握手
- TLS 握手
- ICMP 错误
- 可见故障之前的重传
- 相关控制通道
- 客户端重试后服务器响应
如果仅在应用程序错误后提取数据包，接收者可能会错过真正的原因。
按大小拆分与按时间拆分
按文件大小拆分对于工具兼容性和上传限制很有用。按时间分割对于事件窗口很有用。按对话拆分对于集中调试很有用。每个都有权衡。
问：
- 接收工具有文件大小限制吗？
- 事件时间窗口重要吗？
- 一个流程代表整个案例吗？
- 是否需要多个相关流程？
- 时间戳需要保持原始状态吗？
- 数据包编号应该保留还是重新映射？
输出应记录所使用的拆分策略。
保留原始数据包证据
生成较小的文件时，保持原始捕获不变。派生捕获应该是可重复的。如果支持团队稍后在提取的窗口之前请求数据包，则原始数据包必须仍然存在。
有用的元数据：
- 原始文件名和哈希值
- 分流或萃取过滤器
- 时间窗口
- 之前和之后的数据包计数
- 包括对话
- 有意丢弃的数据包
- 输出文件哈希值
这将“我剪切文件”变成了一种防御性操作。
PCAP 手术适合的场合
PCAP 手术专为证据审查和受控编辑而设计。大型捕获处理是其中的一部分：首先检查，其次选择最小输出，第三记录操作。
对于大型 PCAP 工作流程，PCAP 手术应有助于回答：
- 存在哪些对话？
- 哪个流程包含故障？
- 它有多少背景？
- 提取了什么？
- 故意排除了什么？
- 衍生捕获可以再生吗？
如果您的搜索查询是“split large pcap”或“从 pcap 中提取 tcp 会话”，请勿仅针对文件大小进行优化。针对较小的捕获进行优化，但仍然可以解释失败。