Wireshark TS | Packet Challenge 之 TCP 重传案例分析

2022年11月7日14:32:27评论23 views字数 4500阅读15分0秒阅读模式

Occam's Razor, Ockham's Razor

前言

来自于 Sharkfest Packet Challenge 中的一个数据包案例，Sharkfest 是 Wireshark 官方组织的一年一度的大会，致力于在 Wireshark 开发人员和用户社区之间分享知识、经验和最佳实践。印象中早期是一年一次，近几年发展成一年两次，一次貌似固定在美国，一次会在其他地区，像是欧洲或亚洲。Packet Challenge 是大会其中一个比较有意思的活动环节，通过一系列数据包案例设置关卡，参会人员进行分析挑战，测试综合分析能力。

题目信息

本次案例为 Sharkfest 2019 EU Packet Challenge 中的第三个题目 Do it Yourself，数据包跟踪文件为 DIY.pcapng 。

主要描述如下：

A developer programmed a microcontroller to send data via TCP. Something looks bad though…

1. What is the largest segment size that will work for both client and server?

2. Where was the capture taken (Client local/SPAN/TAP/Server local)?

3. What is the initial round trip time of the connection?

4. How many router hops are between client and server?

5. Why does the transmission of TCP data from 192.168.0.2 to 192.168.0.1 fail?

数据包信息

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

λ capinfos DIY.pcapngFile name:           DIY.pcapngFile type:           Wireshark/... - pcapngFile encapsulation:  EthernetFile timestamp precision:  microseconds (6)Packet size limit:   file hdr: (not set)Number of packets:   1210File size:           1555 kBData size:           1499 kBCapture duration:    4.495727 secondsFirst packet time:   2017-03-27 19:02:12.959401Last packet time:    2017-03-27 19:02:17.455128Data byte rate:      333 kBpsData bit rate:       2667 kbpsAverage packet size: 1238.93 bytesAverage packet rate: 269 packets/sSHA256:              4385a9ded3fdc9c7fa0c3015323ed6df10fb68e38dba07210ec0588bd65a5febRIPEMD160:           53562636f5037964e8b6a0bccb2cbf7648895e31SHA1:                a0295d1e0ff87f0e4135f4bf1a87422ff562fc04Strict time order:   TrueCapture application: Sanitized by TraceWrangler v0.6.6 build 928Number of interfaces in file: 1Interface #0 info:                     Name = DeviceNPF_{83DAFA6D-086A-4B8B-AA1D-562D69913D39}                     Encapsulation = Ethernet (1 - ether)                     Capture length = 262144                     Time precision = microseconds (6)                     Time ticks per second = 1000000                     Time resolution = 0x06                     Operating system = 64-bit Windows 10, build 14393                     Number of stat entries = 0                     Number of packets = 1210

在 Win10 系统上通过 Wireshark 捕获，无截断，捕获数据包数量 1210 个，捕获持续时间为 4.49 秒，平均速率 2667 kbps ，并经过 TraceWrangler 匿名化工具编辑过。

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

会话信息显示如下，仅有一条 TCP 会话。

Wireshark TS | Packet Challenge 之 TCP 重传案例分析

专家信息如下，可以看到有非常多数量的快速重传、重传以及 Dup ACK 信息，占比很高。

数据包分析

展开数据包文件信息，如下，可以看到确实有很多的重传信息，从 No.11 到最后 No.1210 全是如此。

1. What is the largest segment size that will work for both client and server?

对于客户端和服务器来说，最大的段大小是多少?

分析步骤

Segment 自然指的是 TCP Segment，可以通过增加 tcp.len 列，从大到小排序查看，该值也会体现在 Info 列 Len 值。

λ tshark -r DIY.pcapng -Y "tcp.len" -T fields -e tcp.len | sort -rn | uniq14607350

分析答案

对于客户端和服务器来说，最大的段大小是：1460 。

2. Where was the capture taken (Client local/SPAN/TAP/Server local)?

捕获是在哪里进行的(客户端本地/SPAN/TAP/服务器本地)?

分析步骤

在数据包列表上通过 Length 列中的信息可知答案，因为 54 字节小于以太网最小长度 60 字节的标准，所以判断数据包捕获是在客户端 192.168.0.1 上所进行。

因为 Wireshark 抓包位置如果是在本地，那么对于本地产生所发出的数据包，Wireshark 是在进网卡之前所抓取，而填充数据以及 FCS 一般是由网卡硬件/驱动程序完成，所以 54 字节的组成并不包含填充数据，即意味着本地抓取。

关于拿到一个数据包跟踪文件，如何判断捕获是在哪里，相关的技术文章可参考《Wireshark 提示和技巧 | 捕获点之 TCP 三次握手》。

分析答案

捕获是在哪里进行的(客户机本地/SPAN/TAP/服务器本地)?：客户端本地。

3. What is the initial round trip time of the connection?

连接的初始往返时间(IRTT)是多少？

分析步骤

Initial Round Trip Time（IRTT），即该 TCP 流中起始 TCP 三次握手的时间。

