RST 序列号间隙

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(，并确保此差距是真实的。

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

1. RST 注入(具有更高的窗口内序列号(？我不这么认为，因为 RST 发送者在发送 RST 后立即完全消失，所以我认为实际上是他自己发送 RST。

2. 丢包？对我来说似乎有效。但我认为故意的 RST 设计不会导致任何数据包丢失。错误的假设？如果 RST 丢失数据包，什么可能导致

   ？

3. 对这种差距还有其他解释吗？

Answer 1

它看起来像RFC-5961中描述的"使用RST位的盲重置攻击"。 但是因为"左侧"在那之后完全死亡(不能回答那些 FIN-ACK(，问题可能是别的。

例如：

• 漏洞扫描程序，用于检查目标是否遵循 RFC-5961 的建议(在此类 RST 之后发送质询 ACK(。