TCP SYN scan (-sS)
SYN scanning is by default used and the most popular scanning method for good reason. It can be performed quickly and SYN scanning is both relatively discreet and cautious, as it never completes TCP connections. It also works with any compatible TCP stack regardless of platforms. However, SYN scanning requires root privileges for nmap to be able to send raw TCP packets.
Example of SYN scanning
nmap -sS -p22.80 127.0.0.1
Starting Nmap ( https://nmap.org )
Nmap scan report for 127.0.0.1
PORT STATE SERVICE
22/tcp open ssh
80/tcp closed http
Nmap done: 1 IP address (1 host up) scanned in 1.35 seconds
SYN -scan operational logic when the port is open
The example shows that Nmap starts by sending a TCP packet with the SYN flag set to port 22. This is the first step in the three-way handshake of TCP that all legitimate connection attempts make. Since the destination port is open, the system takes the second step by sending a response with the SYN and ACK flags. In a normal connection, the machine would send an ACK packet acknowledging the SYN/ACK. However, Nmap doesn't need to do this because the SYN/ACK response already indicated that the port is open. If Nmap were to complete the connection, it would then have to ensure that it is closed. This usually requires another handshake using FIN packets instead of SYN. So ACK is a bad idea, but something still needs to be done. If the SYN/ACK is completely ignored, the server assumes it has dropped and continues sending it again. Since we don't want to establish a full connection, we use an RST packet as shown in the diagram. This instructs to forget (reset) that connection attempt.
SYN -scan operation logic when the port is closed
The following example shows how Nmap determines that port 80 is closed. This is even simpler than the open situation. The first step is always the same - Nmap sends a SYN packet. But instead of receiving a SYN/ACK packet, an RST is returned. This resolves the issue - the port is closed. There is no need for further communication on this port.
SYN scanning operation logic when port is "filtered"
In the last example, a SYN request is sent as usual, but Nmap doesn't receive a response. The response could simply be slow. Based on previous responses (or timing assumptions), Nmap knows how long to wait for a response, and eventually it gives up if no response is received. The unresponsive port is usually filtered (blocked by a firewall device or perhaps the host is turned off), but this one test is not absolute. Perhaps the port is open, but the probe request or response has simply been ignored. So Nmap retries by sending a SYN packet. After a second timeout, Nmap gives up and marks the port as filtered.
Ready to become an ethical hacker?
Start today.
As a member of Hakatemia you get unlimited access to Hakatemia modules, exercises and tools, and you get access to the Hakatemia Discord channel where you can ask for help from both instructors and other Hakatemia members.