PRACTICAL PACKET ANALYSIS学习:第10章：真实网络故障分析案例 — 深度中文解读

虾球xz

425人浏览 · 2026-06-16 07:42:10

虾球xz · 2026-06-16 07:42:10 发布

本章通过六个真实场景，演示如何用 Wireshark 抓包来定位网络故障。核心思路：先观察流量，再找异常，再推因果。

一、网络分析的基本方法论

用户报告故障
    |
    v
抓包 (Wireshark)
    |
    v
观察协议层次 (Protocol Hierarchy)
    |
    v
检查会话/对话 (Conversations / Streams)
    |
    v
找到异常 --> 推断原因 --> 提出解决方案

二、案例1：ESPN 网页内容缺失

背景

用户 Pete 每天早上访问 ESPN 看篮球比分，今天页面加载缓慢且图片全部丢失。

分析过程

第一步：查看 HTTP 请求

用过滤器 http.request.method == "GET" 找到 7 个 HTTP 请求，均指向 ESPN 相关域名（包括 CDN）。
为什么一个网页会有 7 个 HTTP 请求？

浏览器访问 www.espn.com
        |
        v
   下载 HTML 页面
        |
        v
   解析 HTML，发现引用了其他资源：
   ┌─────────────────────────────────────┐
   │  图片 → img.espncdn.com            │
   │  广告 → cdn.optimizely.com         │
   │  视频 → media.espn.com             │
   │  ...                               │
   └─────────────────────────────────────┘
        |
        v
   对每个域名发起 DNS 查询 + HTTP 请求

这是正常行为，现代网页通常引用来自多个服务器的内容。

第二步：查看协议层次

发现只有 HTTP 和 DNS 两种应用层协议，共 14 个 DNS 包（7 个请求 + 7 个应答），对应 7 个 HTTP 请求。

第三步：查看 IP 会话 (Conversations)

异常发现：理应是 7 个 IP 会话，实际上是 8 个！
多出来的会话：

本机 IP	远端 IP	发送字节	接收字节
172.16.16.154	203.0.113.94	6774	0

接收字节为 0，说明对方没有回应！

第四步：深入分析该异常会话

Pete 的电脑                       203.0.113.94
     |                                  |
     |------- SYN ------------------>  |   (无回应)
     |------- SYN (重传) ----------->  |   (无回应)
     |------- SYN (重传) ----------->  |   (无回应)
     |                                  |
     持续 95 秒后放弃

正常 TCP 握手应该是：

客户端 ---SYN---> 服务器
客户端 <--SYN/ACK-- 服务器
客户端 ---ACK---> 服务器

但这里只有 SYN，永远收不到 SYN/ACK。

第五步：找根本原因

这个第 8 个会话没有对应的 DNS 请求！也就是说，Pete 的电脑直接用了一个旧的 IP 地址，没有重新查询 DNS。
原因：DNS 缓存过期问题

                 DNS 缓存 (本地)
                 ┌───────────────────────────────┐
                 │ imgespn.com --> 203.0.113.94  │  <-- 这个 IP 已经失效了！
                 └───────────────────────────────┘
                         |
                         | 直接使用旧 IP，不发 DNS 请求
                         |
                         v
                  203.0.113.94 (已不存在或不监听)
                         |
                  连接超时，内容加载失败

解决方法

手动清除 DNS 缓存：

Windows：ipconfig /flushdns
Linux：sudo systemd-resolve --flush-caches
或者等几分钟让缓存自然过期。

经验总结

DNS 缓存是双刃剑：平时加速访问，但服务器 IP 变更后可能导致连接失败。抓包时要注意"应该存在却不存在的包"（比如缺少 DNS 请求）。

三、案例2：气象站停止上报数据

背景

Pete 的气象站通过 HTTP 向 Wunderground 上报数据，某天凌晨 12 点后停止上报。

网络拓扑

屋顶气象站
    |
    | RF 无线链接
    |
气象接收器 (172.16.16.154)
    |
    | 有线网络
    |
路由器 (172.16.16.1)
    |
    | 互联网
    |
Wunderground 服务器 (38.102.136.125)

分析过程

HTTP GET 请求结构

接收器通过 URL 参数传送气象数据（这是一种常见的 IoT 数据上报方式）：

GET /weatherstation/updateweatherstation.php?
    ID=PETE001&
    PASSWORD=000000&     <-- 问题在这里！
    tempf=43.0&
    dewptf=13.6&
    windchillf=43.0&
    ...

服务器响应

HTTP/1.0 200 OK
INVALIDPASSWORDID|Password or key and/or id are incorrect

HTTP 状态码 200 表示"请求格式正确，服务器收到了"，但响应体说明密码错误。
密码变成了全零（000000），原因可能是：

设备固件更新后配置丢失
设备重启后配置未保存

安全警示

做法	安全性	说明
HTTP + URL 传密码	极差	明文传输，任何人抓包可见
HTTPS + URL 传密码	一般	加密传输，但 URL 会被记录在日志
HTTPS + POST Body 传密码	较好	加密且不在 URL 中暴露

解决方法

登录气象接收器管理界面，重新填写正确密码。

四、案例3：无法访问互联网（三个子场景）

子场景 A：网关配置错误

正常访问互联网的流程

故障现象

DNS 查询发出后无任何回应，反复重试：

0.0s  DNS 查询 --> 4.2.2.2  (无回应)
0.1s  DNS 查询 --> 4.2.2.1  (无回应，换备用 DNS)
1.0s  DNS 查询 --> 4.2.2.2  (仍无回应)
...
8.0s  浏览器报错：无法访问此网站

根本原因

用户手动配置了错误的默认网关地址。那个 IP 根本不是路由器，所以 DNS 包无法被转发到互联网。
ARP 能成功是因为错误的网关 IP 对应的设备在局域网内存在并回应了 ARP，但它不具备路由转发能力。

子场景 B：hosts 文件被篡改

故障现象

用户无法访问 Google，但能访问其他网站。抓包发现：

ARP 请求：172.16.0.102 的 MAC 是多少？  <-- 这不是网关！
ARP 回复：MAC 是 00:21:70:c0:56:f0
TCP SYN --> 172.16.0.102:80             <-- 往内网某台机器发 HTTP 请求
TCP RST <-- 172.16.0.102               <-- 对方拒绝，因为它不是 Web 服务器

没有 DNS 查询！这说明系统在查询前已经"知道"了 IP。

DNS 解析优先级

应用程序发起域名查询
        |
        v
    检查 hosts 文件              <-- 优先级最高
        |
    有记录? ---> 是 --> 直接使用
        |
        否
        |
        v
    检查本地 DNS 缓存
        |
    有缓存? ---> 是 --> 直接使用
        |
        否
        |
        v
    发送 DNS 查询到配置的 DNS 服务器

hosts 文件中有：

172.16.0.102    www.google.com    <-- 错误条目！

系统认为 Google 就在局域网内，于是直接 ARP 然后 TCP 连接，而那台内网机器根本不是 Web 服务器。
hosts 文件位置：

