利用大语言模型分析 Wireshark 抓包数据

Posted on 2025-02-06

利用大语言模型来辅助分析 Wireshark 网络数据包，从而加深对典型网络协议的理解，提升分析常见网络问题的能力，并进一步建立标准化的分析流程 Prompt，以提高问题排查的效率。

背景

Wireshark 作为一款功能强大的网络数据包捕获与分析工具，在实际问题分析过程中，我主要遇到两个挑战：一是对数据包中异常信息或特定字段的含义理解不够深入，二是对过滤器（filter）的使用不够熟练，导致难以快速定位关键数据。

我希望能够利用大语言模型来辅助分析 Wireshark 网络数据包，从而加深对典型网络协议的理解，提升分析常见网络问题的能力，并进一步建立标准化的分析流程 Prompt，以提高问题排查的效率。

如何开始

Wireshark 导出的数据包格式是 .pcap，它是一种二进制格式，ChatGPT、Claude 和 DeepSeek 等大语言模型无法直接解析。但如果将 .pcap 转换为可读的结构化文本，它们就能进行分析并提供有价值的见解。

以下是 ChatGPT 给出的一些思路

你想要 LLM 直接解析 Wireshark 捕获的 .pcap 文件，并提取有价值的信息，比如网络错误、丢包、时延等，然后结合 Prompt 进行总结，对吧？你打算怎么使用这个分析工具？是本地跑 LLM 解析，还是想要一个在线交互式的分析环境？

从你的目标来看，可以有几种方式：

自动化日志提取与分析：

解析 .pcap 文件，提取关键数据（如 TCP 三次握手失败、DNS 解析错误等）。

生成结构化的日志，用 LLM 进行摘要和问题分析。

沉淀 Prompt 以优化 LLM 分析能力：

针对不同的网络问题（丢包、高时延、握手失败），设计一系列 Prompt，引导 LLM 输出更准确的诊断。

建立一个 Prompt 库，方便后续类似问题的分析。

构建一个 Project（可能是 Python 脚本 + LLM）：

用 pyshark 解析 .pcap 文件，将流量数据转换成 LLM 适合处理的格式（比如 JSON）。

结合 LLM 进行分析，并生成易读的报告。

你倾向于哪种方式？或者你希望从哪一步开始？

简单来说，有两种思路：

使用 pyshark 解析 .pcap 文件，直接提取关键数据。
将 .pcap 转换为可读的结构化文本，再交给大语言模型进行分析。

我更倾向于第二种方式，这样可以提升数据的可读性，并更灵活地利用大语言模型进行问题诊断和总结。

导出数据包解析结果

利用 Wireshark 的 “Export packet dissections” 功能，可以以结构化的方式导出解析后的数据包信息，便于后续分析、共享或存档。

常见的导出格式包括：

Plain Text (.txt)：以纯文本形式呈现解析数据，适合快速浏览。
CSV (.csv)：以表格化方式组织数据，便于统计和筛选分析。
JSON (.json)：包含完整的层级结构，适合机器读取和进一步处理。
XML (.xml)：适用于结构化存储和解析。
PSML/PDML：Wireshark 专用的 XML 格式，提供详细的协议解析信息。

export

我分别导出了 CSV 和 JSON 格式，并进行对比后发现：JSON 格式包含所有数据包的详细信息，更适合大语言模型进行深入分析。

以下是一个数据包的 JSON 样本，可以看出它完整记录了网络包的所有字段和细节。

