Nmap – Port Scanning


What is a Port?

Similar to the way IP addresses are used to identify machines on networks, ports identify specific applications in use on a single machine.

A connection for each protocol is uniquely identified by four elements: source and destination IP addresses and corresponding source and destination ports. All of these elements are simply numbers placed in the headers of each packet sent between hosts.

Because the port number field is 16-bits wide, values can reach 65,535.

TCP/UDP Port Number Ranges

  1. Well-Known (Privileged) Port Numbers: 0 – 1,023
  2. Registered (User) Port Numbers: 1,024 – 49,151
  3. Private/Dynamic Port Numbers: 49,152 – 65,535

Key Concept: Port numbers assignments are managed by IANA to ensure universal compatibility around the global Internet. The numbers are divided into three ranges: well-known port numbers used for the most common applications, registered port numbers for other applications, and private/dynamic port numbers that can be used without IANA registration.

What is a Port Scanning?

Port scanning is the act of remotely testing numerous ports to determine what state they are in. The most interesting state is usually open, meaning that an application is listening and accepting connections on the port.

The six port states recognized by Nmap:


An application is actively accepting TCP connections or UDP packets on this port. Attackers and pen-testers want to exploit the open ports, while administrators try to close or protect them with firewalls without thwarting legitimate users.


A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it.


  • Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port.
  • Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This sort of filtering slows scans down dramatically.


  • The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed.
  • Only the ACK scan, which is used to map firewall rulesets, classifies ports into this state.
  • Scanning unfiltered ports with other scan types such as Window scan, SYN scan, or FIN scan, may help resolve whether the port is open.


  • Nmap places ports in this state when it is unable to determine whether a port is open or filtered.
  • This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered.


  • This state is used when Nmap is unable to determine whether a port is closed or filtered.
  • It is only used for the IP ID Idle scan.

A Quick Port Scanning

nmap <target> does the following:

  1. Converts <target> from a hostname into an IPv4 address using DNS. If an IP address is specified instead of a hostname this lookup is skipped.
  2. Pings the host, by default with an ICMP echo request packet and a TCP ACK packet to port 80, to determine whether it is up and running. If not, Nmap reports that fact and exits. I could have specified -Pn to skip this test.
  3. Converts the target IP address back to the name using a reverse-DNS query. Because of the way DNS works, the reverse name may not be the same as the <target> specified on the command-line. This query can be skipped with the -n option to improve speed and stealthiness.
  4. Launches a TCP port scan of the most popular 1,000 ports listed in nmap-services. A SYN stealth scan is usually used, but connect scan is substituted instead for non-root Unix users who lack the privileges necessary to send raw packets.
  5. Prints the results to standard output in normal human-readable format, and exits.


  • TCP SYN Scan (Stealth) -sS
  • TCP Connect Scan -sT
  • UDP Scan -sU
  • TCP FIN, NULL, and Xmas Scans -sF, -sN, -sX
  • TCP ACK Scan -sA
  • TCP Maimon Scan -sM
  • TCP Idle Scan -sI
  • IP Protocol Scan -s0
  • TCP FTP Bounce Scan -b

TCP SYN (Stealth) Scan (-sS)

  • Requires Privileged Access: YES
  • If a scan type is not specified on the nmap command line, the TCP SYN scan is used by default (root user).


  1. Nmap sends a TCP packet with the SYN flag set.
  2. Since the port is open, target responds with SYN/ACK.
  3. In a normal operation, client’s machine would complete the three-way handshake by sending an ACK packet acknowledging the SYN/ACK. Nmap does not need to do this, since the SYN/ACK response already told it that the port is open. The proper response, since we don’t want to make a full connection, is a RST packet.
					nmap -d --packet-trace -p22,113,139 scanme.nmap.org