当然这个 IRTT 值也会在这条 TCP 流中的绝大多数数据包中标识有。

λ tshark -r DIY.pcapng -Y "tcp.analysis.initial_rtt" -T fields -e tcp.analysis.initial_rtt | sort | uniq0.001735000

分析答案

连接的初始往返时间(IRTT)是多少？：0.001735 秒。

4. How many router hops are between client and server?

客户端和服务器之间有多少路由跳数?

分析步骤

在网络中，数据包每过一个路由设备，TTL 值减 1 。在 2 题中确认了是在客户端本地所抓取的包，这样查看 No.2 SYN/ACK 数据包的 TTL 值即可。

λ tshark -r DIY.pcapng -Y "frame.number==2" -T fields -e ip.ttl100

分析答案

客户端和服务器之间有多少路由跳数?：28 。

5. Why does the transmission of TCP data from 192.168.0.2 to 192.168.0.1 fail?

为什么从 192.168.0.2 到 192.168.0.1 的 TCP 数据传输失败?

分析步骤

从数据包跟踪文件的捕获点来说，这个问题可以说是为什么客户端 192.168.0.1 没有接受服务器端 192168.0.2 所发送的数据？

a. 现象

在 TCP 三次握手成功之后，No.4-No.10 服务器所发送的数据分段，客户端并没有接收，而是产生了一个 No.11 ACK 数据包仍请求服务器 Seq Num 1 的分段，之后服务器依次产生超时重传，但客户端仍未接受相应数据包，再之后不断循环该过程直至整个跟踪文件结束。

b. 可能原因

TCP CHECKSUM INCORRECT

问题比较诡异，可能是 No.4-No.10 数据分段有问题，尝试打开 TCP 协议中 Validate the TCP checksum if possible 选项，会发现出现了大量 TCP CHECKSUM INCORRECT 告警信息。

客户端 TCP CHECKSUM INCORRECT，首先客户端 TCP checksum 并不是问题。这是因为数据包是在客户端本地捕获，由于是网卡 CheckSum Offload 功能执行TCP/UDP/IP 校验和工作，所以 Wireshark 捕获时的客户端数据包的 TCP 校验和是随机填充的，因此校验和会提示不正确；
服务器端 TCP CHECKSUM INCORRECT，No.4 - No.9 数据分段校验和不正确，因此客户端协议栈未正常接收，而 No.10 数据分段校验和正常，客户端协议栈正常接收，但由于与期望 Seq Num 不一致，所以触发 No.11 客户端 DUP ACK。

以上为 TCP CHECKSUM INCORRECT 疑似原因的解释，符合数据包现象，但该答案并不一定准确，主要是该题目提供的信息很少，不能完全确认校验和问题是否是匿名化软件编辑数据包引发的额外不相关的问题（所有检验和都仅相差 1，譬如 No.4 校验和 0x07f5 不正确，0x07f4 正确）。

同样关于数据包 TCP Checksum ，相关的技术文章也可参考《Wireshark 提示和技巧 | 捕获点之 TCP 三次握手》。

IPTABLES

iptables 也有可能是导致该问题现象的原因。譬如匹配报文特定长度，阻断了 No.4 - No.9 数据分段（TCP Length 1460 字节），而接收了 No.10 数据分段（TCP Length 735 字节），进而触发 TCP DUP ACK，此后不断循环上述过程。

分析答案

为什么从 192.168.0.2 到 192.168.0.1 的 TCP 数据传输失败?：TCP 校验和或者 IPTABLES 。

往期推荐

1. Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

2. Wireshark 提示和技巧 | a == ${a} 显示过滤宏

3. Wireshark TS | Slow Slow Slow Web

4. Wireshark TS | 消失的 TCP DUP ACK

5. 网络设备 MTU MSS Jumboframe 全解

后台回复「TT」获取 Wireshark 提示和技巧系列 合集

后台回复「TS」获取 Wireshark Troubleshooting 系列 合集

如需交流，可后台直接留言，我会在第一时间回复，谢谢！

原文始发于微信公众号（Echo Reply）：Wireshark TS | Packet Challenge 之 TCP 重传案例分析

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。

左青龙
微信扫一扫

右白虎
微信扫一扫

Wireshark TS | Packet Challenge 之 TCP 重传案例分析

分析答案

分析答案

利用虚假 GIF 进行多阶段反向代理卡盗刷攻击

挖洞日记 | 某高校旁站到统一认证, 怒刷30+rank

LetMeowIn - 凭证转储程序分析

CVE-2025-24054 遭受主动攻击 - 文件下载时窃取 NTLM 凭证

【渗透测试】doubletrouble: 1靶场渗透测试

Telnet 渗透测试（端口 23）

分享常见的逻辑漏洞挖掘方法（第二部分）

同步漏洞行动：朝鲜Lazarus APT组织针对韩国供应链发起攻击

Vulnhub-zico2靶机教学

使用 PowerShell 中的动态 API 解析绕过 AMSI

发表评论

在线咨询

微信