{
  "_index": "packets-2005-03-30",
  "_type": "doc",
  "_score": null,
  "_source": {
    "layers": {
      "frame": {
        "frame.encap_type": "1",
        "frame.time": "Mar 30, 2005 16:52:17.755930000 CST",
        "frame.time_utc": "Mar 30, 2005 08:52:17.755930000 UTC",
        "frame.time_epoch": "1112172737.755930000",
        "frame.offset_shift": "0.000000000",
        "frame.time_delta": "0.015764000",
        "frame.time_delta_displayed": "0.015764000",
        "frame.time_relative": "271.259884000",
        "frame.number": "28",
        "frame.len": "129",
        "frame.cap_len": "129",
        "frame.marked": "0",
        "frame.ignored": "0",
        "frame.protocols": "eth:ethertype:ip:udp:dns",
        "frame.coloring_rule.name": "UDP",
        "frame.coloring_rule.string": "udp"
      },
      "eth": {
        "eth.dst": "00:12:a9:00:32:23",
        "eth.dst_tree": {
          "eth.dst_resolved": "3Com_00:32:23",
          "eth.dst.oui": "4777",
          "eth.dst.oui_resolved": "3Com Ltd",
          "eth.dst.lg": "0",
          "eth.dst.ig": "0",
          "eth.addr": "00:12:a9:00:32:23",
          "eth.addr_resolved": "3Com_00:32:23",
          "eth.addr.oui": "4777",
          "eth.addr.oui_resolved": "3Com Ltd",
          "eth.lg": "0",
          "eth.ig": "0"
        },
        "eth.src": "00:60:08:45:e4:55",
        "eth.src_tree": {
          "eth.src_resolved": "3Com_45:e4:55",
          "eth.src.oui": "24584",
          "eth.src.oui_resolved": "3Com",
          "eth.src.lg": "0",
          "eth.src.ig": "0",
          "eth.addr": "00:60:08:45:e4:55",
          "eth.addr_resolved": "3Com_45:e4:55",
          "eth.addr.oui": "24584",
          "eth.addr.oui_resolved": "3Com",
          "eth.lg": "0",
          "eth.ig": "0"
        },
        "eth.type": "0x0800",
        "eth.stream": "1"
      },
      "ip": {
        "ip.version": "4",
        "ip.hdr_len": "20",
        "ip.dsfield": "0x00",
        "ip.dsfield_tree": {
          "ip.dsfield.dscp": "0",
          "ip.dsfield.ecn": "0"
        },
        "ip.len": "115",
        "ip.id": "0x87de",
        "ip.flags": "0x00",
        "ip.flags_tree": {
          "ip.flags.rb": "0",
          "ip.flags.df": "0",
          "ip.flags.mf": "0"
        },
        "ip.frag_offset": "0",
        "ip.ttl": "128",
        "ip.proto": "17",
        "ip.checksum": "0x6a95",
        "ip.checksum.status": "2",
        "ip.src": "192.168.170.56",
        "ip.addr": "192.168.170.56",
        "ip.src_host": "192.168.170.56",
        "ip.host": "192.168.170.56",
        "ip.dst": "217.13.4.24",
        "ip.addr": "217.13.4.24",
        "ip.dst_host": "217.13.4.24",
        "ip.host": "217.13.4.24",
        "ip.stream": "1"
      },
      "udp": {
        "udp.srcport": "1707",
        "udp.dstport": "53",
        "udp.port": "1707",
        "udp.port": "53",
        "udp.length": "95",
        "udp.checksum": "0x39f0",
        "udp.checksum.status": "2",
        "udp.stream": "3",
        "udp.stream.pnum": "1",
        "Timestamps": {
          "udp.time_relative": "0.000000000",
          "udp.time_delta": "0.000000000"
        },
        "udp.payload": "32:6e:01:00:00:01:00:00:00:00:00:00:05:5f:6c:64:61:70:04:5f:74:63:70:17:44:65:66:61:75:6c:74:2d:46:69:72:73:74:2d:53:69:74:65:2d:4e:61:6d:65:06:5f:73:69:74:65:73:02:64:63:06:5f:6d:73:64:63:73:0b:75:74:65:6c:73:79:73:74:65:6d:73:05:6c:6f:63:61:6c:00:00:21:00:01"
      },
      "dns": {
        "dns.id": "0x326e",
        "dns.flags": "0x0100",
        "dns.flags_tree": {
          "dns.flags.response": "0",
          "dns.flags.opcode": "0",
          "dns.flags.truncated": "0",
          "dns.flags.recdesired": "1",
          "dns.flags.z": "0",
          "dns.flags.checkdisable": "0"
        },
        "dns.count.queries": "1",
        "dns.count.answers": "0",
        "dns.count.auth_rr": "0",
        "dns.count.add_rr": "0",
        "Queries": {
          "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.utelsystems.local: type SRV, class IN": {
            "dns.qry.name": "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.utelsystems.local",
            "dns.qry.name.len": "69",
            "dns.count.labels": "8",
            "dns.qry.type": "33",
            "dns.qry.class": "0x0001"
          }
        },
        "dns.response_in": "30"
      }
    }
  }
}

初步探索

抓包样本

网上有许多开源的 Wireshark 抓包样本可供学习，例如 Wireshark Sample Captures 官方库，该库收录了涵盖各种网络协议和应用场景的 .pcap 文件，便于研究和测试。地址：Wireshark Sample Captures。

实验

我的目标是利用大语言模型分析和理解 Wireshark 抓取的网络数据包，主要聚焦于两个方向：

学习典型的网络协议，加深对不同协议结构和行为的理解。
分析常见网络问题，并总结出一套标准化的 Prompt ，以提升问题排查效率。

在实际分析中，以下问题较为常见：

TCP 连接问题（如三次握手失败、连接被重置）
HTTP/HTTPS 错误（如 4xx、5xx 状态码）
DNS 解析异常（如解析失败、响应超时）
网络延迟/性能问题（如高 RTT、丢包）
应用层协议异常（如 WebSocket 断连、TLS 握手失败）

作为初步探索，我选取了一个 DNS 查询包 作为示例，并尝试用大语言模型进行分析，以验证其对网络数据的理解和诊断能力。

Prompt

在使用大语言模型解析 Wireshark 抓包数据时，我设计了一系列 Prompt，以提取关键信息、诊断网络问题，并加深对协议的理解。

基础信息提取

用于获取抓包数据的基本概况，包括通信协议、IP 地址、时间信息等：

