Wireshark TS | TCP 握手异常问题

前言

关于网络协议分析,我们经常会接触一些各式各样的数据包跟踪文件,有标准协议报文用于研究的,有排查故障分析使用的等等。

就我个人来说,也总会从互联网收集一些数据包案例,有时会在这些跟踪文件中查找问题,试着找出一些看起来不太正常的东西,并尝试分析可能的影响 。当然,很多时候由于多方面资源的缺失,部分跟踪文件的问题已无法得到一个明确的答案,但可以观察数据包的不同交互行为,尝试找到一个合理的解释。

该数据包案例来自于 Wireshark sharkfest 2017,一些简短但有趣的 TCP 跟踪文件中的一个。


问题信息

数据包跟踪文件基本信息如下:

λ capinfos Sample01.pcapng
File name:           Sample01.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Packet size limit:   inferred: 54 bytes - 59 bytes (range)
Number of packets:   15
File size:           1756 bytes
Data size:           1504 bytes
Capture duration:    4.328701 seconds
First packet time:   2013-01-22 07:09:21.023257
Last packet time:    2013-01-22 07:09:25.351958
Data byte rate:      347 bytes/s
Data bit rate:       2779 bits/s
Average packet size: 100.27 bytes
Average packet rate: 3 packets/s
SHA256:              ea32270673ebc233e8229118bce6a8e522a4920d53fbe780a906f20f76e4ddd9
RIPEMD160:           dfc99ad2ea5826ebf361ce9a376d11ef85628976
SHA1:                9d11a1f96469a6e3002dcb4c21054e2bb542f950
Strict time order:   True
Capture application: Sanitized by TraceWrangler v0.6.4 build 806
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{2EE03F8E-3C66-48E3-86B3-6AD1273BCD6B}
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = Windows XP Service Pack 3, build 2600
                     Number of stat entries = 0
                     Number of packets = 15

数据包数量并不多,仅有 15 个,捕获持续时间为 4.3 秒,平均速率 2779 bit/s,在 Win XP 上通过 Wireshark 捕获,并经过 TraceWrangler 匿名化软件所处理。

关于 TraceWrangler 匿名化软件简介,可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》

这里比较特别的地方是 Packet size limit: inferred: 54 bytes - 59 bytes (range) ,通常来说根据 snaplen 做截断,应该是一个统一的数值,也就是所有的数据包捕获长度应该是一样的,而不是一个范围值,但确实也不排除有些数据包做过特殊处理。

专家信息如下,这其中也会有一些很奇怪的信息,包括 The non-SYN packet does contain a MSS option ,非 SYN 的数据包包含有 MSS 信息,感觉要么是一个错误的 TCP 协议栈实现,要么是人为伪造的数据包。

Wireshark TS | TCP 握手异常问题_第1张图片


问题分析

展开完整的数据包文件信息,如下

Wireshark TS | TCP 握手异常问题_第2张图片

首先查看捕获帧长度的问题,增加 Capture Length列,对比可知在 No.7、No.9 和 No.10 均存在捕获长度小于实际帧长度的地方,并且有两个值,54 和 59 ,确实如 capinfos 的提示信息一样,Packet size limit: inferred: 54 bytes - 59 bytes (range) ,此处初步判断是人为编辑过数据包跟踪文件。

Wireshark TS | TCP 握手异常问题_第3张图片

其次 Warning 问题 The non-SYN packet does contain a MSS option ,除了 No.1 - No.4 的 TCP 三次握手之外,确实在 No.5 和 No.6 也就是 Server 192.168.0.101 发送的两个 ACK 存在 MSS 1460 的信息,理论上来说,MSS 通告信息仅存在于 TCP 三次握手建立连接的环节。如上所述,这并不是一个正常的 TCP 协议栈实现,结合捕获长度的问题,再加上是 sharkfest 的故障案例分析,我觉得大概率此跟踪文件是人为伪造的数据包,以做案例分析使用。

Wireshark TS | TCP 握手异常问题_第4张图片

既然是案例分析,那么我们进一步分析是否还有其他的问题存在。

HS-05

TCP 三次握手环节还存在此许问题,主要分析如下:

  1. 客户端 192.168.0.1 和服务器 192.168.0.101 的 TCP 三次握手实际由 No.2 - No.4 三个数据包完成,RTT 2ms。
  2. No.1 由客户端 192.168.0.1 所发送的第一个 SYN,由于网络或者服务器的关系,服务器并没有正常接收。结合后面的交互,实际上可判断为服务器的问题,性能或者其他问题并没有回应 SYN/ACK;
  3. No.2 为客户端 192.168.0.1 No.1 SYN 发送超时后,第一个重传包,重传超时时间为 3 秒;
  4. No.3 由服务器 192.168.0.101 响应的 SYN/ACK,对应于 No.2 SYN,理论上 No.1 SYN 在网络上不应该存活这长时间,但这里存在一个 Win=0 的状态,意味着服务器此时接收窗口为 0; 开局即空血
  5. 之后在 TCP 三次握手完成后,客户端也并没有一些主动的请求数据,而 No.5 服务器仍因为 Win = 0 零窗口问题,主动通知了一个 TCP ZeroWindow 消息,而在过了 1.3 秒之后,接收窗口才打开了部分,进行了 TCP Window Update Win = 2048 的通知消息。

问题总结

奇怪的数据包,有趣的案例,估摸只有数据包的创建者才知道如何创造或是得来的了吧,未知答案就不纠结了,下一个案例见~

你可能感兴趣的:(NetShark,wireshark,tcp/ip,网络,网络协议,tcpdump)