Project 10: TCP Handshake with scapy (NETLAB)

Finding the Target IP Address

Open the client1 (Kali32) virtual machine. Log in as root with the password toor

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.

Starting a netcat Listener on the Target Machine

On the Kali32 target machine, in a Terminal window, execute this command (notice that the switch is a lowercase L):
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.

Blocking RST Packets on the Sender Machine

Open the client2 (Kali64) virtual machine. Log in as root with the password toor

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.

Starting scapy on the Sender Machine

On the Kali64 machine, use this command to start scapy:
scapy

Creating an IP Object on the Sender Machine

In the Sender machine, in the Terminal window, at the >>> prompt, execute these commands, replacing the IP address in the second command with the IP address of your Target machine:
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.

Creating a TCP Object on the Sender Machine

Use these commands to create an object named t of type TCP with a destination port of 5555 and the flags set to S (for SYN):
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.

Sending a SYN Packet from the Sender Machine

Use this command to send the packet onto the network and listen to a single packet in response.

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.

Observing TCP Timeout

On the Target machine, bring the window showing netstat to the front.

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.

Lengthening the TCP Timeout on the Target Machine

This is why hackers love Linux--you can adjust anything about it. There are several TCP timing settings, but the one important for this project is tcp_synack_retries --"The maximum number of times a SYN/ACK segment for a passive TCP connection will be retransmitted."

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).

Re-sending a SYN from the Sender Machine

In scapy, execute this command again:

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.

Sending an ACK Packet from the Sender Machine

On the Sender machine, at the >>> prompt, execute these commands.

Replace "1491428787" with the seq number you noted above plus 1.

t.flags = "A"

t.seq = 1

t.ack = 1491428787

send(i/t)

Observing the Session on the Target Machine

On the Target machine, netstat should now show an ESTABLISHED connection, as shown below:

Sources

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


Last modified 3-10-16
Modified for NETLAB 6-8-16