- Nmap Network Scanning
- Chapter5.Port Scanning Techniques and Algorithms
- TCP SYN (Stealth) Scan (-sS)
SYN scan is the default and most popular scan option for goodreason. It can be performed quickly, scanning thousands of ports persecond on a fast network not hampered by intrusive firewalls. SYN scanis relatively unobtrusive and stealthy, since it never completes TCPconnections. It also works against any compliant TCP stack ratherthan depending on idiosyncrasies of specific platforms as Nmap'sFIN/NULL/Xmas, Maimon and idle scans do. It also allows clear,reliable differentiation between open
,closed
, and filtered
states.
SYN scan may be requested by passing the -sS
option to Nmap. It requiresraw-packet privileges,and is the defaultTCP scan when they are available. So when running Nmap as root orAdministrator, -sS
is usually omitted. This defaultSYN scan behavior is shown in Example5.1, which finds a port in each of the three major states.
Example5.1.A SYN scan showing three port states
krad# nmap -p22,113,139 scanme.nmap.org
Starting Nmap ( https://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)PORT STATE SERVICE22/tcp open ssh113/tcp closed auth139/tcp filtered netbios-ssnNmap done: 1 IP address (1 host up) scanned in 1.35 seconds
While SYN scan is pretty easy to use without any low-levelTCP knowledge,understanding the technique helps when interpreting unusual results.Fortunately for us, the fearsomeblack-hatcrackerEreet Hagiwarahas taken a break from terrorizingJapanese Windows users to illustrate the Example5.1SYN scan for us at the packet level. First, the behavior against openport 22 is shown in Figure5.2.
Figure5.2.SYN scan of open port 22
As this example shows, Nmap starts by sending a TCP packet withthe SYN flag set (see Figure2, “TCP header” if you haveforgotten what packet headers look like) to port 22. This is thefirst step in the TCPthree-way handshakethat any legitimateconnection attempt takes. Since the target port is open, Scanme takesthe second step by sending a response with the SYN and ACK flags back.In a normal connection, Ereet's machine (named krad) would completethe three-way handshake by sending an ACK packet acknowledging theSYN/ACK. Nmap does not need to do this, since the SYN/ACK responsealready told it that the port is open. If Nmap completed theconnection, it would then have to worry about closing it. Thisusually involves another handshake, using FIN packets ratherthan SYN. So an ACK is a bad idea, yet something still has to bedone. If the SYN/ACK is ignored completely, Scanme will assume it wasdropped and keep re-sending it. The proper response, since we don'twant to make a full connection, is a RST packet as shown in thediagram. This tells Scanme to forget about (reset) the attemptedconnection. Nmap could send this RST packet easily enough, but itactually doesn't need to. The OS running on krad also receivesthe SYN/ACK, which it doesn't expect because Nmap crafted the SYNprobe itself. So the OS responds to the unexpected SYN/ACK with aRST packet. All RST packets described in this chapter also have the ACK bitset because they are always sent in response to (and acknowledge) areceived packet. So that bit is not shown explicitly for RST packets.Because the three-way handshake is never completed, SYN scan issometimes calledhalf-open scanning.
Figure5.3 shows how Nmapdetermines that port 113 is closed. This is even simpler than theopen case. The first step is always the same—Nmap sends the SYNprobe to Scanme. But instead of receiving a SYN/ACK back, a RST isreturned. That settles it—the port is closed. No morecommunication regarding this port is necessary.
Finally, Ereet shows us how a filtered port appears to Nmap inFigure5.4. The initialSYN is sent first, as usual, but Nmap sees no reply. The responsecould simply be slow. From previous responses (or timing defaults),Nmap knows how long to wait and eventually gives up on receiving one.A non-responsive port is usually filtered (blocked by a firewalldevice, or perhaps the host is down), but this one test is notconclusive. Perhaps the port is open but the probe or response weresimply dropped. Networks can be flaky. So Nmap tries again by resending the SYN probe. After yet another timeout period, Nmapgives up and marks the port filtered
. In thiscase, only one retransmission was attempted. As described in the section called “Scan Code and Algorithms”, Nmap keeps careful packet lossstatistics and will attempt more retransmissions when scanning lessreliable networks.
Figure5.4.SYN scan of filtered port 139
Nmap will also consider a port filtered
if it receives certain ICMP error messages back. Table5.2 shows how Nmap assigns port states based on responses to a SYN probe.
Table5.2.How Nmap interprets responses to a SYN probe
Probe Response | Assigned State |
---|---|
TCP SYN/ACK response | open |
TCP RST response | closed |
No response received (even after retransmissions) | filtered |
ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, or 13) | filtered |
While the pretty illustrations in this section are useful whenyou have them, Nmap reports exactly what it is doing at the packetlevel when you specify the --packet-trace
option inaddition to any other desired command-line flags. This is a great way fornewbies to understand Nmap's behavior when Ereet is not around tohelp. Even advanced users find it handy when Nmap producesresults they don't expect. You may want to increase the debug levelwith -d
(or even -d5
) as well. Thenscan the minimum number of ports and hosts necessary for your purposeor you could end up with literally millions of output lines. Example5.2 repeats Ereet'sthree-port SYN scan with packet tracing enabled (output edited forbrevity). Read the command-line, then test yourself by figuring outwhat packets will be sent before reading on. Then once you read the traceup to “The SYN Stealth Scan took 1.25s”, you should knowfrom the RCVD lines what the port state table will look like beforecontinuing on to read it.
Example5.2.Using --packet-trace
to understand a SYN scan
krad# nmap -d --packet-trace -p22,113,139 scanme.nmap.org
Starting Nmap ( https://nmap.org )SENT (0.0130s) ICMP krad > scanme echo request (type=8/code=0) ttl=52 id=1829SENT (0.0160s) TCP krad:63541 > scanme:80 A iplen=40 seq=91911070 ack=99850910RCVD (0.0280s) ICMP scanme > krad echo reply (type=0/code=0) iplen=28We got a ping packet back from scanme: id = 48821 seq = 714 checksum = 16000massping done: num_hosts: 1 num_responses: 1Initiating SYN Stealth Scan against scanme.nmap.org (scanme) [3 ports] at 00:53SENT (0.1340s) TCP krad:63517 > scanme:113 S iplen=40 seq=10438635SENT (0.1370s) TCP krad:63517 > scanme:22 S iplen=40 seq=10438635SENT (0.1400s) TCP krad:63517 > scanme:139 S iplen=40 seq=10438635RCVD (0.1460s) TCP scanme:113 > krad:63517 RA iplen=40 seq=0 ack=10438636RCVD (0.1510s) TCP scanme:22 > krad:63517 SA iplen=44 seq=75897108 ack=10438636SENT (1.2550s) TCP krad:63518 > scanme:139 S iplen=40 seq=10373098 win=3072The SYN Stealth Scan took 1.25s to scan 3 total ports.Nmap scan report for scanme.nmap.org (64.13.134.52)PORT STATE SERVICE22/tcp open ssh113/tcp closed auth139/tcp filtered netbios-ssnNmap done: 1 IP address (1 host up) scanned in 1.40 seconds
SYN scan has long been called thestealth scanbecause it issubtler than TCP connect scan (discussed next), which was the mostcommon scan type before Nmap was released. Despite that moniker,don't count on a default SYN scan slipping undetected throughsensitive networks. Widely deployedintrusion detection systems and even personal firewallsare quite capable of detecting default SYN scans. More effectivetechniques for stealthy scanning are demonstrated in Chapter10, Detecting and Subverting Firewalls and Intrusion Detection Systems.