Question

我正在分析各种TCP会话的结束，在RST的情况下，我经常观察到相同的模式，以下是示例性的会话结束（它是第一个序列号，然后是确认号）：

0890: 14:56:54.507349: <= 1997168101 1198807587  ACK,PSH - length: 00017
0891: 14:56:55.565251: <= 1997168101 1198807587  ACK,PSH - length: 00017
0892: 14:56:57.409887: => 1198807587 1997168118  ACK     - length: 00000
0893: 14:57:01.096632: => 1198807587 1997168118  ACK     - length: 01188
0894: 14:57:01.096645: <= 1997168118 1198808775  ACK     - length: 00000
0895: 15:00:32.390242: => 1198813327 1997168118  ACK,RST - length: 00000
0896: 15:00:32.390253: <= 1997168118 1198808775  ACK     - length: 00000
0897: 15:06:55.502604: <= 1997168118 1198808775  ACK,FIN - length: 00000
0898: 15:07:01.105218: <= 1997168118 1198808775  ACK,FIN - length: 00000
0899: 15:07:12.337226: <= 1997168118 1198808775  ACK,FIN - length: 00000
0900: 15:07:34.737225: <= 1997168118 1198808775  ACK,FIN - length: 00000
0901: 15:08:19.665225: <= 1997168118 1198808775  ACK,FIN - length: 00000

我对RST数据包的序列号感兴趣。我希望将1198807587 + 1188 = 1198808775作为序列号而不是1198813327，即有4552字节的间隔。我检查了完整的会话（数据包1-889），并确保此差距是真实的。

我现在想知道，对此最可能的解释是什么？

RST注入（具有更高的窗口内序列号）？我不这么认为，因为RST发送器在发送RST之后立即完全消失了，所以我认为它实际上是在发送RST。
丢包？对我来说似乎有效。但是我会假设故意设计的RST不会导致任何数据包丢失。错误的假设？在丢包的情况下，什么可能导致RST？
是否还有其他解释？

Answer 1

它看起来像RFC-5961中描述的“使用RST位进行盲重置攻击”。但是由于那之后的“左侧”完全是死亡（这些FIN-ACK不能回答），因此问题可能出在其他方面。

例如：

漏洞扫描程序，检查目标是否遵循RFC-5961的建议（在此类RST之后发送Challenge-ACK）。

RST序号缺口

1 个答案: