☰

如何解释 FIN、ACK 而不是 FIN - FIN、ACK 的序列？

tag-icon • tag-icon linux networking ssh tcp wireshark
如何解释 FIN、ACK 而不是 FIN - FIN、ACK 的序列？

语境：新安装的 Debian 12，我收到一堆与 ssh 相关的奇怪日志：

root@square:~# journalctl -u ssh -f
May 07 11:13:00 yop-square sshd[766]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:00 yop-square sshd[766]: Connection closed by 10.91.66.91 port 53714
May 07 11:13:00 yop-square sshd[767]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:00 yop-square sshd[767]: Connection closed by 10.106.14.62 port 54236
May 07 11:13:00 yop-square sshd[768]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:00 yop-square sshd[768]: Connection closed by 10.35.165.19 port 60748
May 07 11:13:06 yop-square sshd[771]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:06 yop-square sshd[771]: Connection closed by 10.35.165.49 port 42286
May 07 11:13:06 yop-square sshd[772]: error: kex_exchange_identification: Connection closed by remote host
May 07 11:13:06 yop-square sshd[772]: Connection closed by 10.80.98.247 port 47780

这可能是设备正在扫描（企业网络的一部分），但行为/日志很奇怪。我拍了一张，tcpdump下面是导致上述日志的一次交流

No.     Time        Source          Destination     Protocol Length    Info
1380    122.725892  10.81.98.206    10.237.76.90    TCP 74  60422 → 22 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM TSval=4018386585 TSecr=0 WS=128
1381    122.725908  10.237.76.90    10.81.98.206    TCP 74  22 → 60422 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=660439285 TSecr=4018386585 WS=128
1382    122.726397  10.81.98.206    10.237.76.90    TCP 66  60422 → 22 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=4018386586 TSecr=660439285
1383    122.726505  10.81.98.206    10.237.76.90    TCP 66  60422 → 22 [FIN, ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=4018386586 TSecr=660439285
1384    122.730066  10.237.76.90    10.81.98.206    TCP 66  22 → 60422 [ACK] Seq=1 Ack=2 Win=65280 Len=0 TSval=660439290 TSecr=4018386586
1385    122.738228  10.237.76.90    10.81.98.206    SSH 106 Server: Protocol (SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2)
1386    122.738603  10.237.76.90    10.81.98.206    TCP 66  22 → 60422 [FIN, ACK] Seq=41 Ack=2 Win=65280 Len=0 TSval=660439298 TSecr=4018386586
1387    122.738792  10.81.98.206    10.237.76.90    TCP 60  60422 → 22 [RST] Seq=2 Win=0 Len=0
1388    122.739140  10.81.98.206    10.237.76.90    TCP 60  60422 → 22 [RST] Seq=2 Win=0 Len=0

在这种情况下10.237.76.90是me（我的 Debian 盒子）并且10.81.98.206是them。请注意，所有活动都是经过授权的，诸如此类 - 我的问题的目的是了解交换并找出谁在行为不当（或者，一切都很好，并且交换/日志是它们应该有的样子）

  • 13801382→发起theySSH 调用并进行握手
  • 1383→they发送FIN,ACK,为什么？。如果他们想结束对话，他们应该发送FIN并等待FIN,ACK，对吗？
  • 1384→ 我发送了一个ACK，但不知道为什么。

无论如何，事情似乎从那以后就变糟了

  • 1385→ 我的 ssh 显示了它的协议，但不知道为什么，因为连接被终止了
  • 1386→突然me发送FIN,ACK
  • 1387并1388→they发送两个RST，可能是叫我滚开

我仍然不确定是谁在搞乱连接，但我确实想知道，因为这要么是我的问题sshd（我非常怀疑），要么是公司扫描的问题，所以我会发送一个吼叫者。

答案1

我对此不是 100% 确定（事实上我只有 65% 确定），但是：

1383 → 他们发送了 FIN、ACK，为什么？如果他们想结束对话，他们应该发送 FIN 并等待 FIN、ACK，对吗？

不一定。TCP 对话在每个方向上都是独立关闭的，因此这两者实际上是两个独立的事情：你发送 FIN 来结束你这边的对话和您发送 ACK 来确认尚未确认的任何段。这些可以是两个单独的数据包，也可以合并为一个。

同样，尽管服务器通常会在一个数据包中响应“FIN，ACK”，但它们本质上并不是一个单元；服务器可能如果需要，可以单独发送自己的 FIN，而不确认收到的 FIN。在这种情况下，在发送 FIN 之前，它仍然有一些数据已经排队等待发送。

1384 → 我发送了 ACK，但不确定为什么。

您已收到 FIN，它有自己的序列号并保证 ACK。

1385 → 我的 ssh 显示了它的协议，不知道为什么，因为连接已终止

FIN 仅表示“这是来自我的FIN 的到达和处理可能需要一些时间，在此期间软件可能已经将数据提交给 TCP，而这些数据应该在完全关闭之前得到正确传送。

1387 和 1388 → 他们发送两个 RST，可能是为了告诉我滚开

不太清楚为什么；也许客户端已经过早地失去了对连接的跟踪（ nmap 等扫描工具可能会这样做），在这种情况下 RST 会很合适。

相关内容