This is your Target.
Use this command to find your Target IP address:
ifconfig
Your Target IP address should be 172.16.1.203,
as shown below.
nc -l -p 5555
In the Terminal window, at the top,
click File,
"Open Terminal" to open
a second Terminal window. In the second window,
execute this command:
watch "netstat -an | grep 5555"
This gives a realtime, constantly updated,
report of connections to port 5555.
You should see a process listening on port 5555, as shown below on this page.
This is your Sender Machine.
Scapy will be sending a "Raw" TCP SYN packet, but the Linux kernel will be offended by that, feeling like only kernel routines should be opening connections.
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.
On the Sender machine, execute these commands.
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
i = IP()
i.dst="172.16.1.203"
i.display()
Scapy fills in both the source and destination addresses,
as shown below on this page.
t = TCP()
t.dport = 5555
t.flags = "S"
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--in the figure below, it is 1491428786. 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 shown 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 Target machine, open a third Terminal window and execute 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 normal use,
because I expect it to make 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)
This command sends a SYN.
Look at your Target machine. It should now show a connection in the SYN-RECV state again:
On the Sender machine, you should see a SYN/ACK reply as shown below. Note the seq value, as outlined in green below.
Replace "1491428787" with the seq number you noted above plus 1.
t.flags = "A"
t.seq = 1
t.ack = 1491428787
send(i/t)
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