请分析这个 Wireshark 抓包数据文件并提供以下信息：

涉及的主要协议

通信双方的 IP 地址

关键的时间节点

异常数据包的特征

基本的统计信息（包数量、流量等）

问题诊断

用于识别潜在的网络问题，并提供分析和解决方案：

基于上述基础信息，请：

识别存在的网络问题

分析问题的可能原因

提供问题的解决建议

列出类似问题的预防措施

协议学习

用于深入学习抓包数据涉及的具体协议，加深对协议的理解：

请详细解释这个抓包中的 [具体协议] ：

协议的基本工作流程

关键字段的含义

正常vs异常的特征

该协议的最佳实践

这套 Prompt 既能帮助快速提取抓包的核心信息，也能用于深入分析问题和学习协议规范，从而提升网络数据分析的效率和准确性。

大模型给出的结果

基础信息提取

我来分析这个DNS相关的抓包文件:

涉及的主要协议

底层: Ethernet

网络层: IPv4

传输层: UDP

应用层: DNS (端口53)

通信双方的IP地址
主要的通信方:

内部客户端: 192.168.170.8, 192.168.170.56

DNS服务器: 192.168.170.20, 217.13.4.24

关键时间节点

开始时间: 2005-03-30 16:47:46.496

结束时间: 2005-03-30 16:52:25.375

总时长: 约4分39秒

异常数据包的特征
检测到多个DNS查询失败 (RCODE=3 NXDOMAIN):

GRIMM.utelsystems.local 的A记录查询

_ldap._tcp.dc._msdcs.utelsystems.local 的SRV记录查询

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.utelsystems.local 的SRV记录查询

基本统计信息

总包数: 38个数据包

DNS查询类型分布:

A记录查询

AAAA记录查询

MX记录查询

TXT记录查询

SRV记录查询

PTR记录查询

ANY记录查询

主要查询域名:

google.com

www.netbsd.org

www.isc.org

*.utelsystems.local

DNS响应情况:

成功响应包含A记录、AAAA记录、MX记录等

多个NXDOMAIN失败响应

平均DNS响应时间在毫秒级别

这些DNS查询数据显示系统在进行常规的域名解析，同时也在尝试解析一些内部Active Directory相关的域名(但失败了)，这可能表明是一个Windows域环境中的客户端行为。

分析指定编号或者ID的报文

在Wireshark数据包中, DNS查询ID在DNS头部, 你可以在报文的dns层看到:
1
2
3
4
5
6
7
8
9
"dns": {
  "dns.id": "0x326e",  // 这里就是DNS查询ID
  "dns.flags": "0x0100",
  "dns.flags_tree": {
    "dns.flags.response": "0",
    "dns.flags.opcode": "0", 
    ...
  }
}
我们以报文28为例,完整路径是:
frame->layers->dns->dns.id : "0x326e"

这个ID的作用是:

用于匹配DNS请求和响应

是一个16位的标识符

响应包会携带相同的ID, 使客户端能够匹配对应的请求

在报文30(响应包)中可以看到相同的ID "0x326e"

建议在Wireshark中:

使用显示过滤器 dns.id == 0x326e 可以快速找到请求-响应对

选择DNS协议的数据包, 展开DNS部分就能看到ID字段

也可以在列表视图中添加一列显示 dns.id

这是DNS协议中请求-响应匹配机制的关键字段。

详细解释每个 flag 的含义

让我详细解释这个DNS响应中Flags字段(0x8583)的每个比特位的含义:

这个16位的Flags值 0x8583 转换成二进制是: 1000 0101 1000 0011

从左到右每个位的含义是:

QR(位15): 1 = 表示这是一个响应消息(Response)

Opcode(位11-14): 0000 = 标准查询(Standard query)

AA(位10): 1 = 权威应答(Authoritative Answer),表示响应来自权威DNS服务器

TC(位9): 0 = 消息没有被截断(Not truncated)

RD(位8): 1 = 期望递归(Recursion Desired)

RA(位7): 1 = 服务器支持递归查询(Recursion Available)

Z(位6): 0 = 保留位,必须为0

AD(位5): 0 = 响应未经过DNSSEC认证

CD(位4): 0 = 不接受未认证的数据

Rcode(位0-3): 0011 = 3,表示域名不存在(NXDOMAIN)

特别注意两点:

AA(Authoritative Answer)位被设置,说明这是一个权威DNS服务器的响应

Rcode为3(NXDOMAIN),这是一个否定性响应,表示请求的域名不存在

这个Flags组合表明:

这是一个来自权威服务器的响应

服务器支持递归查询

请求的域名不存在

响应未经过DNSSEC认证

消息完整(未截断)

这个特定的响应是一个典型的”域名不存在”错误响应,来自一个权威DNS服务器。

总结

利用大语言模型分析 Wireshark 抓包数据可以显著提升网络协议学习和问题诊断效率，特别适合帮助工程师快速理解复杂协议细节和异常模式。