TCP Connect Scan (-sT)

  • Requires Privileged Access: NO
  • This is the case when a user does not have raw packet privileges or is scanning IPv6 networks. Instead of writing raw packets as most other scan types do, Nmap asks the underlying operating system to establish a connection with the target machine and port by issuing the connect system call.
  • The first two steps (SYN and SYN/ACK) are exactly the same as with a SYN scan. Then, instead of aborting the half-open connection with a RST packet, source device acknowledges the SYN/ACK with its own ACK packet, completing the connection. As soon as Nmap hears from its host OS that the connection was successful, it terminates the connection. TCP connections usually end with another handshake involving the FIN flag, but Nmap asks the host OS to terminate the connection immediately with a RST packet.
  • The disadvantage of this scan is apparent when application connection logs are examined.
					nmap -T4 -sT scanme.nmap.org

UDP Scan (-sU)

  • Requires privileged access: YES
  • The most curious element of this table may be the open|filtered state. It is a symptom of the biggest challenges with UDP scanning: open ports rarely respond to empty probes. Those ports for which Nmap has a protocol-specific payload are more likely to get a response and be marked open, but for the rest, the target TCP/IP stack simply passes the empty packet up to a listening application, which usually discards it immediately as invalid. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered.

Distinguishing Open from Filtered UDP Ports

  • open|filtered state occurs when Nmap fails to receive any responses from its UDP probes to a particular port.
  • Yet it also shows that, on rare occasions, the UDP service listening on a port will respond in kind, proving that the port is open.
  • The reason these services don’t respond often is that the empty packets Nmap sends are considered invalid.
  • To send the proper packet for every popular UDP service, Nmap would need a large database defining their probe formats. Fortunately, Nmap has that in the form of nmap-service-probes, which is part of the service and version detection subsystem (-sV).
  • When version scanning is enabled with -sV (or -A), it will send UDP probes to every open|filtered port (as well as known open ones). If any of the probes elicit a response from an open|filtered port, the state is changed to open.
					# Improving UDP scan results with version detection
nmap -sUV -F scanme.nmap.org

While this version detection technique is the only way for Nmap to automatically disambiguate open|filtered ports, there are a couple tricks that can be tried manually. Sometimes a specialized traceroute can help. You could do a traceroute against a known-open TCP or UDP port with Nmap or a tool such as Nping. Then try the same against the questionable UDP port. Differences in hop counts can differentiate open from filtered ports. It is more likely to work in situations where the screening firewall is at least a hop or two before the target host.

					# UDP traceroute against known-open port 53
nping --udp --traceroute -c 13 -p 53 scanme.nmap.org

# UDP traceroute against presumed-closed port 54
nping --udp --traceroute -c 13 -p 54 scanme.nmap.org

TCP FIN, NULL, and Xmas Scans (-sF, -sN, -sX)

  • Requires Privileged Access: YES
  • FIN Scan – Sets just the TCP FIN bit
  • NULL Scan – Does not set any bits (TCP flag header is 0)
  • Xmas Scan – Sets the FIN, PSH, and URG flags


  • The key advantage to these scan types is that they can sneak through certain non-stateful firewalls and packet filtering routers.
  • Another advantage is that these scan types are a little more stealthy than even a SYN scan.


  • The big downside is that not all systems follow RFC 793 to the letter. A number of systems send RST responses to the probes regardless of whether the port is open or not. This causes all of the ports to be labeled closed.
  • Another downside of these scans is that they can’t distinguish open ports from certain filtered ones. If the packet filter sends an ICMP destination prohibited error, Nmap knows that a port is filtered. But most filters simply drop banned probes without any response, making the ports appear open. Adding version detection (-sV) can disambiguate as it does with UDP scans, but that defeats much of the stealthy nature of this scan.
					nmap -T4 -sF scanme.nmap.org
nmap -T4 -sN scanme.nmap.org
nmap -T4 -sX scanme.nmap.org

TCP ACK Scan (-sA)

  • Requires Privileged Access: YES
  • Nmap’s unique ACK scan will never locate an open port.
  •  When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined.
  • Ports that don’t respond, or send certain ICMP error messages back, are labeled filtered.
					nmap -sA -T4 scanme.nmap.org

Leave a Reply

Related Post