Scapy 中的 3 次握手 [英] 3 way handshake in Scapy

问题描述

我正在尝试在 Scapy 中构建 3 向握手.使用以下代码，

#!/usr/local/bin/python从 scapy.all 导入 *运动 = random.randint(1024,65535)#同步ip=IP(src='172.16.120.5',dst='172.16.100.101')SYN=TCP(sport=sport,dport=443,flags='S',seq=1000)SYNACK=sr1(ip/SYN)# 确认my_ack = SYNACK.seq + 1ACK=TCP(sport=sport, dport=443, flags='A', seq=1001, ack=my_ack)发送(IP/ACK)

但是在服务器上我只看到 SYN_RECV，即使发送了返回的 SYN-ACK 并且返回了 ACK.这是来自服务器 (172.16.100.101) 的捕获，

08:10:19.455038 IP 172.16.120.5.58972 >172.16.100.101.https:S 1000:1000(0) 赢 819208:10:19.455343 IP 172.16.100.101.https >172.16.120.5.58972: S 2541678705:2541678705(0) ack 1001 win 18484 <mss 1460>08:10:19.545808 IP 172.16.120.5.58972 >172.16.100.101.https:.确认 1 赢 819208:10:24.015204 IP 172.16.100.101.https >172.16.120.5.58972: S 2541678705:2541678705(0) ack 1001 win 18484 <mss 1460>

正如你所看到的，SYN-ACK 被发送了两次，所以看起来服务器不喜欢最终的 ACK.有什么想法吗?

我还直接从 python 打印了每个数据包的输出.请注意，这是针对不同的连接.

<预><代码>>>>同步<TCP 运动=26193 dport=https seq=1000 标志=S |>>>>>>>同步<IP 版本=4L ihl=5L tos=0x0 len=44 id=0 flags=DF frag=0L ttl=63 proto=tcp chksum=0x741 src=172.16.100.101 dst=172.16.120.5 options=[] |TCP 运动=https dport=26193 seq=1023579974 ack=1001 dataofs=6L reserved=0L flags=SA window=18484 chksum=0xdb18 urgptr=0 options=[('MSS', 1460)] |<Padding load='\x00\x00' |>>>>>>>>>确认<TCP 运动=26193 dport=https seq=1001 ack=1023579975 flags=A |>

编辑 2:

下面显示了成功和不成功的连接.

SCAPY

20:58:37.357056 IP 172.16.120.5.35957 >172.16.100.101.https:S 10:10(0) 赢 819220:58:37.357369 IP 172.16.100.101.https >172.16.120.5.35957: S 900629853:900629853(0) ack 11 win 18484 <mss 1460>20:58:37.445888 IP 172.16.120.5.35957 >172.16.100.101.https:.确认 900629854 赢 8192

卷曲

20:58:46.165413 IP 172.16.120.5.33241 >172.16.100.101.https: S 2266708589:2266708589(0) win 5840 20:58:46.166296 IP 172.16.100.101.https >172.16.120.5.33241: S 2138155488:2138155488(0) ack 2266708590 win 18460 <mss 1460,sackOK,timestamp 107550664,4wscale>173p20:58:46.169026 IP 172.16.120.5.33241 >172.16.100.101.https:.ack 2138155489 win 92 <nop,nop,timestamp 17370497 107550664>

解决方案

我最终通过增加 ACK 的最终 SEQ 编号设法解决了这个问题.

from scapy.all import *运动 = random.randint(1024,65535)#同步ip=IP(src='172.16.120.5',dst='172.16.100.101')SYN=TCP(sport=sport,dport=443,flags='S',seq=1000)SYNACK=sr1(ip/SYN)# 同步确认ACK=TCP(sport=sport, dport=443, flags='A', seq=SYNACK.ack + 1, ack=SYNACK.seq + 1)发送(IP/ACK)

这是一个显示行为的 tcpdump...

20:47:54.226591 IP 172.16.120.5.55348 >172.16.100.101.443:S 1000:1000(0) 赢 819220:47:54.227220 IP 172.16.100.101.443 >172.16.120.5.55348: S 4265040634:4265040634(0) ack 1001 win 18484 <mss 1460>20:47:54.317452 IP 172.16.120.5.55348 >172.16.100.101.443:.确认 4265040635 赢 8192

Im trying to build a 3 way handshake in Scapy. Using the following code,

