Início / computer / Perguntas / 1841598
Accepted
WoJ
Asked: 2024-05-07 18:52:40 +0800 CST

Como explicar sequências de FIN,ACK em vez de FIN - FIN,ACK?

  • 772

Contexto: Debian 12 recém-instalado, recebo vários logs estranhos relacionados ao 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

Podem ser dispositivos fazendo varreduras (parte de uma rede corporativa), mas o comportamento/registro é estranho. Peguei um tcpdumpe abaixo está uma das trocas que leva aos logs acima

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

Neste cenário 10.237.76.90é me(minha caixa Debian) e 10.81.98.206é them. Observe que toda a atividade é autorizada e outros enfeites - o objetivo da minha pergunta é entender a troca e descobrir quem está se comportando mal (ou, alternativamente, se está tudo bem e a troca/logs são o que deveriam ser)

  • 1380para 1382→ theyiniciar uma chamada SSH e passar pelo handshake
  • 1383→ theyenviar um FIN,ACK, por quê? . Se quisessem encerrar a conversa, deveriam ter enviado um FINe aguardado um FIN,ACK, certo?
  • 1384→ Envio um ACK, não sei por quê.

De qualquer forma, as coisas parecem ir para o sul a partir daí

  • 1385→ meu ssh apresenta seu protocolo, não faço ideia do porquê já que a conexão foi encerrada
  • 1386→ meenvia um FIN,ACK, do nada
  • 1387e 1388→ theyenviar dois RST, provavelmente para me dizer para me perder

Ainda não tenho certeza de quem está bagunçando a conexão, mas com certeza gostaria de saber porque é um problema meu sshd(o que duvido seriamente) ou da digitalização corporativa e por isso enviarei um bugio .

linux

1 respostas

  1. Best Answer

    Não tenho 100% de certeza sobre isso (na verdade, tenho apenas 65% de certeza), mas:

    1383 → enviam um FIN,ACK, por quê?. Se quisessem encerrar a conversa deveriam ter enviado um FIN e aguardar um FIN,ACK, certo?

    Não necessariamente. As conversas TCP são encerradas independentemente em cada direção, então essas duas são, na verdade, duas coisas independentes: você envia FIN para encerrar a conversa do seu lado e envia ACK para reconhecer quaisquer segmentos que você ainda não tenha confirmado. Esses podem ser dois pacotes separados ou combinados em um.

    Da mesma forma, embora o servidor normalmente responda com um “FIN,ACK” em um pacote, eles não são inerentemente uma única unidade; o servidor pode enviar seu próprio FIN separadamente do ACK do FIN recebido, se desejar. Neste caso, ainda possui alguns dados que já estavam na fila para envio antes de poder enviar o FIN.

    1384 → Envio um ACK, não sei porquê.

    Você recebeu um FIN, que possui seu próprio número de sequência e garante um ACK.

    1385 → meu ssh apresenta seu protocolo, não faço ideia do porquê já que a conexão foi encerrada

    Um FIN significa apenas "este foi o último pacote do meu lado", mas ainda permite que os dados sejam enviados na direção oposta. Pode levar algum tempo para o FIN chegar e ser processado, durante o qual o software já pode ter enviado dados ao TCP, e esses dados devem ser entregues corretamente antes do desligamento completo.

    1387 e 1388 → eles mandam dois RST, provavelmente para me mandar sumir

    Não tenho certeza do porquê; talvez o cliente já tenha perdido o controle da conexão prematuramente (ferramentas de varredura como o nmap podem estar fazendo isso); nesse caso, um RST seria apropriado.

    • 4

relate perguntas