Wireshark TS | 二谈 TCP 握手异常问题

admin 2022年6月27日00:57:00安全闲碎评论4 views2952字阅读9分50秒阅读模式

TCP 三次握手的学问多之又多


前言

继续以一个实际案例来说下 TCP 握手问题,该数据包仍然来自于 Wireshark sharkfest 2017,一些简短但有趣的 TCP 跟踪文件中的又一个。
当然产生 TCP 握手异常的原因会有很多,一方面限于自己所掌握的知识程度,某些方面的知识点掌握和理解上还是会有所欠缺,分析自然会不到位,另外一方面也是老生常谈的问题,大多数的实际案例并不是亲身经历,缺少基础环境以及进一步分析可能需要的资源,像是多点捕获的对比、正常和异常现象的对比、模拟测试复现异常验证等等,所以有时候我不得不成为一个“猜测”的工程师,模糊根因。

问题信息

数据包跟踪文件基本信息如下:
λ capinfos Sample02.pcapngFile name: Sample02.pcapngFile type: Wireshark/... - pcapngFile encapsulation: EthernetFile timestamp precision: microseconds (6)Packet size limit: file hdr: (not set)Number of packets: 6File size: 836 bytesData size: 350 bytesCapture duration: 2.965008 secondsFirst packet time: 2013-11-18 18:21:28.059918Last packet time: 2013-11-18 18:21:31.024926Data byte rate: 118 bytes/sData bit rate: 944 bits/sAverage packet size: 58.33 bytesAverage packet rate: 2 packets/sSHA256: 00339945b951259fe0656842cda513f40dc412c816bda66578d4d06ce350314bRIPEMD160: c4bfddc2f23c078def1ad98153b56d41d20b012aSHA1: dd148ec87dc6b9714fc6dac5c583e4ffcc2ea4e5Strict time order: TrueCapture application: Sanitized by TraceWrangler v0.6.4 build 806Number of interfaces in file: 1Interface #0 info: Name = DeviceNPF_{C09F8401-EC02-4BA6-9EA3-C9B992ECC7CF} 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 = 6

数据包数量并不多,仅有 6 个,捕获持续时间为约 3 秒,平均速率 944 bits/s,在 Win XP 上通过 Wireshark 捕获,并经过 TraceWrangler 匿名化软件所处理,其他并没有什么特别的地方。
关于 TraceWrangler 匿名化软件简介,可以查看之前的文章。
7ACE,公众号:Echo ReplyWireshark 提示和技巧 | 如何匿名化数据包


专家信息如下,同样因数据包很少,也没有些特别的提示,仅仅有一条 Warning RST 信息。
Wireshark TS | 二谈 TCP 握手异常问题


问题分析

展开完整的数据包文件信息,如下
Wireshark TS | 二谈 TCP 握手异常问题

数据包 No.1-2
  1. ARP 请求和 ARP 响应,从 Info 信息上也可以看出是之后的客户端 192.168.0.1 请求服务器端 192.168.0.101 的 mac 地址;
  2. 比较特别的是间隔时间,有 49ms 之多,了解网络的同学可能会更加清楚,ARP 请求和响应是出现在同一网段内的,49ms 时延的距离,两者真的是离得很远了;当然也有可能是服务器端性能问题响应数据包慢,不完全否定,但是结合以下 TCP 三次握手的时延,并不作为可能原因;

Wireshark TS | 二谈 TCP 握手异常问题

  1. 数据包是在客户端 192.168.0.1 上所捕获,因为 Length 为 42 字节,小于以太网数据帧最小长度 60 字节的要求。
关于如何判断捕获点的说明,请查看之前的文章《捕获点之 TCP 三次握手》,哈哈 确实算本人写的很用心的一篇技巧文章。
7ACE,公众号:Echo ReplyWireshark 提示和技巧 | 捕获点之 TCP 三次握手


数据包 No.3-6
Wireshark TS | 二谈 TCP 握手异常问题

  1. 数据包 No.3-4,为标准的 TCP 三次握手中的前两次,RTT 45ms ,MSS 1460 ,均支持 SACK ;
  2. 数据包 No.5,正常来说应该是客户端 192.168.0.1 发送 TCP 三次握手中的最后一个 ACK,但是在这里却是客户端 192.168.0.1 在第一个 SYN 超时间隔 3s 后所发送的 SYN 重传包。
    这里就会比较奇怪了,首先客户端完全忽略了服务器的 SYN/ACK,而且如上所述数据包跟踪文件是在客户端本身上所捕获,所以问题的原因就指向了客户端本身,在系统或是网卡硬件某个层面丢弃了 SYN/ACK
    而因为客户端忽略了 SYN/ACK,所以在大约 3s 之后客户端重传了 SYN,这个也没有问题,在 linux 系统上关于 SYN 的超时重传时间确实有 1 秒和 3 秒两种;
  3. 数据包 No.6,是服务器 192.168.0.101 所发送的 RST 数据包。在这里服务器实现也会有些许问题,如果在 No.5 客户端 SYN 重传的情况下,服务器如果接收到这个重传包,正常情况下同样会响应一次 SYN/ACK,而不是响应 RST 数据包。
    甚至在某些情况下,客户端会在这个 SYN 重传数据包之后收到两个 SYN/ACK 数据包,这是为什么?因为服务器 SYN/ACK 也会有超时重传的设置,如果服务器在客户端所发送的 SYN 重传数据包到达之前,No.2 SYN/ACK 先超时了,那么服务器就会先重传发送一次 SYN/ACK , 紧接着客户端 SYN 重传数据包到来,又触发产生一次 SYN/ACK,所以最终客户端会再收到两个 SYN/ACK 数据包。

问题总结

综上所述,这个不成功连接的案例,并不只是一个不稳定的连接,包括客户端和服务器双方面都会有一些不同寻常的现象。
当然一方面是真的有问题,另一方面可能是不同系统内核实现不一样,进而产生的一些附加现象。甚至说在协议栈测试工具以及数据包编辑工具的存在下,这是否是一个真实的案例也说不好。
仅仅是 6 个数据包,带给我们的思考却很多很多。


Wireshark TS | 二谈 TCP 握手异常问题


往期推荐


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

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

3. Wireshark TS | Slow Slow Slow Web

4. Wireshark TS | AWS 服务雪崩效应

5. 网络设备 MTU MSS Jumboframe 全解



后台回复「TT」获取 Wireshark 提示和技巧系列 合集
后台回复「TS」获取 Wireshark Troubleshooting系列 合集
如需交流,可后台直接留言,我会在第一时间回复,谢谢!
Wireshark TS | 二谈 TCP 握手异常问题

原文始发于微信公众号(Echo Reply):Wireshark TS | 二谈 TCP 握手异常问题

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年6月27日00:57:00
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  Wireshark TS | 二谈 TCP 握手异常问题 https://cn-sec.com/archives/1144371.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: