Próbuję stworzyć 3-drożny uścisk dłoni w Scapy. Korzystanie poniższy kod,3-drożny uścisk dłoni w Scapy
#!/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)
Jednak na serwerze widzę tylko SYN_RECV chociaż powrót SYN-ACK jest wysyłany i ACK jest wysyłany w zamian. Oto capture z serwera (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>
Jak widać SYN-ACK jest wysyłany dwa razy więc wygląda na to doesnt serwerze jak ostatnim ACK. Jakieś pomysły ?
Edycja:
Ive także nadrukowane wyjście każdego z pakietów bezpośrednio pytona. Zauważ, że było to dla innego połączenia.
>>> 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:
Poniżej przedstawiono udane i unsucessful połączenia.
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>
'pakiet SYN-ACK' jest rejestrowane jako 'ACK 1 wygranej 8192', co wydaje się wskazywać na' ack' z oczekiwanej liczby sekwencji 1 zamiast 2541678706. Czy możesz wydrukować 'SYNACK' i' my_ack' (choć wydają się być ustawione poprawnie)? – Yoel
Ive zaktualizowałem pytanie. Myślisz, że masz rację, że ACK ma nieprawidłowy numer potwierdzenia. Jednak jeśli wezmę działające połączenie, tj. Wykonam zawinięcie do portu 443, który został pomyślnie ustanowiony, to pokazuje również ostateczną wersję ACK z 1 – felix001
. Czy możesz również opublikować równoważny log udanego połączenia 'curl'? W jaki sposób jest wdrażany serwer? Czy można go zastąpić skryptem 'scapy', który drukuje odebrane pakiety? – Yoel