Windows：C:\Windows\System32\drivers\etc\hosts
Linux：/etc/hosts
安全启示： 恶意软件常通过篡改 hosts 文件将银行网站重定向到钓鱼网站，这是一种经典的攻击手法。

子场景 C：上游服务器故障

故障现象

全公司都无法访问 Google（不只是一个人）。

DNS 查询 --> 4.2.2.1                         成功
DNS 回复 <-- 4.2.2.1 (返回多个 IP 地址)       成功
TCP SYN --> 74.125.95.105:80                 无回应
TCP SYN --> 74.125.95.105:80 (重传)          无回应
TCP SYN --> 74.125.95.105:80 (重传)          无回应
浏览器报错

分析

组件	状态	证据
本地网络	正常	DNS 查询成功
网关路由器	正常	DNS 包顺利转发出去
外部 DNS 服务器	正常	返回了有效 IP
Google 服务器	故障	TCP SYN 无回应，且没有 RST

没有 RST（拒绝）而是完全无回应，这与子场景 B 不同：

子场景 B：SYN --> RST  (对方在线，但拒绝连接)
子场景 C：SYN --> (沉默)  (对方不响应，可能宕机或被防火墙丢包)

这个问题在对方服务器，我们无能为力，等待 Google 修复即可。

五、案例4：打印机间歇性中断

故障现象

发送大型打印任务时，打印机打几页后停止，无论哪台电脑发送都会复现。

TCP 数据传输正常流程

客户端 (172.16.0.8)                    打印机 (172.16.0.253)
       |                                      |
       |------ TCP SYN ------------------>   |
       |<----- TCP SYN/ACK ---------------  |
       |------ TCP ACK ------------------>   |
       |                                      |
       |------ 数据包 1460 字节 --------->   |
       |<----- ACK ----------------------    |
       |------ 数据包 1460 字节 --------->   |
       |<----- ACK ----------------------    |
       |       (持续传输...)                  |
       |                                      |
       |------ 数据包 N ----------------->   |
       |       (打印机不再回应 ACK)            |
       |                                      |
       |  等待 5.5 秒...                      |
       |------ 重传 数据包 N ------------>   |  (TCP 重传机制)
       |  等待 11 秒...                       |
       |------ 重传 数据包 N ------------>   |  (仍无回应)
       |                                      |
       连接中断，打印停止

TCP 重传机制说明

重传超时 (RTO, Retransmission Timeout) 是 TCP 的可靠性保障机制：
$RTOn=RTOn−1×2RTO_n = RTO_{n-1} \times 2$
每次重传等待时间翻倍（指数退避）：

第 1 次重传：等待 5.5 秒
第 2 次重传：再等 11 秒
第 3 次重传：再等 22 秒
…直到放弃

故障定位

由于问题只出现在与打印机的通信中，且客户端正常发送了数据，打印机不再回应 ACK，说明问题在打印机端。
最终诊断：打印机 RAM 故障，大型打印任务耗尽了某段有问题的内存区域，导致打印机停止接受数据。

六、案例5：分支机构无法访问总部应用

网络拓扑

分支机构                          总部
┌─────────────────────┐           ┌─────────────────────────┐
│                     │           │                         │
│  工作站             │           │  应用服务器              │
│  172.16.16.101      │           │  172.16.16.200          │
│         |           │           │                         │
│  分支 DNS 服务器     │   WAN     │  总部 DNS 服务器         │
│  172.16.16.251      │<--------->│  172.16.16.250          │
│         |           │           │         |               │
│  分支路由器         │           │  总部路由器              │
└─────────────────────┘           └─────────────────────────┘

DNS 主从同步原理

总部 DNS（主服务器）        分支 DNS（从服务器）
       |                          |
       |    区域传输 (Zone Transfer)
       |    通过 TCP 端口 53
       |<------------------------>|
       |   资源记录同步           |
       |   (A记录、MX记录等)      |
                                  |
                                  | 用户查询
                              工作站

区域传输用 TCP 而非 UDP 是因为传输的数据量大，需要 TCP 的可靠传输保证。

故障排查过程

第一步：工作站抓包

工作站 --> 分支DNS: 查询 appserver 的 IP
分支DNS --> 工作站: 服务器故障 (SERVFAIL)

分支 DNS 本身出了问题。
第二步：分支DNS服务器抓包

分支DNS --> 总部DNS (172.16.16.250): TCP SYN (端口53)
                                     (无回应！)

区域传输的 TCP SYN 没有得到回应。
第三步：分析总部路由器
总部路由器配置了防火墙规则：

规则	端口53 UDP	端口53 TCP
入站规则	允许	禁止

UDP 53 允许普通 DNS 查询通过，但 TCP 53 被封锁，导致区域传输无法进行。

解决方法

在总部路由器上放行入站 TCP 端口 53 流量，让区域传输能够完成。

七、案例6：数据损坏责任归因

背景

开发者写了一个应用，把各门店的 CSV 销售数据通过 FTP 上传到总部服务器。数据库数据有错，开发者怀疑是网络传输损坏了数据。

验证方法：文件哈希对比

通过 Wireshark 从抓包文件中还原传输的 CSV 文件，然后与原始文件做 MD5 对比：
$网络传输无损坏MD5(\text{原始文件}) = MD5(\text{从抓包还原的文件}) \implies \text{网络传输无损坏}$
MD5（信息摘要算法5） 的特性：对于任意文件 $f$ ， $M D 5 (f)$ 是一个 128 位的固定长度摘要。如果 $MD5(f_1) = MD5(f_2)$ ，则可认为 $f1≡f2f_1 \equiv f_2$ 。
只要哈希值相同，就证明文件在传输过程中没有被改变，数据损坏发生在服务器端的应用处理逻辑中，与网络无关。

操作方法

在 Wireshark 中找到 FTP-DATA 流
右键 → Follow TCP Stream
点击 “Save As”，保存为原始文件名
在命令行对比 MD5：

# Linux / macOS
md5sum 原始文件.csv
md5sum 从抓包还原.csv
# Windows PowerShell
Get-FileHash 原始文件.csv -Algorithm MD5
Get-FileHash 从抓包还原.csv -Algorithm MD5

八、六个案例的对比总结

案例	关键协议	故障层次	定位手段
ESPN内容缺失	DNS, HTTP	客户端DNS缓存	对比会话数与DNS请求数
气象站不上报	HTTP	认证配置	跟踪TCP流，读URL参数
网关配置错误	ARP, DNS	客户端配置	DNS无回应
hosts文件篡改	ARP, TCP	客户端配置	无DNS请求就发起连接
上游服务器故障	DNS, TCP	远端服务器	SYN无回应且无RST
打印机故障	TCP	硬件故障	TCP重传后通信中断
数据库错误	FTP, TCP	应用逻辑	MD5哈希对比

第11章：对抗慢速网络 — 深度中文解读

本章核心问题：网络慢，到底是谁的锅？ 通过 TCP 的内置机制，我们可以精确定位延迟来源。

一、核心概念：延迟 (Latency)

