TCP scan, also known as TCP connect scan, is the default TCP scan type when SYN scan is not an option.
Well, when is the SYN scan not an option?
Do you remember the trip of a data packet on a DNS query. In that lecture, I said that Layer 3 and Layer 4
packets are managed by the operating system of your device.
That means, user does not interfere with the TCP 3-­way handshake, the whole process is managed by the
the operating system itself.
In SYN scan, we interrupt the 3-­way handshake and don’t send the last ACK packet to complete the handshake.
You have to be a privileged used to be able to interrupt the handshake. If you are not a privileged user,
you cannot interrupt 3-­way handshake and can not perform SYN scan as well.
So instead of writing raw packets as most other scan types do, which needs admin privilege, Nmap asks
the underlying operating system to establish a connection with a target machine and port by issuing
the native connect system call.
So you don’t need to be a privilege user to perform TCP connect scans. When SYN scan is available,
it is usually a better choice. Nmap has less control over the high level connect call than with raw
packets making it less efficient.
The system call completes connections to open target ports rather than performing the half-­open reset
SYN scan does. Not only does this take longer and require more packets to obtain the same information,
but target machines are more likely to log the connection. The steps of TCP connect
scan is exactly the same as TCP 3-­way handshake: You send a SYN packet, to open a real connection a
and then wait for a response. A SYN/ACK response indicates the port is listening (open), while a RST (reset) is
RST (reset) is indicative of a non-­listener. If no response is received
after several retransmissions, or an ICMP unreachable error is received,
the port is marked as filtered.
If you receive a SYN/ACK from the target system, you send ACK packet to complete the three-­way handshake.
Since we have nothing to say at the moment, we send RST to end the conversation.
Let’s see what happens under the hood when we perform a TCP scan, and then compare the SYN scan with the TCP
scan:
Let’s perform an Nmap TCP scan in our virtual network first.
Go to Kali and open a terminal screen.
I want to scan my Metasploitable system. Let’s check if the host is up first.
I know the IP address of my Metasploitable VM, so type “ping 172.16.99.206” and hit enter. OK. We received
a response packs.
The system is up. Let’s create the TCP scan command: nmap is the command itself,
sT is to TCP scan. n is to avoid the DNS resolution.
I’d like to see the IP addresses. Pn is to avoid the host discovery.
I already know that the host is up. You should make it a habit to use -­Pn while you’re scanning a single system.
a single system.
Now we have the target IP address 172.16.99.206.
Let’s keep it fast, scan for the top 10 ports only.
I use top-­ports parameter for this purpose and hit enter.
Here are the states of top 10 ports of Metasploitable. 7 ports are open and 3 ports are closed.
OK let's open Wireshark and see what's happening when a TCP scan is performed.
So you get to run wireshark first. Double click eth0 to start to
listen to that interface.
Skip the packets which we are not interested in.
I add a filter.
I only want to see the traffic for my destination computer, 172.16.99.206, and I want to see the
TCP traffic only. Click to the blue arrow next to filter bar to activate the filter. To clear the packets
we've already caught.
I restart the Wireshark packet capturing. OK now go to the terminal screen.
I’d like to analyse the TCP scan packets for an open port first. I’m going to run the latest Nmap query
again, but in this time, I run the query for port 80 only. Hit enter and run the nmap query.
Yes the port is open as I remember.
It's good to know I'm not losing my memory.
Go back to Wireshark.
I want to stop Wireshark by clicking the red square at the upper left corner to avoid unwanted packets.
Now here we have three packets.
The first packet is a SYN packet to start the 3-­way handshake. It’s from an arbitrary port of Kali to
the 80th port of Metasploitable -­the destination system.
Second packet is a SYN/ACK sent by the destination system.
The third packet is an ACK sent by Kali to complete the TCP 3-way handshake. And the fourth packet is a
RST sent by Kali again, to end the conversation.
This time I want to scan a closed port for example port 81 before running the query
I restart the Wireshark packet capturing to clean it screen by clicking the blue button in the upper
left corner. In the terminal screen
I hit enter to run the query. As you see Port 81 is closed.
Now let's look at the Wireshark interface to see what happens when we scan a closed port.
The first packet is again a SYN packet to start the 3-­way handshake.
The source system is Kali and the destination system is Metasploitable.
he second packet is, for this scan, a RST packet. Because the port 81 is closed,
the destination system sent us a RST packet.
Here we have a comparison between SYN scan packets and TCP scan packets for an open port.
In SYN scan, Nmap has corrupted the 3-­way handshake by a RST packet. •In TCP scan, on the other hand,
the 3-­way handshake is completed and the communication is established.
So let’s see the differences between the SYN scan and the TCP scan in a table that
we've only really talked about up to now.
3-way handshake is not completed in SYN scan while it’s completed in TCP scan. A RST packet is sent
when a SYN/ACK received in SYN scan while an ACK packet is sent in TCP scan. Target machines
are more likely to log the connection when the connection is established in TCP scan. No log for SYN scans, because
3-­way handshake is not established. Because the native operating system call is interrupted,
SYN scan has to be run by a privilege user.
TCP scan uses the system call, so it does not need extra privileges.