Nmap can scan port ranges and custom port lists, but the real magic is how it prioritizes and optimizes these scans.
Let’s see Nmap in action. Imagine you want to scan ports 20 through 25 and also port 80, 443, and 8080 on a target IP, 192.168.1.100.
nmap -p 20-25,80,443,8080 192.168.1.100
Here’s what happens under the hood. Nmap doesn’t just blindly ping every port in a range. It intelligently groups ports, especially for TCP scans, to maximize efficiency. For instance, if you specify a large range like 1-1000, Nmap might send probes to several ports concurrently, waiting for a limited number of responses before sending more. This is a form of parallelism that prevents overwhelming the target or your network while still getting results quickly.
The problem Nmap solves here is the trade-off between scan speed and accuracy. Scanning every single one of the 65,535 possible ports on a host can take an extremely long time, especially over a slow network. By allowing you to specify only the ports you’re interested in, Nmap lets you tailor your scans to your specific needs, whether you’re looking for common web services (ports 80, 443), FTP (port 21), or a custom application running on an unusual port.
The -p flag is your primary tool. You can combine several types of port specifications:
- Single ports:
-p 80 - Ranges:
-p 1-1024 - Specific lists:
-p 22,80,443 - Combinations:
-p 20-25,80,443,8080 - All ports:
-p-(This is equivalent to-p 1-65535) - Fastest scan (top 1000 ports):
-F(This is a shortcut for-p 1-1000but uses Nmap’s internal logic for selecting the most common ports, which might not be exactly the first 1000 in numerical order).
Nmap’s scan engine also adapts based on the port specification. For very large ranges or when scanning all ports, it might employ techniques like the "FIN scan" (-sF) or "Xmas scan" (-sX) if it detects it can get more information with less overhead, especially against firewalls. These scans send malformed packets and analyze the responses (or lack thereof) to infer port states. However, for specific, smaller lists like 20-25,80,443, Nmap will likely default to a more straightforward SYN scan (-sS) for TCP, which is generally faster and stealthier than a full connect scan (-sT).
When you specify a custom list like 20-25,80,443,8080, Nmap internally creates a list of unique ports and then processes them. It doesn’t scan them strictly in the order you list them. Instead, it groups them for efficiency, especially when using options like -T4 (Aggressive timing) or -T5 (Insane timing). For example, if you scan 80,22,443 with -T4, Nmap might launch probes to all three ports almost simultaneously, rather than waiting for the response from port 80 before sending to port 22. The number of parallel probes is managed by the timing template you select.
The most surprising thing most people miss is how Nmap handles UDP scans with custom port lists. Unlike TCP, UDP is connectionless, meaning each probe is sent independently. This makes UDP scans inherently slower and less reliable than TCP scans. When you use -sU with a custom port list, Nmap doesn’t get the same benefit of grouping probes for efficiency as it does with TCP. It has to send individual UDP packets for each port and then wait for responses or timeouts, which can significantly increase scan duration, especially for large lists or ranges.
The next thing you’ll want to explore is how to combine port scanning with other Nmap features, like service version detection (-sV) or OS detection (-O), to get richer information about the services running on those specific ports.