延迟就是数据包从发出到收到之间的时间差。
$单向延迟=T到达−T发出\text{单向延迟} = T_{\text{到达}} - T_{\text{发出}}$
$(RTT)=T收到ACK−T发出数据包\text{往返时延 (RTT)} = T_{\text{收到ACK}} - T_{\text{发出数据包}}$
延迟低 = 网络快；延迟高 = 网络慢。

二、TCP 错误恢复机制之一：重传 (Retransmission)

原理

TCP 发出数据包后，会启动一个计时器，等待对方的 ACK（确认收到）。如果超时没有收到 ACK，就认为数据丢失，重新发送。

发送方                         接收方
  |                               |
  |--- 数据包 ----------------->  |
  |                               |
  |  (等待 RTO 时间...)            |
  |  (没有收到 ACK)               |
  |                               |
  |--- 重传 #1 ---------------->  |   等待 RTO x 1
  |--- 重传 #2 ---------------->  |   等待 RTO x 2
  |--- 重传 #3 ---------------->  |   等待 RTO x 4
  |--- 重传 #4 ---------------->  |   等待 RTO x 8
  |--- 重传 #5 ---------------->  |   等待 RTO x 16
  |
  连接终止

重传超时的计算（指数退避）

设第 $n$ 次重传的等待时间为 $RTO_n$ ，则：
$RTOn=RTO0×2nRTO_n = RTO_0 \times 2^n$
例如初始 $RTO_0 = 0.2$ 秒：
$RTO1=0.2s,RTO2=0.4s,RTO3=0.8s,RTO4=1.6s,RTO5=3.2sRTO_1 = 0.2s,\quad RTO_2 = 0.4s,\quad RTO_3 = 0.8s,\quad RTO_4 = 1.6s,\quad RTO_5 = 3.2s$

最大重传次数

操作系统	默认最大重传次数
Windows	5 次
Linux	15 次

重传超时的确定方式

发送一个数据包后，TCP 记录 RTT（往返时延），多次采样取平均，用来决定 RTO：
$\alpha \times RTT_{\text{平均}} \quad (\alpha \text{ 为系数，通常大于 1})$

三、TCP 错误恢复机制之二：重复 ACK 与快速重传

序列号与确认号的关系

每个 TCP 数据包都带有序列号 (SEQ)，接收方用确认号 (ACK) 告诉发送方"我期待下一个收到的字节编号"：
$ACK回复=SEQ收到+数据字节数ACK_{\text{回复}} = SEQ_{\text{收到}} + \text{数据字节数}$
例如：

发送方 SEQ=5000, 数据500字节
接收方回复 ACK=5500  (我期待下一个从5500开始)
发送方 SEQ=5500, 数据500字节
接收方回复 ACK=6000
发送方 SEQ=6000, 数据500字节
接收方回复 ACK=6500

当数据包丢失时

发送方发送了 3 个包：SEQ=5000, SEQ=5500, SEQ=6000
接收方收到了：
  SEQ=5000  (正常)
  SEQ=6000  (跳过了 5500！)  <-- 包丢失
接收方：我没收到 SEQ=5500，我重复发 ACK=5500 催你重发！

关键规则

收到 3 个重复 ACK → 触发快速重传 (Fast Retransmission)，不等 RTO 超时，立刻重发丢失的包。

SACK（选择性确认）

普通模式：丢了包 N，则 N 之后的所有包都要重传。
SACK 模式：只重传真正丢失的包 N，其他已收到的包不用重传。

无 SACK：丢失第2个包 → 重传第2、3、4、5个包
有 SACK：丢失第2个包 → 只重传第2个包

现代操作系统基本都启用了 SACK，效率高得多。

四、TCP 流量控制：滑动窗口 (Sliding Window)

为什么需要流量控制？

发送方太快、接收方太慢 → 接收方缓冲区溢出 → 数据丢失。
流量控制的目的：让发送方的速度匹配接收方的处理能力。

接收窗口 (Receive Window)

接收方在每个 ACK 包的 TCP 头部里告诉发送方：“我的缓冲区还剩多少空间，你最多发这么多字节”。

接收方缓冲区总大小 = 5000 字节
发送方发了 2500 字节 → 缓冲区剩 2500 字节
发送方又发了 2000 字节 → 缓冲区剩 500 字节
接收方处理完数据 → 缓冲区恢复到 5000 字节

窗口动态调整

正常状态
接收方 window = 5000 字节
发送方每次发 5000 字节以内
              |
              | 接收方变忙，处理变慢
              v
接收方发送 ACK，window = 1000 字节
发送方减速，每次最多发 1000 字节
              |
              | 接收方恢复正常
              v
接收方发送 ACK，window = 5000 字节
发送方恢复速度

零窗口 (Zero Window)：紧急刹车

当接收方完全无法处理数据时，发送 window = 0 的包，告知发送方立刻停止发送。

发送方                         接收方
  |                               |
  |--- 数据 2000 字节 --------->  |
  |<-- ACK, window=0 ----------- |  (停！我满了)
  |                               |
  |--- keep-alive ------------>  |  (你还活着吗？每隔几秒问一次)
  |<-- ACK, window=0 ----------- |  (还满着呢)
  |--- keep-alive ------------>  |
  |<-- ACK, window=1000 -------- |  (好了，你可以发了)
  |--- 数据 1000 字节 ---------> |  (恢复发送，但速度降低)

三种窗口状态对比

状态	窗口值	含义	发送方行为
正常	大于 0	接收方有空间	正常发送
窗口缩小	减小中	接收方变忙	降速发送
零窗口	0	接收方满了	停止发送，发 keep-alive

五、定位高延迟来源：六包分析法

这是本章最实用的技巧。只需分析连接的前 6 个包，就能判断延迟来自哪里。

正常通信的 6 个包

包1: 客户端 --SYN-->           服务器  (TCP握手第1步)
包2: 客户端 <--SYN/ACK--       服务器  (TCP握手第2步)
包3: 客户端 --ACK-->           服务器  (TCP握手第3步)
包4: 客户端 --HTTP GET-->      服务器  (发起请求，应用层)
包5: 客户端 <--ACK--           服务器  (服务器确认收到GET)
包6: 客户端 <--HTTP 数据--     服务器  (服务器返回数据，应用层)

正常情况下，6 个包全部完成在 0.1 秒以内。

类型1：网线延迟 (Wire Latency) — 中间设备的锅

包1: SYN        发出时间: 0.000s
包2: SYN/ACK    到达时间: 0.870s  <-- 延迟在这里！
包4: GET        发出时间: 0.875s
包5: ACK        到达时间: 2.025s  <-- 这里也有延迟！

判断逻辑：SYN/ACK 服务器处理极少，负载再重也能快速回应，所以慢不是服务器的问题，不是客户端的问题，是中间网络设备（路由器、防火墙、代理）的问题。

客户端          路由器/防火墙          服务器
   |                  |                  |
   |---SYN---------> |                  |
   |                  |  (处理很慢...)   |
   |                  |---SYN---------> |
   |                  |<--SYN/ACK------ |
   |  (经历漫长等待)   |                  |
   |<--SYN/ACK------- |                  |

