我注意到一些合法的联系是这样的:
6221 29.880628 5.4.3.2 1.2.3.4 TCP 61235 > cbt [SYN] Seq=0 Win=8192 Len=0 MSS=1452 SACK_PERM=1 6222 29.880646 1.2.3.4 5.4.3.2 TCP cbt > 61235 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1 6240 29.984383 5.4.3.2 1.2.3.4 TCP 61235 > cbt [ACK] Seq=1 Ack=1 Win=65340 Len=0 6241 29.989707 5.4.3.2 1.2.3.4 TCP 61235 > cbt [PSH, ACK] Seq=1 Ack=1 Win=65340 Len=267
所以,至少就我而言,如果合法总是这样:
Client (Syn,Seq=0) Server (Syn/Ack, Seq=0, Ack1) Client (Ack, Seq=1, Ack1)
在可能的欺骗和能够将套接字提升到应用程序方面对我来说似乎很弱。 (当然欺骗IP必须down才能避免RST)
所以我测试了发送带有欺骗性 IP 的 SYN,然后发送 ACK。
SYN 到达,但 ack 有时会被忽略。
在欺骗性 SYN 之后,服务器发送 3 个 SYN/ACK(当然没有回复)。几秒钟后,如果我重新发送确认,它会收到但有一些错误。
在这种情况下是否可以与欺骗性 IP 握手?似乎是,但我做错了什么..
最佳答案
不,这是不可能的。
问题是当服务器发回 SYN-ACK
时——因为它将它发回到欺骗性 ip,这与实际发起者不匹配消息。
具体来说,您描述的(伪造 ACK)是一个 TCP sequence prediction attack这是众所周知的,现在几乎所有操作系统都反对。
关于c - 与欺骗 IP 的握手,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3737399/