As content creators at carcodepro.com and automotive repair experts, understanding network diagnostics is becoming increasingly valuable in modern vehicle systems. Just as a mechanic uses specialized tools for car repair, network administrators and security professionals rely on tools like Nmap for network analysis. This article will delve into the various port scanning techniques available in Nmap, enhancing your understanding of network troubleshooting and security assessments, skills that are increasingly relevant in today’s automotive technology landscape.
Understanding Port Scanning with Nmap
For a beginner in automotive repair, tackling complex issues might initially involve using basic tools like hammers or duct tape for tasks they aren’t designed for. However, experienced mechanics know the value of using the right tool for the job, often possessing a wide array of specialized instruments that simplify complex repairs. Similarly, in network diagnostics, experts understand the nuances of different port scanning techniques and choose the most appropriate one (or combination) for the task at hand. In contrast, less experienced users might default to a standard SYN scan for every situation, much like relying solely on a hammer for every car repair.
Nmap, a powerful and free security scanner, lowers the barrier to entry in network scanning. The primary hurdle in mastering port scanning with Nmap is knowledge—understanding the different scan types and when to use them. This knowledge is akin to a mechanic knowing when a strut spring compressor is needed, rather than just brute-forcing a repair.
It’s important to note that many advanced scan types in Nmap require privileged user access, typically root on Unix-like systems or administrator rights on Windows. This is because these scans often involve sending and receiving raw packets, which necessitates lower-level system access. While this might have been a significant limitation when Nmap was first released in 1997, with prevalent shared shell access, the landscape has changed. Today, with cheaper computers, widespread broadband internet, and user-friendly Unix-based desktops (like Linux and macOS), along with Windows versions of Nmap, users have more direct control over their systems and can easily run Nmap with the necessary privileges. This shift is advantageous because privileged options unlock Nmap’s full potential and flexibility.
While Nmap strives for accuracy, it’s crucial to remember that its findings are based on the responses received from the target machine or any firewalls in front of it. Target hosts might be unreliable, sending responses designed to mislead Nmap. More commonly, hosts may deviate from network standards (RFCs) and not respond as expected to certain Nmap probes. FIN, NULL, and Xmas scans are particularly susceptible to these inconsistencies. Such issues are specific to certain scan types and will be discussed in their respective sections.
This article will document over a dozen port scanning techniques supported by Nmap. It’s important to remember that typically only one scan method can be used at a time, although UDP scans (-sU) can be combined with any TCP scan type. The scan type option in Nmap usually takes the form -s<C>, where <C> is the primary character of the scan name (usually the first). An exception is the outdated FTP bounce scan (-b). By default, Nmap performs a SYN scan, but it falls back to a connect scan if the user lacks the necessary privileges to send raw packets (root access on Unix) or when scanning IPv6 targets. Among all the scan types discussed below, unprivileged users can only effectively utilize the connect scan and the FTP bounce scan.
TCP SYN Scan (-sS)
The TCP SYN scan is Nmap’s default and most popular scan for good reason. It’s known for its speed, capable of scanning thousands of ports per second on a fast network unhindered by restrictive firewalls. SYN scans are also relatively stealthy and non-intrusive as they never complete full TCP connections. This is why it’s often referred to as “half-open scanning.” Furthermore, SYN scans are reliable across different TCP stack implementations, unlike some older scans that rely on specific platform behaviors. They provide clear and dependable differentiation between open, closed, and filtered port states.
Here’s how it works: Nmap sends a SYN packet to the target port, initiating a connection as if it were attempting a legitimate connection. It then waits for a response.
- SYN/ACK response: Indicates the port is open and listening for connections.
- RST (reset) response: Signals the port is closed and not actively listening.
- No response after retransmissions: The port is marked as filtered, suggesting a firewall is likely blocking the probe.
- ICMP unreachable errors (type 3, codes 1, 2, 3, 9, 10, or 13): Also indicate a filtered port, often due to firewall rules.
TCP Connect Scan (-sT)
The TCP connect scan becomes Nmap’s default TCP scan when SYN scan is not feasible. This typically occurs when a user lacks the privileges to send raw packets or when scanning IPv6 networks. Instead of crafting raw packets, Nmap utilizes the operating system’s connect system call to establish a connection with the target machine and port. This is the same system call used by web browsers, P2P clients, and most network applications to initiate connections, part of the Berkeley Sockets API. Nmap leverages this API to obtain status information for each connection attempt.
While functional, the connect scan is generally considered less desirable than SYN scan when SYN scan is available. Nmap has less control over the connect call compared to raw packets, making it less efficient. It requires completing a full TCP connection to open ports instead of the half-open reset used by SYN scans. This not only makes it slower and requiring more packets for the same information, but also makes the scan more easily detectable.
A good Intrusion Detection System (IDS) can detect connect scans, though many systems lack such sophisticated alarms. Most Unix-like systems will log connection attempts to syslog, often including verbose error messages when Nmap opens and closes connections without transferring data. Poorly designed services might even crash under the stress of numerous connect scans, though this is less common. System administrators who monitor logs and see a series of connection attempts from a single system should recognize the signature of a connect scan.
UDP Scan (-sU)
While TCP is the dominant protocol on the internet, UDP (User Datagram Protocol) services are also widely used. Common examples include DNS (port 53), SNMP (ports 161/162), and DHCP (ports 67/68). Due to the inherent challenges in UDP scanning (generally slower and more complex than TCP), some security audits mistakenly overlook UDP ports. This is a critical oversight because UDP service exploits are common, and attackers certainly don’t ignore this entire protocol. Fortunately, Nmap offers robust UDP scanning capabilities.
The -sU option activates UDP scan. It can be combined with TCP scan types like SYN scan (-sS) to assess both protocols simultaneously.
UDP scans operate by sending empty (no data) UDP headers to each target port. The responses, or lack thereof, determine the port state:
- ICMP port unreachable error (type 3, code 3): Indicates the port is closed.
- Other ICMP errors (type 3, codes 1, 2, 9, 10, or 13): Suggest the port is filtered.
- UDP response from the service: Confirms the port is open.
- No response after retransmissions: The port is considered open|filtered. This ambiguity arises because the port could be open, or a packet filter might be blocking communication. Version detection (
-sV) can help differentiate between these states.
The primary challenge with UDP scanning is speed. Open and filtered ports rarely respond, forcing Nmap to time out and retransmit probes in case of packet loss. Closed ports can be even more problematic. While they ideally should respond with ICMP port unreachable errors, many hosts rate-limit these messages by default. Linux and Solaris are particularly strict in this regard. For example, Linux kernel 2.4.20 limits destination unreachable messages to one per second (net/ipv4/icmp.c).
Nmap detects such rate limiting and adjusts its scan rate to avoid flooding the network with unnecessary packets that the target will drop. However, Linux-style rate limiting (one packet per second) can extend a 65,536-port scan to over 18 hours. Strategies to accelerate UDP scans include scanning multiple hosts in parallel, focusing on common ports first, scanning from behind a firewall, and using --host-timeout to skip slow hosts.
TCP NULL, FIN, and Xmas Scans (-sN, -sF, -sX)
These three scan types (and potentially more, using the --scanflags option discussed later) exploit a subtle loophole in the TCP RFC (RFC 793) to distinguish between open and closed ports. RFC 793 page 65 states that “if the [destination] port state is CLOSED …. an incoming segment not containing a RST causes a RST to be sent in response.” The following page discusses packets sent to open ports without SYN, RST, or ACK bits set, stating: “you are unlikely to get here, but if you do, drop the segment, and return.”
According to these RFC guidelines, a system adhering strictly to these rules should respond with an RST if a packet lacking SYN, RST, or ACK bits reaches a closed port, and provide no response if the port is open. As long as these three bits are not set, any combination of the other three (FIN, PSH, and URG) is acceptable. Nmap leverages this behavior with the following scan types:
- Null Scan (
-sN): Sends packets with no TCP flags set (all flags are off). - FIN Scan (
-sF): Sets only the TCP FIN bit. - Xmas Scan (
-sX): Sets the FIN, PSH, and URG flags, illuminating the packet like a Christmas tree.
These three scans behave identically except for the TCP flags set in the probe packets.
- RST packet received: The port is considered closed.
- No response: The port is marked as open|filtered.
- ICMP unreachable errors (type 3, codes 1, 2, 3, 9, 10, or 13): The port is marked as filtered.
The primary advantage of these scans is their ability to potentially bypass non-stateful firewalls and packet-filtering routers. They also offer a slightly more stealthy profile compared to SYN scans. However, modern Intrusion Detection Systems (IDS) can often be configured to detect them.
The major drawback is that not all systems adhere to RFC 793 precisely. Some systems respond with RST packets regardless of whether the port is open or closed, leading Nmap to incorrectly classify all ports as closed. Microsoft Windows, many Cisco devices, BSDI, and IBM OS/400 are known to exhibit this behavior, making these scans unreliable against most of these systems. Another limitation is the inability to distinguish between open and filtered ports; the result is always open|filtered when no RST is received.
TCP ACK Scan (-sA)
The TCP ACK scan differs significantly from previous scan types as it never determines open (or even open|filtered) ports. Its primary purpose is to map firewall rule sets, identifying whether they are stateful and which ports are filtered.
ACK scan probes send packets with only the ACK flag set (unless you use --scanflags). When scanning an unfiltered system, both open and closed ports will respond with RST packets. Nmap marks these as unfiltered, indicating that ACK packets can reach them, but the port’s open/closed status remains undetermined. Ports that do not respond or send back ICMP error messages (type 3, codes 1, 2, 3, 9, 10, or 13) are classified as filtered.
ACK scans are particularly useful for testing firewall rules. By sending ACK packets, you can determine if a firewall allows or denies traffic based on established connections (stateful firewalls) or simply filters packets based on rules (stateless firewalls).
TCP Window Scan (-sW)
The TCP Window scan is similar to the ACK scan but exploits a specific implementation detail in certain systems to differentiate between open and closed ports, rather than always reporting unfiltered when RST is received. It achieves this by examining the TCP window field of the RST packets returned. On some systems, open ports use a positive window size (even in RST packets), while closed ports have a zero window size. Thus, instead of always labeling ports as unfiltered upon receiving an RST, the Window scan can classify ports as open or closed based on whether the TCP window value in the reset is positive or zero, respectively.
This scan relies on implementation-specific behaviors that are not universally consistent across systems, making its reliability variable. Systems not supporting this behavior will typically report all ports as closed. Of course, it’s possible the target machine genuinely has no open ports. However, if a scan shows most ports as closed but some common ports (like 22, 25, 53) as filtered, the information might be accurate. Conversely, if a scan reveals 1000 open ports and only three closed or filtered ports, those three might indeed be open.
TCP Maimon Scan (-sM)
The TCP Maimon scan, named after its discoverer Uriel Maimon, was detailed in Phrack Magazine issue #49 (November 1996). Nmap incorporated this technique two issues later. The Maimon scan is nearly identical to NULL, FIN, and Xmas scans, except its probe is FIN/ACK. According to RFC 793 (TCP), an RST packet should be generated in response to such a probe regardless of whether the port is open or closed. However, Maimon observed that many BSD-based systems would drop the packet if the port was open.
- RST packet received: Port is closed.
- No response: Port is open|filtered.
- ICMP unreachable errors: Port is filtered.
Like NULL, FIN, and Xmas scans, Maimon scan can sometimes bypass non-stateful firewalls, but suffers from the same limitations regarding systems that don’t fully adhere to RFC 793.
Custom TCP Scan (--scanflags)
Advanced Nmap users are not limited to the built-in scan types. The --scanflags option allows you to design custom scans by specifying arbitrary TCP flags. This provides flexibility to experiment and potentially evade Intrusion Detection Systems (IDS) that rely on signatures for standard Nmap scans.
The argument for --scanflags can be a numerical flag value (like 9 for PSH and FIN), but using symbolic names is more convenient. Combine any combination of URG, ACK, PSH, RST, SYN, and FIN. For example, --scanflags URGACKPSHRSTSYNFIN sets all flags, though this isn’t particularly useful for scanning. The order of specification is irrelevant.
In addition to specifying flags, you can provide a base TCP scan type (like -sA or -sF). This base type informs Nmap how to interpret responses. For instance, a SYN scan treats no response as filtered, while a FIN scan interprets it as open|filtered. Nmap will behave according to the base scan type, but using your specified TCP flags. If you don’t specify a base type, SYN scan is used by default.
Idle Scan (-sI <zombie host>[:<probeport>])
The idle scan (-sI) is a sophisticated, advanced scan method that allows for truly stealthy TCP port scanning, meaning no packets are sent to the target from your actual IP address. Instead, it leverages a “zombie” host’s predictable IP ID (IP identification) sequence generation as a side-channel to gather information about open ports on the target. An IDS will see the scan originating from the zombie machine you specify (which must be up and meet certain criteria).
This intriguing scan type is complex and beyond the scope of this reference guide. Detailed information is available in a dedicated paper at https://nmap.org/book/idlescan.html.
Beyond its stealth capabilities (due to its blind nature), idle scan enables mapping IP-based trust relationships between machines. The port list reflects open ports from the zombie host’s perspective. This allows you to test target accessibility using various zombies you believe to be trusted (through router/packet filter rules).
You can append a colon and port number to the zombie host if you want to probe a specific port on the zombie for IP ID changes. Otherwise, Nmap defaults to TCP port 80 (commonly used for pinging).
IP Protocol Scan (-sO)
The IP protocol scan (-sO) allows you to determine which IP protocols (TCP, ICMP, IGMP, etc.) are supported by the target machine. While technically not a port scan (as it uses IP protocol numbers instead of TCP/UDP port numbers), it uses the -p option to select protocol numbers to scan, reports results in the standard port table format, and even utilizes the same scan engine as true port scanning methods. It is close enough to port scanning to be included here.
Beyond its practical utility, the protocol scan showcases the power of open-source software. The idea is simple, but the author didn’t initially consider or request such functionality. However, Gerhard Rieger conceived the idea, wrote an excellent patch to implement it, and submitted it to the nmap-hackers mailing list in the summer of 2000. The patch was integrated into Nmap and a new version released the next day. Few commercial software projects have users enthusiastic enough to design and contribute such improvements!
Protocol scan works similarly to UDP scan. Instead of iterating through UDP packet port number fields, it sends raw IP packet headers and iterates through the 8-bit IP protocol field. Headers are typically empty, containing no data or even proper headers for the claimed protocol. The three exceptions are TCP, UDP, and ICMP; appropriate protocol headers are included for them because some systems won’t send them and because Nmap already has functions to create them. Instead of looking for ICMP port unreachable messages, protocol scan looks for ICMP protocol unreachable messages.
- Response in any protocol from target: Protocol marked as open.
- ICMP protocol unreachable error (type 3, code 2): Protocol marked as closed.
- Other ICMP unreachable errors (type 3, codes 1, 3, 9, 10, or 13): Protocol marked filtered (while simultaneously proving ICMP is
open). - No response after retransmissions: Protocol marked open|filtered.
FTP Bounce Scan (-b <ftp-relay-host>)
An interesting feature of the FTP protocol (RFC 959) is support for FTP proxy connections. This allows a user to connect to one FTP server and then request files to be sent to a third-party server. This feature is prone to abuse on many levels, and many servers have ceased supporting it. One exploitable use is to make an FTP server perform a port scan against another host. Simply ask the FTP server to send a file to each desired port on the target host. Error messages will often reveal whether the port is open or not. This was a useful method to bypass firewalls because organization FTP servers were often more accessible to internal hosts than internet hosts were. Nmap supports FTP bounce scan with the -b option. It takes an argument in the format <username>:<password>@<host>:<port>. <host> is the name or IP address of a vulnerable FTP server. As with normal URLs, you can omit <username>:<password>@, causing anonymous login to be attempted (user: anonymous password: -wwwuser@). The port number (and preceding colon) can also be omitted, defaulting to the standard FTP port (21) on <host>.
This vulnerability was more widespread in 1997 when Nmap was released but has been largely patched. Vulnerable servers still exist, so it’s worth trying if other techniques fail. If your goal is to bypass a firewall, scan the target network for open port 21 (or any FTP service if you are doing a full port scan with version detection), then try a bounce scan. Nmap will tell you if the host is vulnerable. If you are just trying to cover your tracks, you don’t (and probably shouldn’t) limit yourself to hosts on the target network. Before scanning random internet addresses for vulnerable FTP servers, consider that system administrators may not appreciate you using their servers in this way.