类型2：客户端延迟 (Client Latency) — 客户端的锅

包1: SYN        0.000s
包2: SYN/ACK    0.001s  (正常！)
包3: ACK        0.002s  (正常！)
包4: GET        1.342s  <-- 延迟在这里！
包5: ACK        1.343s  (正常)
包6: 数据       1.344s  (正常)

判断逻辑：包3 到包4 之间完全是客户端的事情（生成 HTTP GET 请求需要应用层处理），所以慢 = 客户端处理能力不足。

类型3：服务器延迟 (Server Latency) — 服务器的锅

包1: SYN        0.000s
包2: SYN/ACK    0.001s  (正常)
包3: ACK        0.002s  (正常)
包4: GET        0.003s  (正常)
包5: ACK        0.004s  (正常)  <-- 服务器确认收到GET，这步快
包6: HTTP数据   0.984s  <-- 延迟在这里！

判断逻辑：包5 到包6 是服务器去取数据、处理、打包、发送，需要应用层处理，所以慢 = 服务器应用层处理能力不足。

六包定位框架

客户端                                服务器
  |                                      |
  |---[1] SYN------------------------>  |
  |                                      |
  |<--[2] SYN/ACK--------------------  |
  |   ^                                  |
  |   如果[1]到[2]慢 = 网线延迟          |
  |                                      |
  |---[3] ACK------------------------>  |
  |---[4] HTTP GET------------------->  |
  |   ^                                  |
  |   如果[3]到[4]慢 = 客户端延迟        |
  |                                      |
  |<--[5] ACK------------------------  |
  |<--[6] HTTP 数据------------------  |
      ^
      如果[5]到[6]慢 = 服务器延迟

六、网络基线 (Network Baseline)

什么是基线？

在网络正常运行时，记录下各种流量数据，作为"正常状态的参照"。当网络出问题时，与基线对比，就能发现异常。
就好比体检时的"正常值参考范围"，没有参考范围，就不知道你的指标是否异常。

三类基线

各类基线说明

基线类型	监控对象	主要用途
站点基线	整个网络出口	发现新的异常协议、广播风暴
主机基线	关键服务器	分析服务器负载、启动异常
应用基线	业务关键应用	对比应用响应速度是否退化

基线采集的注意事项

至少采集三次：低流量时段（早晨）、高流量时段（下午）、无流量时段（深夜）
不要在被测主机上直接抓包：高负载时会影响主机性能，导致基线数据失真
妥善保存：基线包含网络敏感信息，加密存储，但要方便随时取用
整理速查表：记录常用值，如平均传输速率、主机依赖关系等

七、本章全貌：排查慢速网络的决策树

八、三种 TCP 异常包的对比

包类型	触发方	触发条件	说明
TCP 重传	发送方	发出包后，RTO 内未收到 ACK	发送方认为包丢了，主动重发
重复 ACK	接收方	收到乱序的包	接收方催发送方补发缺失的包
快速重传	发送方	收到 3 个重复 ACK	不等 RTO，立刻补发丢失的包
零窗口	接收方	缓冲区满了	告知发送方暂停发送
Keep-Alive	发送方	零窗口后定期探测	检测接收方是否恢复

第12章：安全领域的数据包分析 — 深度中文解读

本章从攻击者和防御者两个视角，分析网络安全事件中的流量特征。

一、攻击的基本流程

侦察 (Reconnaissance)
    |
    v
扫描目标 (Scanning)
    |
    v
流量劫持 / 中间人攻击 (Traffic Manipulation / MITM)
    |
    v
漏洞利用 (Exploitation)
    |
    v
植入恶意软件 / 建立后门 (Malware / Backdoor)
    |
    v
持久控制 (C2 Command & Control)

二、侦察：SYN 扫描

原理

攻击者向目标发送 SYN 包，根据响应判断端口是否开放，不完成握手（所以叫"半开放扫描"）。

三种扫描结果对比

目标响应	含义	判断
SYN/ACK	端口有服务在监听	端口开放
RST	端口没有服务	端口关闭
无响应	防火墙拦截或包丢失	无法确定

从抓包中识别 SYN 扫描

快速判断开放/关闭端口的方法：看每个 TCP 会话的包数量。

5 个包的会话：SYN + SYN/ACK + (3次SYN/ACK重传) → 端口开放
2 个包的会话：SYN + RST                           → 端口关闭
1 个包的会话：SYN + (无回应)                       → 端口过滤/不确定

Conversations 窗口示例（按包数量排序）：
端口 22 (SSH)  → 5 个包  → 开放
端口 53 (DNS)  → 5 个包  → 开放
端口 80 (HTTP) → 5 个包  → 开放
端口 25 (SMTP) → 2 个包  → 关闭
端口 113       → 2 个包  → 关闭
端口 443       → 1 个包  → 过滤/不确定

三、操作系统指纹识别

攻击者在不登录目标机器的情况下，通过分析数据包的字段值来猜测目标运行的操作系统。

被动指纹识别 (Passive Fingerprinting)

原理： TCP/IP 协议规范只定义了字段的含义，没有规定默认值，各操作系统自己设定默认值，因此不同系统发出的包有规律性差异。
关键字段：

协议头	字段	Windows 典型值	Linux 典型值
IP	初始 TTL	128	64
IP	不分片标志	设置	设置
TCP	最大段大小 (MSS)	1440~1460	1460
TCP	窗口大小	可变	可变
TCP	SackOK	设置	设置

示例判断：

字段	包1的值	包2的值
初始 TTL	128	64
MSS	1440	1460
窗口大小	64240	2920
结论	Windows	Linux

特点： 只听不发，完全隐蔽。

主动指纹识别 (Active Fingerprinting)

攻击者主动向目标发送精心构造的探测包，根据目标的回应方式判断操作系统。Nmap 就是这么做的。
特点： 会留下流量痕迹，不隐蔽，但准确率更高。

四、流量劫持：ARP 缓存毒化

ARP 协议的本质漏洞

ARP 是"无状态"协议——任何人发来的 ARP 回复都会被接受，不验证真实性。

正常 ARP 流程：
A 广播问：谁有 IP 1.1.1.1 的 MAC？
路由器回复：我有，我的 MAC 是 AA:BB:CC
ARP 毒化：
攻击者对 A 说：1.1.1.1 的 MAC 是我（XX:YY:ZZ）
攻击者对路由器说：A 的 IP 的 MAC 是我（XX:YY:ZZ）
两边都被骗，流量都经过攻击者

中间人攻击 (MITM) 的完整流程

从抓包中识别 ARP 毒化

关键线索：

非广播的 ARP 请求：正常 ARP 请求是广播，但毒化时攻击者单播给目标
无请求的 ARP 回复：没有人问，攻击者主动回复说"IP X 的 MAC 是我"
MAC 地址突变：连续包中，同一个 IP 的 MAC 地址突然变化

包40（正常）：目标 MAC = 00:26:0b:31:07:33 (路由器真实MAC)
            发往 Google 的包
包57（被毒化后）：目标 MAC = 00:25:b3:bf:91:ee (攻击者MAC！)
               发往 Google 的包

