主页 / computer / 问题 / 1841598
Accepted
WoJ
Asked: 2024-05-07 18:52:40 +0800 CST

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

  • 772

上下文：新安装的 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，为什么？。如果他们想结束对话，他们应该发送 aFIN并等待 a FIN,ACK，对吧？
  • 1384→ 我发送了一封ACK，不知道为什么。

无论如何，事情似乎从那里开始向南发展

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

我仍然不确定是谁在连接中造成了混乱，但我确实想知道，因为这要么是我的问题sshd（我严重怀疑），要么是公司扫描的问题，所以我会发送一个咆哮。

linux

1 个回答

  1. Best Answer

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

    第1383章 如果他们想结束对话，他们应该发送 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 是合适的。

    • 4

相关问题