#!/usr/local/bin/python

from scapy.all import *

sport = random.randint(1024,65535)

# SYN     
ip=IP(src='172.16.120.5',dst='172.16.100.101')
SYN=TCP(sport=sport,dport=443,flags='S',seq=1000)
SYNACK=sr1(ip/SYN)

# ACK              
my_ack = SYNACK.seq + 1
ACK=TCP(sport=sport, dport=443, flags='A', seq=1001, ack=my_ack)
send(ip/ACK)

However on the server I see only SYN_RECV even though the return SYN-ACK is sent and the ACK is sent in return. Here is a capture from the server (172.16.100.101),

08:10:19.455038 IP 172.16.120.5.58972 > 172.16.100.101.https: S 1000:1000(0) win 8192
08:10:19.455343 IP 172.16.100.101.https > 172.16.120.5.58972: S 2541678705:2541678705(0) ack 1001 win 18484 <mss 1460>
08:10:19.545808 IP 172.16.120.5.58972 > 172.16.100.101.https: . ack 1 win 8192
08:10:24.015204 IP 172.16.100.101.https > 172.16.120.5.58972: S 2541678705:2541678705(0) ack 1001 win 18484 <mss 1460>

As you can see the SYN-ACK is being sent twice so it looks like the server doesnt like the final ACK. Any ideas ?

EDIT :

Ive also printed the output of each of the packets directly from python. Note this was for a different connection.

>>> SYN
<TCP  sport=26193 dport=https seq=1000 flags=S |>
>>> 
>>> SYNACK
<IP  version=4L ihl=5L tos=0x0 len=44 id=0 flags=DF frag=0L ttl=63 proto=tcp chksum=0x741 src=172.16.100.101 dst=172.16.120.5 options=[] |<TCP  sport=https dport=26193 seq=1023579974 ack=1001 dataofs=6L reserved=0L flags=SA window=18484 chksum=0xdb18 urgptr=0 options=[('MSS', 1460)] |<Padding  load='\x00\x00' |>>>
>>> 
>>> ACK
<TCP  sport=26193 dport=https seq=1001 ack=1023579975 flags=A |>

EDIT 2 :

Below shows a successful and unsucessful connection.

SCAPY

20:58:37.357056 IP 172.16.120.5.35957 > 172.16.100.101.https: S 10:10(0) win 8192
20:58:37.357369 IP 172.16.100.101.https > 172.16.120.5.35957: S 900629853:900629853(0) ack 11 win 18484 <mss 1460>
20:58:37.445888 IP 172.16.120.5.35957 > 172.16.100.101.https: . ack 900629854 win 8192

CURL

20:58:46.165413 IP 172.16.120.5.33241 > 172.16.100.101.https: S 2266708589:2266708589(0) win 5840 <mss 1460,sackOK,timestamp 17370497 0,nop,wscale 6>
20:58:46.166296 IP 172.16.100.101.https > 172.16.120.5.33241: S 2138155488:2138155488(0) ack 2266708590 win 18460 <mss 1460,sackOK,timestamp 107550664 17370497,nop,wscale 7>
20:58:46.169026 IP 172.16.120.5.33241 > 172.16.100.101.https: . ack 2138155489 win 92 <nop,nop,timestamp 17370497 107550664>

解决方案

I managed to fix this in the end by incrementing the final SEQ number of the ACK.

from scapy.all import *

sport = random.randint(1024,65535)

# SYN
ip=IP(src='172.16.120.5',dst='172.16.100.101')
SYN=TCP(sport=sport,dport=443,flags='S',seq=1000)
SYNACK=sr1(ip/SYN)

# SYN-ACK
ACK=TCP(sport=sport, dport=443, flags='A', seq=SYNACK.ack + 1, ack=SYNACK.seq + 1)
send(ip/ACK)

Heres a tcpdump showing the behaviour...

20:47:54.226591 IP 172.16.120.5.55348 > 172.16.100.101.443: S 1000:1000(0) win 8192
20:47:54.227220 IP 172.16.100.101.443 > 172.16.120.5.55348: S 4265040634:4265040634(0) ack 1001 win 18484 <mss 1460>
20:47:54.317452 IP 172.16.120.5.55348 > 172.16.100.101.443: . ack 4265040635 win 8192

这篇关于Scapy 中的 3 次握手的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！