五、会话劫持 (Session Hijacking)

HTTP Cookie 的工作原理

用户第一次访问网站
       |
       v
网站发给用户一个 Session ID（会话令牌）
例如：PHPSESSID = ncobrqrb7fj2a2sinddtk567q4
       |
       v
之后每次请求，浏览器自动带上这个 Cookie
网站根据 Cookie 识别用户身份，不需要重复登录

会话劫持的攻击过程

防护建议

使用 HTTPS 加密传输，防止 Cookie 被明文截获。现代网站还会在 Cookie 上设置 HttpOnly 和 Secure 标志，进一步防止劫持。

六、恶意软件分析：Operation Aurora

攻击链全流程

关键技术概念

混淆 (Obfuscation)： 把正常的 JavaScript 代码故意写成看不懂的乱码，逃避杀毒软件检测。
iframe： HTML 中的"内嵌框架"，可以在页面内悄悄加载另一个 URL 的内容，用户看不到。
Shellcode： 漏洞利用成功后执行的机器码，通常用来打开一个 Shell（命令行）供攻击者控制。
反向连接 (Reverse Shell)：

正向 Shell（常被防火墙拦截）：
攻击者 --> 受害者:4321  (被防火墙挡住)
反向 Shell（绕过防火墙）：
受害者 --> 攻击者:4321  (从内到外，防火墙放行)
攻击者在 4321 端口等待，接到连接后就能控制受害者

七、恶意软件分析：CyberEYE 远程访问木马 (RAT)

事件响应流程

IDS 告警：
检测到十六进制字符串 41 4E 41 42 49 4C 47 49 7C
= ASCII 字符串 "ANA BILGI"
= 土耳其语，意为"基本信息"
= CyberEYE RAT 的特征字符串
       |
       v
在 Wireshark 中搜索该十六进制串，定位到数据包
       |
       v
跟踪 TCP 流，分析通信内容

通信协议逆向分析

通过观察流量，反推出 RAT 的命令结构：

攻击者发送：  ANABILGI|556
受害者回应：  计算机名称 + 操作系统版本
受害者持续发：BAGLIMI?  (土耳其语：我已连接？)
攻击者发送：  CAPSCREEN60
（触发截屏并传输）
受害者回应：  ANABILGI|12
             SH|556
             CAPSCREEN|C:\WINDOWS\jpgevhook.dat|84972
             [JPG 文件二进制数据]

命令含义推断：

命令	推测含义
ANABILGI	基本信息请求
BAGLIMI?	心跳包（我在线）
CAPSCREEN	截屏并回传
SH	会话句柄

从流量中提取截图文件（文件雕刻）

JPG 文件有固定的文件头标识：字节序列 FF D8 FF E0。

从 Wireshark 导出的原始数据：
[RAT命令头部数据]  <-- 需要删除这部分
FF D8 FF E0 ...   <-- 从这里开始才是真正的 JPG
[JPG 图像数据]
[JPG 结尾标志 FF D9]

用十六进制编辑器删除 FF D8 FF E0 之前的所有数据，就能还原出截图文件。这个过程叫文件雕刻 (File Carving)。

八、漏洞利用套件 + 勒索软件（Angler + CryptoWall）

感染链完整图解

受害者 192.168.122.145
       |
       | 1. 通过必应搜索访问正常网站
       v
正常网站 113.20.11.49 (sydneygroup.com.au)
（已被黑客植入恶意重定向代码）
       |
       | 2. 页面中嵌入了指向利用套件服务器的重定向
       v
利用套件服务器 45.32.238.202
（Angler Exploit Kit）
       |
       | 3. 检测受害者 Flash 版本，存在漏洞
       | 4. 下发 Flash 漏洞利用文件（文件名无后缀，名称随机）
       v
受害者浏览器执行 Flash Exploit
       |
       | 5. Flash 漏洞被触发，下载第二阶段 payload
       v
恶意文件下载执行（CryptoWall 勒索软件安装）
       |
       | 6. 恶意软件向 C2 服务器报到
       v
C2 服务器 184.170.149.44 / 213.186.33.18
       |
       | 7. 开始加密受害者文件，等待支付赎金
       v
受害者文件被加密，提示支付比特币解锁

C2（命令与控制）通信特征

CryptoWall 的 C2 通信模式：

POST http://homealldaylong.com/76N1Lm.php?x4tk7t4jo6
[少量加密数据]
服务器返回：
HTTP 200 OK
[加密的命令]

识别 C2 流量的特征：

固定的 URL 结构（同一个 PHP 文件）
规律性重复（定期心跳）
参数部分每次不同（传递加密数据）
外连陌生 IP 的 80/443 端口

九、本章所有攻击技术总结

攻击类型	网络特征	检测方法
SYN 扫描	大量 SYN 无 ACK，短时间内扫描多端口	统计单 IP 的 SYN 发起数量
ARP 毒化	无请求的 ARP 回复，MAC 地址突变	监控 ARP 表变化
会话劫持	同一 Cookie 出现在两个不同 IP	HTTPS 加密
RAT	固定字符串，规律性心跳包	IDS 特征匹配
漏洞利用	奇怪的重定向链，下载无后缀文件	IDS 加行为分析
勒索软件 C2	规律性 POST 到固定 PHP 页面	威胁情报匹配

第13章：无线数据包分析

本章从零开始讲解无线网络抓包与分析，涵盖物理层特性、无线网卡模式、802.11数据包结构、无线安全认证等核心内容。

一、为什么无线网络与有线网络不同？

在有线网络中，每台设备都有一根专属的网线连接到交换机，通信是"点对点"的，私密性较好。
而在无线网络中，数据是通过空中无线电波传播的，就像广播电台一样，周围所有人都能"听"到，只是需要知道如何解读信号。这带来了新的挑战：

信号是共享的（大家都在同一片"空气"里通信）
信号容易受干扰
需要加密来保护数据

二、物理层的核心挑战

2.1 每次只能监听一个频道

无线网络使用802.11标准（即Wi-Fi），整个无线频谱被分成若干个信道（Channel）。

在美国，共有 11个信道 可用
每个Wi-Fi接入点（WAP）只占用其中一个信道
抓包工具每次也只能监听一个信道

无线频谱（11个信道）示意：
信道:  1   2   3   4   5   6   7   8   9  10  11
      |---|---|---|---|---|---|---|---|---|---|---|
                      ^
               接入点在信道6
               抓包也必须设置到信道6

比喻理解： 就像收音机，你只能调到一个频率来收听，调到FM98.5就只能听98.5，听不到100.0。

特殊技巧： 有些工具（如 Kismet）支持"信道跳跃（Channel Hopping）"，每秒可以快速切换多达10个信道，相当于快速扫描所有频道，用来发现网络很有用。

2.2 无线信号干扰

无线信号在传播过程中容易受到以下因素干扰：

干扰源	影响
大型金属/反射表面	信号反射、减弱
微波炉	在2.4GHz频段产生强干扰
2.4GHz电话	同频干扰
厚墙/高密度墙体	信号穿透损耗
相邻信道的网络	信道重叠干扰

