Introduction to TCP and SYN connections
While reading this article remember the following definitions:
SYN packet: is a packet requesting or confirming the synchronization of a connection.
ACK packet: is a packet confirming the receipt of a SYN packet.
RST packet: is a packet informing the connection attempt should be discarded.
Usually when two devices connect, connections are established through a process called three way handshake which consists of 3 initial interactions: first of a connection request by the client or device requesting the connection, second by a confirmation by the device to which the connection is requested and in third place a final confirmation from the device which requested the connection, something like:
-“hey, can you hear me?, can we meet?” (SYN packet requesting synchronization)
-”Hi!, I see you!, we can meet” (Where “I see you” is an ACK packet, “we can meet” a SYN packet)
-”Great!” (ACK packet)
In the comparison above shows how a TCP connection is established, the first device asks the second device if it detects the request and if can they establish a connection, the second device confirms it can detect it and that is available for a connection, then the first device confirms acknowledge of the acceptance.
Then the connection is established, as explained with graphics in Nmap basic scan types, this process has the problem the third handshake, the final confirmation, usually leaves a connection log on the device to which you requested the connection, if you are scanning a target without permission or want to test a firewall or Intrusion Detection System (IDS) you may want to avoid the confirmation to prevent a log including your IP address or to test the capability of your system to detect the interaction between systems despite the lack of an established connection, called TCP connection or Connect Scan. This is a stealth scan.
This can be achieved by replacing the TCP connection/Connect Scan for a SYN connection. A SYN connection omits the final confirmation replacing it for an RST packet. If we replace the TCP connection, the three handshake connection, for a SYN connection the example would be:
-“hey, can you hear me?, can we meet?” (SYN packet requesting synchronization)
-”Hi!, I see you!, we can meet” (Where “I see you” is an ACK packet, “we can meet” a SYN packet)
-”Sorry, I sent a request to you by mistake, forget about it” (RST packet)
The example above shows a SYN connection, which does not establish a connection in contrast to a TCP connection or Connect Scan, therefore there is not log on the second device about a connection, nor your IP address logged.
Practical examples of TCP and SYN connection
Nmap doesn’t support SYN (-sS) connections without privileges, to send SYN requests you must be root, and if you are root requests are SYN by default. In the following example you can see a regular verbose scan against linux.lat as regular user:
As you can see it says “Initiating a Connect Scan“.
In the next example the scan is carried out as root, therefore it is a SYN scan by default:
And as you can see, this time it says “Initiating SYN Stealth Scan“, connections are dropped after linux.lat sent its ACK+SYN response to Nmap’s initial SYN request.
Nmap NULL Scan (-sN)
Despite sending a RST packet preventing the connection, grom being logged a SYN scan can be detected by firewalls and Intrusion Detection Systems (IDS). There are additional techniques to carry out more stealthy scans with Nmap.
Nmap works by analyzing the packets responses from the target contrasting them with protocols rules and interpreting them. Nmap allows to forge packets to generate the proper responses revealing their nature, for example to know if a port is really closed or filtered by a firewall.
The following example shows a NULL scan which does not include SYN, ACK or RST packets.
When doing a NULL scan Nmap can interpret 3 results: Open|Filtered, Closed or Filtered.
Open|Filtered: Nmap can’t determine if the port is open or filtered by a firewall.
Closed: The port is closed.
Filtered: The port is filtered.
This means when carrying out a NULL scan Nmap doesn’t know how to distinguish from open and filtered ports depending on the firewall response or lack of response, therefore if the port is open you’ll get it as Open|Filtered.
In the following example the port 80 of linux.lat is scanned with a NULL Scan, with verbosity.
Where:
nmap = calls the program
-v = instructs nmap to scan with verbosity
-sN = instructs nmap to run a NULL scan.
-p = prefix to determine the port to scan.
linux.lat = is the target.
As shown in the following example you can add the options -sV to discover if the port portrayed as Open|Filtered is actually open, but adding this flag may result in an easier scan detection by the target as explained in Nmap’s book.
Where:
nmap = calls the program
-v = instructs nmap to scan with verbosity
-sN = instructs nmap to run a NULL scan.
-sV =
-p = prefix to determine the port to scan.
linux.lat = is the target.
As you can see, in the last screenshot Nmap reveals the real state of the port, but by sacrificing the undetection of the scan.
I hope you found this article useful to get introduced to Nmap Stealth Scan, keep following LinuxHint.com for more tips and updates on Linux and networking.
Related articles:
