This will make it easier to see scapy's output.
nc -l -p 5555
Note: on some Linux versions you need to use
this command instead: nc -l 5555
Open another Terminal window and execute this command:
watch "netstat -an | grep 5555"
This gives a realtime, constantly updated,
report of connections to port 5555.
You should have two windows open now, one with netcat listening, and the other running netstat. The netstat window shows a process in the LISTEN state on port 5555, as shown below.
Then, like the Great Firewall of China, it will send a RST packet to cancel the improper connection.
To prevent that, we need to add an iptables firewall rule.
Open a new Terminal window and execute these commands. The first command flushes out the old rules, the second command addrs a rule to drop all RST packets sent out, and the third command lists the firewall rules.
iptables -F
iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
iptables -L
You should see one rule in the OUTPUT section dropping RST packets,
as shown below on this page.
scapy
conf.L3socket
conf.L3socket=L3RawSocket
i = IP()
i.display()
Scapy fills in both the source
and destination addresses with
the loopback address 127.0.0.1,
as shown below.
t = TCP()
t.dport = 5555
t.display()
The properties of your TCP object should look like the example
shown below on this page. Notice that the
seq and ack numbers
are both 0.
Note that the third character is the numeral 1, not a lowercase L:
sr1(i/t)
This command sends and receives one packet,
of type IP at layer 3 and TCP at layer 4.
As you can see in the image below, the response is shown,
with flags=SA (a SYN/ACK reply).
The ack number is 1, indicating that this is a reply to your SYN
packet with seq = 0.
Find the seq number in the SYN/ACK reply. It's highlighted in the figure below. Later, you will add one to this number to find the ack value you must use in the ACK packet that completes the handshake.
You should see a connection in the state SYN_RECV, as highlighted in the image below.
This means the Target has received a SYN, amd sent a SYN/ACK, and it is now waiting for the ACK to complete the handshake.
Wait for 60 seconds. You should see the connection time out--it will vanish from the netstat list.
This is the default setting in Kali Linux, to wait 60 seconds before giving up on the connection. You can complete the project this way if you work fast, but for most students 60 seconds isn't long enough to complete the handshake.
This setting defaults to 5, which means sessions time out after 60 seconds.
On the Linux target machine, open a new Terminal window and excute this command to lengthen the timeout to 10 minutes:
echo 10 > /proc/sys/net/ipv4/tcp_synack_retries
Note: this setting is not wise for use on a server, because it to makes your machine far more vulnerable to SYN floods. But it's not permanent--when the machine restarts it will reset to the default value of 5 (one minute).
Note that the third character is the numeral 1, not a lowercase L:
sr1(i/t)
On the Sender Linux machine,
you should see a SYN/ACK reply
as shown below.
The window watching netstat now shows a connection in the SYN-RECV state, as shown below.
Find your seq number and add one to it. Ignore the "L" at the end.
Replace "1" with your ack number.
Replace "2510685632" with the value you calculated above; your seq value plus 1.
t.flags = "A"
t.seq = 1
t.ack = 2379023435
send(i/t)
Make sure you can see the ESTABLISHED connection.
Save a screen image with the filename Proj 10 from Your Name.
Email the image to cnit.123@gmail.com with a Subject line of Proj 10 from Your Name.
http://blog.facilelogin.com/2010/12/hand-crafting-tcp-handshake-with-scapy.html
http://linux.die.net/man/7/tcp
http://www.cyberciti.biz/tips/linux-increasing-or-decreasing-tcp-sockets-timeouts.html
Scapy fails when sending HTTP GET request to localhost