干扰导致的后果：

丢包（数据包在传输中消失）
重复包（同一包收到多次）
畸形包（数据包内容损坏）

2.3 信道重叠问题

11个信道共享有限的频谱空间（ $\text{ GHz}$ 到 $\text{ GHz}$ ，带宽约 $\text{ MHz}$ ），每个信道占用 $\text{ MHz}$ ，因此相邻信道之间存在重叠：
$MHz\text{总频谱} = 2.483 - 2.402 = 0.081 \text{ GHz} = 81 \text{ MHz}$
$MHz\text{每信道宽度} = 22 \text{ MHz}$
信道重叠示意图：

频率 →
2.402GHz                                          2.483GHz
|←———————————22MHz———————————→|
  [==信道1==]
       [==信道2==]
            [==信道3==]
                 [==信道4==]
                      [==信道5==]
                           [==信道6==]
                                ...
                                         [=信道11=]
推荐使用不重叠的信道组合：1、6、11

结论： 实际部署中，同一区域内的多个Wi-Fi网络应使用 1、6、11 这三个互不重叠的信道。

2.4 如何检测干扰：频谱分析仪

检测无线信号干扰需要用频谱分析仪（Spectrum Analyzer），它可以图形化显示各频段的信号强度。

商业级频谱分析仪价格昂贵（数千美元）
平价方案： MetaGeek公司的 Wi-Spy USB设备 + Chanalyzer软件，可直观显示整个802.11频谱

注意： Wireshark本身无法用来检测信号干扰，它只分析数据包内容。

三、无线网卡的四种工作模式

在抓包之前，需要了解无线网卡（NIC）的四种工作模式：

四种无线网卡模式总览：
+------------------+   +-------------------+
|   托管模式        |   |   Ad Hoc模式       |
|  (Managed Mode)  |   |  (Ad Hoc Mode)    |
|                  |   |                   |
| 客户端 <-> WAP   |   | 设备 <-> 设备     |
|                  |   |（无需接入点）      |
+------------------+   +-------------------+
+------------------+   +-------------------+
|   主模式          |   |   监控模式        |
|  (Master Mode)   |   | (Monitor Mode)    |
|                  |   |                   |
| 电脑扮演WAP角色   |   | 只收听，不发送    |
|（需专用驱动）     |   |（抓包必需模式）   |
+------------------+   +-------------------+

模式	用途	是否常用
托管模式（Managed）	普通用户连接Wi-Fi路由器	最常用
Ad Hoc模式	设备间直连，如两台电脑直接通信	较少用
主模式（Master）	电脑模拟成Wi-Fi接入点	较少用
监控模式（Monitor / RFMON）	被动监听所有无线数据包，不主动收发	抓包必需

关键点： 抓取无线数据包必须将网卡切换到监控模式，否则只能看到自己设备的流量。

硬件推荐（书中提及）： ALFA Network 的无线网卡，性价比高，对监控模式支持良好。

四、在 Windows 下抓取无线数据包

Windows 系统的驱动程序通常不允许网卡切换到监控模式，因此需要借助专用硬件：

AirPcap 设备（Riverbed Technologies）

AirPcap 是一个 USB 设备（外形像U盘），专为 Windows 下的无线抓包设计：

AirPcap 工作流程：
USB接口
  |
  v
AirPcap设备
  |
  v
WinPcap驱动
  |
  v
Wireshark（选择AirPcap接口开始抓包）

AirPcap 可配置选项说明：

配置项	说明
Interface	选择使用哪个AirPcap设备（可接多个）
Channel	选择要监听的信道（如信道6）
Extension Channel	802.11n扩展信道设置
Include 802.11 FCS	是否包含帧校验序列（建议勾选）
Capture Type	802.11 Only / +Radio头 / +PPI头
FCS Filter	过滤掉损坏的帧（建议选Valid Frames）
WEP Configuration	填入WEP密钥，以便解密数据

FCS（帧校验序列）说明：
$FCS=最后4个字节的校验码，用于验证数据包是否在传输中损坏\text{FCS} = \text{最后4个字节的校验码，用于验证数据包是否在传输中损坏}$
Capture Type 三种选项含义：

802.11 Only：只含标准802.11头部
802.11 + Radio：额外包含Radiotap头部（含数据率、频率、信号强度、噪声等）
802.11 + PPI：包含PPI头部（802.11n特有的额外信息）

五、在 Linux 下抓取无线数据包

Linux 下抓包更灵活，直接用系统命令配置网卡即可。

使用 iwconfig 命令

iwconfig 是 Linux 的无线配置工具，类似有线网络的 ifconfig。
第一步：查看当前无线接口状态

# 查看所有网络接口的无线配置
iwconfig

输出示例（含详细中文注释）：

# 输出解读：
Eth0    no wireless extensions   # Eth0 没有无线功能（有线网卡）
Lo0     no wireless extensions   # Lo0 是回环接口，也没有无线功能
Eth1    IEEE 802.11g             # Eth1 是无线网卡，使用802.11g协议
        ESSID: "Tesla Wireless Network"  # 当前连接的Wi-Fi名称
        Mode: Managed            # 当前是托管模式（普通连接模式）
        Frequency: 2.462 GHz     # 当前频率（对应信道11）
        Access Point: 00:02:2D:8B:70:2E  # 接入点的MAC地址
        Bit Rate: 54 Mb/s        # 当前数据速率
        Signal level=-71 dBm     # 信号强度（越接近0越强）
        Noise level=-86 dBm      # 噪声水平

第二步：切换到监控模式（需要root权限）

# 切换到root用户
su
# 输入root密码
# 将Eth1切换到监控模式
iwconfig eth1 mode monitor
# 启动Eth1接口
iwconfig eth1 up
# 切换到指定信道（例如信道3）
iwconfig eth1 channel 3

提示： Linux下可以在抓包过程中动态切换信道，也可以写脚本自动切换，非常灵活。
第三步：启动Wireshark开始抓包
配置完成后，直接打开Wireshark，选择Eth1接口即可开始抓包。

六、802.11 数据包结构

与有线网络的以太网帧相比，802.11数据包在数据链路层（OSI第2层）增加了额外的头部信息。

6.1 三种数据包类型

802.11数据包分类：
                  802.11数据包
                       |
        +--------------+--------------+
        |              |              |
   管理包(Management)  控制包(Control)  数据包(Data)
        |              |              |
   负责建立和          负责传输控制       携带实际
   维护连接            和拥塞管理        用户数据
        |
   包含子类型：
   - 认证（Authentication）
   - 关联（Association）
   - 信标（Beacon）
   - 解除认证（Deauthentication）
   ...

类型	作用	典型子类型
管理包（Management）	建立/维护设备间连接	信标、认证、关联、探测请求
控制包（Control）	协助数据传输、拥塞控制	RTS（请求发送）、CTS（清除发送）、ACK
数据包（Data）	承载真实数据，可跨网络转发	QoS数据、空数据帧

6.2 信标包（Beacon）——最信息丰富的管理包

