Tools · Nmap and network discovery · 05 / 25
Nmap SYN scan vs TCP connect scan (-sS vs -sT) explained
The packet-level difference between a half-open SYN scan and a full TCP connect scan, what each leaves in logs, and which one to use in your lab.
The SYN scan stops after two packets
A SYN scan sends the first packet of the TCP handshake. If the port is open, the target replies SYN-ACK, and Nmap’s operating system, which never asked for that connection, answers with a RST. The connection never completes, which is why the technique is called half-open. If the port is closed, the target sends RST immediately.
Because Nmap crafts the packets itself, a SYN scan needs raw socket privileges: root on Linux and macOS, or administrator with Npcap on Windows. It is the default for privileged users because it is fast and does not depend on the OS connection table.
The connect scan completes the handshake
A connect scan calls the operating system’s connect() function, exactly as a web browser would. An open port completes the three-way handshake, and Nmap then closes it. No special privileges are required, so this is the default when you run Nmap as a normal user, and the only option for scanning through some proxies.
A completed connection reaches the application. A web server may log a request with no data, an SSH daemon may log “Connection closed by remote host”, and some fragile embedded services may even crash on a connection that closes immediately. That is the main practical reason to prefer -sS when you have the privilege.
Lab: watch both scans with tcpdump
On the target VM, start tcpdump filtered to the scanner’s address. From the scanner, run a SYN scan of port 22, then a connect scan of the same port. Compare the two packet sequences. The SYN scan should show SYN, SYN-ACK, RST. The connect scan shows SYN, SYN-ACK, ACK, then a RST or FIN from the scanner.
Then check the SSH log on the target with journalctl -u ssh --since "5 min ago". The connect scan typically leaves a line about a connection that closed before authentication. The SYN scan usually leaves nothing in the application log, though a firewall or IDS on the host can still see it.
# target sudo tcpdump -ni any host 192.168.56.20 and port 22 # scanner sudo nmap -sS -p22 192.168.56.101 nmap -sT -p22 192.168.56.101 # target, afterwards journalctl -u ssh --since "5 min ago"
Half-open is not invisible
Older guides call the SYN scan “stealth”. It was quieter when applications were the only thing logging. Today host firewalls, network IDS, and endpoint agents see SYN packets directly, and a burst of SYNs to many ports from one source is one of the easiest patterns to detect.
Choose between the two on practical grounds: privileges, speed, and whether you want to avoid touching fragile applications. Do not choose on the hope of not being noticed. On an authorized scan, being noticed by the defenders is part of the test.
Diagram
Packets on the wire for an open port
Same target, same port, different endings.
Packets. SYN, SYN-ACK, ACK, then close.
Privileges. None needed.
Logs. The application sees a real connection.
Packets. SYN, SYN-ACK, RST from the scanner.
Privileges. Raw sockets: root or admin with Npcap.
Logs. Usually invisible to the app, visible to firewalls and IDS.
Check yourself
1. During a SYN scan of an open port, what does the scanner send after the SYN-ACK?
2. Which scan is more likely to leave a line in an SSH server’s log?
3. Why is “stealth scan” a misleading name today?