信标包的作用：接入点（WAP）定期向周围广播自己的存在，告诉附近设备：“我在这里，这是我的参数，欢迎连接我。”
信标包中的关键字段：

字段	含义
Timestamp	发送时的时间戳
Beacon Interval	信标包的重复发送间隔
Capabilities Information	WAP的硬件能力信息
SSID parameter set	Wi-Fi网络名称（SSID）
Supported Rates	WAP支持的数据传输速率
DS Parameter set	WAP工作的信道号
源/目标地址	MAC地址
厂商信息	生产厂商的特定信息

从信标包能读出什么： 设备品牌（如D-Link）、使用的802.11版本（如802.11b）、工作信道（如信道11）。

七、Wireshark 无线专用列

在Wireshark的"数据包列表"面板中，可以添加三个无线专用列：

列名	过滤器字段	作用
Channel（信道）	`wlan_radio.channel`	显示数据包来自哪个信道
Signal Strength（信号强度）	`wlan_radio.signal_dbm`	显示信号强度（dBm）
Data Rate（数据率）	`wlan_radio.data_rate`	显示传输速率

添加步骤：

Edit → Preferences
进入 Columns 部分，点击 +
Title填列名，Type选 Custom，Field Name填对应过滤器字段
点击 OK 保存

实用价值： 即使客户端软件显示"信号良好"，通过抓包查看 Signal Strength 列，可能发现实际信号质量很差，从而找到连接问题的真正原因。

八、无线专用过滤器

8.1 按BSS ID过滤（只看某个接入点的流量）

BSS ID（基本服务集标识符）是每个WAP的唯一标识，相当于Wi-Fi接入点的"身份证"。

# Wireshark过滤语法
wlan.bssid == 00:11:22:33:44:55
# 替换为目标WAP的MAC地址，即可只显示该接入点的数据

8.2 按数据包类型过滤

# 过滤所有管理帧
wlan.fc.type == 0
# 过滤所有控制帧
wlan.fc.type == 1
# 过滤所有数据帧
wlan.fc.type == 2

8.3 按子类型过滤（常用汇总）

帧类型	Wireshark过滤器
关联请求	`wlan.fc.type_subtype == 0x00`
关联响应	`wlan.fc.type_subtype == 0x01`
探测请求	`wlan.fc.type_subtype == 0x04`
探测响应	`wlan.fc.type_subtype == 0x05`
信标	`wlan.fc.type_subtype == 0x08`
认证	`wlan.fc.type_subtype == 0x0B`
取消认证	`wlan.fc.type_subtype == 0x0C`
请求发送(RTS)	`wlan.fc.type_subtype == 0x1B`
清除发送(CTS)	`wlan.fc.type_subtype == 0x1C`
ACK确认	`wlan.fc.type_subtype == 0x1D`
空数据帧	`wlan.fc.type_subtype == 0x24`
QoS数据	`wlan.fc.type_subtype == 0x28`

8.4 按信道过滤

# 只显示信道11上的流量
wlan_radio.channel == 11
# 把11替换成你想过滤的信道号

应用场景： 如果网络设计上只应该有信道1和信道6的流量，却发现信道11有数据，说明可能存在配置错误或非法设备接入。

九、保存无线配置档案（Profile）

每次分析无线数据包都需要重新配置列和过滤器，很繁琐。Wireshark支持保存自定义配置档案（Profile）：
保存步骤：

配置好所有无线专用列和过滤器
右键点击屏幕右下角的当前配置档案名称
点击 New，命名为 Wireless，点击 OK
以后切换到无线分析时，直接切换到"Wireless"档案即可，无需重复配置。

十、无线网络安全协议分析

无线数据在空中传播，任何有Wireshark和AirPcap的人都可能截获。因此加密至关重要。

10.1 三种主要安全协议对比

安全协议演进：
WEP（有线等效加密）
  |
  | 发现严重漏洞（密钥管理缺陷）
  v
WPA（Wi-Fi保护访问）
  |
  | 更强安全性
  v
WPA2（更安全）

协议	安全性	状态
WEP	较弱，密钥管理有缺陷	已淘汰
WPA	中等，改进了WEP的问题	仍在使用
WPA2	较强	当前主流

注意： 即使使用了SSL或SSH等上层加密，无线信道上这层数据仍然安全，因为数据在更高层已被加密，只是无线层的头部可见。

10.2 WEP 认证流程分析

WEP认证的核心思想： 用一个共享的"密码"（WEP密钥）来验证客户端是否有权接入。

成功的WEP认证流程

WEP认证流程（"挑战-响应"机制）：
时间轴 →
  WAP                           无线客户端
   |                                |
   |  [数据包3]                      |
   |  ——发送挑战文本（随机数据）——>   |
   |                                |  客户端用WEP密钥解密挑战
   |  [数据包4]                      |
   |  <——返回解密后的挑战文本————    |
   |                                |
   |  WAP验证：解密结果正确？
   |
   |  [数据包5]
   |  ——通知认证成功——>              |
   |                                |
   |  [数据包6-7]  关联请求+响应     |
   |  <———————————————————————>    |
   |                                |
   |         连接建立！              |

每一步说明：

数据包3： WAP发送一段随机的挑战文本给客户端
数据包4： 客户端用用户输入的WEP密钥解密挑战文本，将结果返回给WAP
数据包5： WAP比对结果，若正确则通知"认证成功"
数据包6-7： 完成关联请求和响应，连接正式建立

失败的WEP认证流程

当用户输入了错误的WEP密钥时：

WEP认证失败流程：
  WAP                           无线客户端
   |                                |
   |  [数据包3]                      |
   |  ——发送挑战文本——>              |
   |                                | 用错误密钥解密，结果不对
   |  [数据包4]                      |
   |  <——返回错误的解密结果————      |
   |                                |
   |  WAP验证：结果不匹配！
   |
   |  [数据包5]
   |  ——通知认证失败——>              |
   |                                |
   |         连接终止！              |

诊断方法： 在Wireshark中查看数据包5的内容，若显示认证失败，说明WEP密钥输入错误。

10.3 WPA 认证流程分析

WPA使用了不同于WEP的认证机制——四次握手（Four-way Handshake）：

成功的WPA认证流程

WPA认证流程：
  WAP                           无线客户端
   |                                |
   |  [数据包1]                      |
   |  ——信标广播（宣告支持WPA）——>   |
   |                                |
   |  [数据包2-3]                    |
   |  <——探测请求/响应————>         |
   |                                |
   |  [数据包4-7]                    |
   |  <——认证+关联请求/响应————>    |
   |                                |
   |         WPA四次握手开始         |
   |  [数据包8]  挑战1               |
   |  ——————>                       |
   |  [数据包9]  响应1               |
   |  <————                         | Replay Counter = 1
   |  [数据包10] 挑战2               |
   |  ——————>                       |
   |  [数据包11] 响应2               |
   |  <————                         | Replay Counter = 2
   |                                |
   |       握手完成，认证成功！       |
   |       开始数据传输              |

Replay Counter字段的作用：
$Counter=用于配对握手中的挑战和响应，防止重放攻击\text{Replay Counter} = \text{用于配对握手中的挑战和响应，防止重放攻击}$

Replay Counter = 1 → 第一对挑战/响应
Replay Counter = 2 → 第二对挑战/响应

注意： 本例使用的是 WPA + TKIP 加密。不同的WAP可能使用不同加密方式（如AES/CCMP），握手细节可能有所不同。

失败的WPA认证流程

当WPA密钥错误时，握手会重复尝试4次，然后终止：

WPA认证失败流程：
  WAP                           无线客户端
   |                                |
   |      ... 探测/认证/关联 ...    |
   |                                |
   |      第1次握手尝试             |
   |  [包8]  ——>                   |
   |  [包9]  <——（密钥错误）        |
   |                                |
   |      第2次握手尝试             |
   |  [包10] ——>                   |
   |  [包11] <——（密钥错误）        |
   |                                |
   |      第3次握手尝试             |
   |  [包12] ——>                   |
   |  [包13] <——（密钥错误）        |
   |                                |
   |      第4次握手尝试             |
   |  [包14] ——>                   |
   |  [包15] <——（密钥错误）        |
   |                                |
   |  [包16] 客户端发送Deauth解除认证|
   |  ————>                        |
   |                                |
   |         连接失败！              |

诊断标志：在Wireshark中看到8个EAPoL（Extensible Authentication Protocol over LAN）握手包（正常成功是4个），说明WPA认证失败，最后还会看到客户端主动发送Deauthentication（解除认证）数据包。

现象	含义
WPA握手包有4个	认证成功
WPA握手包有8个（重复2组）	认证失败，密钥错误
出现Deauthentication包	客户端主动断开连接

十一、整体流程总结

无线抓包完整流程：
1. 确认目标网络的工作信道
         |
         v
2. 配置无线网卡为监控模式
   - Windows: 使用AirPcap设备
   - Linux: iwconfig eth1 mode monitor
         |
         v
3. 将网卡/AirPcap设置到目标信道
   - Windows: AirPcap配置程序
   - Linux: iwconfig eth1 channel 6
         |
         v
4. 启动Wireshark，选择监控接口
         |
         v
5. 添加无线专用列（信道/信号强度/数据率）
         |
         v
6. 使用过滤器定位目标流量
   - 按BSS ID过滤
   - 按包类型过滤
   - 按信道过滤
         |
         v
7. 分析数据包（认证流程、安全问题等）

十二、关键词速查表

术语	全称	含义
WAP	Wireless Access Point	无线接入点（路由器）
WLAN	Wireless Local Area Network	无线局域网
BSS ID	Basic Service Set Identifier	接入点的唯一标识（MAC地址）
SSID	Service Set Identifier	Wi-Fi网络名称
FCS	Frame Check Sequence	帧校验序列，用于检测数据损坏
WEP	Wired Equivalent Privacy	有线等效加密（已淘汰）
WPA	Wi-Fi Protected Access	Wi-Fi保护访问
RFMON	Radio Frequency MONitor	射频监控模式，即监控模式
EAPoL	Extensible Authentication Protocol over LAN	局域网上的可扩展认证协议
TKIP	Temporal Key Integrity Protocol	临时密钥完整性协议（WPA加密方式）
PPI	Per-Packet Information	每包信息头（802.11n）
dBm	Decibel-milliwatts	信号强度单位，负值越大信号越弱

openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

别再搞混堆和栈！C 语言内存管理与位运算完整学习笔记

openEuler 社区

Raspberry Pi Compute Module 5 Programming Jig (CM5 烧录夹具）正式发售！

openEuler 社区

2026工业物联网底层解构：5G大带宽下的边缘计算网关高并发异步架构实战

openEuler 社区

所有评论(0)

查看更多评论

虾球xz

@TM1695648164

已为社区贡献46条内容

PRACTICAL PACKET ANALYSIS学习:第10章：真实网络故障分析案例 — 深度中文解读

虾球xz

一、网络分析的基本方法论

二、案例1：ESPN 网页内容缺失

背景

分析过程

第一步：查看 HTTP 请求

第二步：查看协议层次

第三步：查看 IP 会话 (Conversations)

异常发现： 理应是 7 个 IP 会话，实际上是 8 个！ 多出来的会话：

第四步：深入分析该异常会话

第五步：找根本原因

解决方法

经验总结

三、案例2：气象站停止上报数据

背景

网络拓扑

分析过程

HTTP GET 请求结构

服务器响应

安全警示

解决方法

四、案例3：无法访问互联网（三个子场景）

子场景 A：网关配置错误

正常访问互联网的流程

故障现象

根本原因

子场景 B：hosts 文件被篡改

故障现象

DNS 解析优先级

子场景 C：上游服务器故障

故障现象

分析

五、案例4：打印机间歇性中断

故障现象

TCP 数据传输正常流程

TCP 重传机制说明

故障定位

六、案例5：分支机构无法访问总部应用

网络拓扑

DNS 主从同步原理

故障排查过程

区域传输的 TCP SYN 没有得到回应。第三步：分析总部路由器 总部路由器配置了防火墙规则：

解决方法

七、案例6：数据损坏责任归因

背景

验证方法：文件哈希对比

操作方法

八、六个案例的对比总结

第11章：对抗慢速网络 — 深度中文解读

一、核心概念：延迟 (Latency)

二、TCP 错误恢复机制之一：重传 (Retransmission)

原理

重传超时的计算（指数退避）

最大重传次数

重传超时的确定方式

三、TCP 错误恢复机制之二：重复 ACK 与快速重传

序列号与确认号的关系

当数据包丢失时

关键规则

SACK（选择性确认）

四、TCP 流量控制：滑动窗口 (Sliding Window)

为什么需要流量控制？

接收窗口 (Receive Window)

窗口动态调整

零窗口 (Zero Window)：紧急刹车

三种窗口状态对比

五、定位高延迟来源：六包分析法

正常通信的 6 个包

类型1：网线延迟 (Wire Latency) — 中间设备的锅

类型2：客户端延迟 (Client Latency) — 客户端的锅

类型3：服务器延迟 (Server Latency) — 服务器的锅

六包定位框架

六、网络基线 (Network Baseline)

什么是基线？

三类基线

各类基线说明

基线采集的注意事项

七、本章全貌：排查慢速网络的决策树

八、三种 TCP 异常包的对比

异常发现：理应是 7 个 IP 会话，实际上是 8 个！
多出来的会话：

区域传输的 TCP SYN 没有得到回应。
第三步：分析总部路由器
总部路由器配置了防火墙规则：

原理： TCP/IP 协议规范只定义了字段的含义，没有规定默认值，各操作系统自己设定默认值，因此不同系统发出的包有规律性差异。
关键字段：

信标包的作用：接入点（WAP）定期向周围广播自己的存在，告诉附近设备：“我在这里，这是我的参数，欢迎连接我。”
信标包中的关键字段：

诊断标志：在Wireshark中看到8个EAPoL（Extensible Authentication Protocol over LAN）握手包（正常成功是4个），说明WPA认证失败，最后还会看到客户端主动发送Deauthentication（解除认证）数据包。